In yesterday's Today's Dev, I got most of the TOML-based configuration bits working against excluding the actual applying due to a segfault when trying to use the QtWayland::zwlr_output_configuration_head_v1 returned from the configuration Object after enabling a given head (output / display). I also got the D-Bus server running again with getters returning expected data.Today, I implemented a new WaylandOutputConfigurationHead class that inherits from the QtWayland one referenced above, with some camelCased methods that map to the respective method in the inherited class (e.g. setPosition -> set_position). Fixed up some wl_display_dispatch_pending calls for the non-pending named function and got configuration applying to work again! 🎉 Big deal after all the refactoring and work I have done.Fired up D-Feet and started testing out my setter methods. I have validated that the following work, with some tinkering certainly needed:
SetCurrentMode - Setting the mode of an output to a different one works. I was able to change the resolution of my left-side monitor to 2560x1440. I then promptly changed it back because oh my god compared to 4k, 1440p feels so small!
SetOutputPosition - Tested changing the Y position of my left-hand monitor. It worked. Not really much to say about that one.
SetOutputEnabled - This worked when turning the monitor off but my reference to wl_registry kinda exploded for some reason when trying to turn the monitor back on, so not sure about that one yet. Could be a problem in the daemon or in the compositor. Might have to test on Magpie v1 (as opposed to current testing with labwc) to learn more.
Now that I got all of that working, I intend on starting mind-mapping a solution (using the Excalidraw plugin within Obsidian -- highly recommend both by the way) for a configuration change batching system. There is almost certainly a better name for it, it's by no means a new idea. Effectively all my current DBus setters like setting mode, position relative to another head, etc. are all individual calls. I would like to change it so configuration changes are layered on top of each other, then firing off a "test" or "apply" event would condense all those events down (eliminating any extraneous events) into one WaylandOutputConfiguration with the changes necessary for each head.To describe it to a "Josh before his morning coffee", I want you to imagine your typical display configuration graphical software. You have rectangles, typically with labels in them describing the displays. At first, this is based off the current state of those heads (their position, resolution, refresh rate, adaptive sync, enabled / disabled, etc.). If you want to change the resolution and position of your monitors all in one go, you'd probably set their resolution so the rectangles change size, then move them around, then click apply. You're not changing the resolution, clicking apply, moving one monitor, clicking apply, moving another monitor, clicking apply. Oh god now you've gone insane, you're closing out of the software and making a strongly worded social media post.To make it more sane, I would want it so you'd break it down by changes to each head, request a new instance for batch configuration, send all of those over the wire, then apply it all at once. Creating a new instance would invalidate any existing one. I'm already doing something sorta similar with my config applying, I just have the luxury of being able to pre-define all my necessary config calls like setPosition ahead-of-time because I have the config. So I would expect to transform that into using the batch config system before moving on to my DBus changes (including probably the move to QtDBus).So to the literal drawing board I shall go tomorrow!