-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
1.10 backport #8353
1.10 backport #8353
Conversation
The reasoning for using a commit handler is to ensure that all paths for output changes are correctly handled. With the centralized modeset infrastructure in place, we can move the logic there. This allows us to be smarter and avoid extraneous arranges, output manager updates and transaction commits. The side-effect is a minor duplication for the special-case request_state, but the shared path will be relied upon further in future commits to justify this duplication. (cherry picked from commit b83e5aa)
output_enable/output_disable are only called from modeset, and from output destroy which requests modeset. As such, they can rely on the modeset handling arrange. (cherry picked from 6045ad9)
Output layout changes originate from the centralized modeset infrastructure and request_state which already takes care of arranging and updating outputs as needed. (cherry picked from af28ac0)
(cherry picked from 4fe054c)
(cherry picked from 4fe054c)
This is handled by apply_output_configs. (cherry picked from 4f9ce46)
Disabled outputs might not have a geometry to arrange for, so skip the arrange to avoid messing up the workspace geometry. (cherry picked from f4a6b03)
Simplify find_output_config and inline the search through the output configs instead of using list_seq_find with a comparator function. The new implementation will merge any amount of matched configs in order, which will be relied upon in a future commit. (cherry picked from a0c0349)
We always need to start out with the default configuration, regardless of whether the config is reloading or not to ensure that config decisions are stable given a specific configuration. (cherry picked from 0496477)
Instead of using a single finalized output config per output, accept a regular list of output configs like the one ultimately stored for configuration purposes. This allows the output management code to test an augmented configuration while still using the same output config logic, without having to mutate the stored configuration. This in turn allows us to make a few APIs private. A bug note about an existing issue with derade to off is added as well. (cherry picked from 29b3f00)
(cherry-picked from d7a76d3)
Arranging lock surfaces rely on the sway_output width and height being updated, but these are only updated after the commit has been completed and all commit listeners have executed. This means that the lock surfaces will not be appropriately scaled to match a change in output dimensions, and may reveal what is under the lock background. Replace the implicit arrange through the output commit listener with an explicit arrange after the output configuration is finalized. This might have regressed by other transition away from output commit listeners for other arrange tasks, but even then it would have erroneously relied on signalling order. (cherry-picked from 785a459)
If there's something we don't want, I can split it - just walked through my commits on master one by one, and it works in a quick local test. I did have a one-time glitch where after testing on/off and output manager/power command interactions, one output was arranged with an odd, slightly smaller geometry (using an odd 3199 width instead of 3840), causing an overlap - but it wasn't immediately reproducible, so I suspect it might be a latent bug in master too. |
Thanks! |
Backports:
cc @emersion