Featured image for Today's Dev #16

Today's Dev #16

November 28, 2024

In yesterday's Today's Dev, I got configuration applying working again as well as functional setters for my DBus Server. Today, I planned on starting to mind-map a solution for a configuration change batching system. Massive image below, I would suggest opening in a new tab and zooming in. My current line of thinking (almost certainly subject to change as I work on this) is that it all centers around a singular WaylandOutputConfigurationBatch. You create new events starting with enabling or disabling an output, which is no different than currently. If you are enabling / keeping an output enabled, you will have available the following events:
  • Set Gamma: This would use wlr-gamma-control-unstable for creating per-output gamma controls.
  • Set Mirror Of: This event would enable you to set the specified "child" output as a mirror of a "parent" one. In reality, the way you accomplish this is just by having one output in the same coordinate space as another so they overlap.
  • Set Mode: Set the resolution & refresh rate mode.
  • Set Position: Probably keep this for now but plan to deprecate.
  • Set Position Anchor: This event would facilitate positioning a given output (child) relative to another (parent), with horizontal and vertical anchoring. I would prefer this to replace the Set Position event already, though realistically I think both will stick around for a bit so others on the team can tinker, even though that'll make "positioning" fun. Calculating the change and end position of an output should be much simpler when it is explicitly anchoring another.
  • Set Scale: Pretty self-explanatory on this one?
  • Set Transform: Varying degrees of valid rotation. Uses wl_output::transform so there are specific values. Doc here if you are interested.
I would expect that the change calculation would:
  1. Process each output's gamma, mode, and scale events. We would make the respective zwlr output configuration head call and also calculate on our own the end-result resolution based on mode selected and scale.
  2. Aggregate all position anchoring events. Calculate the total global coordinate space used by all the outputs. This will be based on the total resolution of all the chosen / current modes * scale factors - mirror events (eliminate this mode from coordinate calculation). From then, create a tree of parent to children, find left most output, calculate offsets based on that monitor. 3/ Create position calls for those heads, for those in mirror set it to coordinate space of related monitor.
Perform test or apply. If you were to test first, we would probably do some sort of result saving, so that way we don't need to re-perform the calculation on apply. If there is any event before apply, we would invalidate the result and just re-calculate on apply as if you never performed a test, assuming you don't test again. In which case around and around we gooooooo. So that's where my head is at. Ping me on my Bluesky or Mastodon (shown below) if you have any better ideas, I'd love to hear them.
Did you know?
You can follow me on Bluesky, Mastodon, or Threads!