Overhaul Wayland initial gathering workflow#453
Open
stacyharper wants to merge 2 commits intoCloudef:masterfrom
Open
Overhaul Wayland initial gathering workflow#453stacyharper wants to merge 2 commits intoCloudef:masterfrom
stacyharper wants to merge 2 commits intoCloudef:masterfrom
Conversation
stacyharper
changed the title
The current init workflow has multiple limitations. Asking for the Wayland folks brings me to implement this alternative approach: https://gitlab.freedesktop.org/wayland/wayland/-/issues/576 Previously we was using the global advertised wl_outputs. We then wait for the wl_surface.enter event to know which output we are displayed on. (We also use this to determine the surface scale value, not the fractional value). This is wrong, and slowly deprecated by the protocol. Other layer shell surface might limit the available geometry our menus can use. This also means we receive this information very late in the workflow, after commiting the first layer_shell with a random max_height. The correct way is to first create a layer shell, anchored to the four corners. Its configure event then advertises us of the available geometry. This bump the wl_compositor version to 6, to receive the wl_surface.preferred_buffer_scale directly, instead of computing it ourselves using the surf_outputs.
As I understand "no overlap", it means "do not overlap". This correspond to this call from the Wayland backend: zwlr_layer_surface_v1_set_exclusive_zone(..., overlap ? -1 : 0); The spec says: > If set to zero, the surface indicates that it would like to be moved > to avoid occluding surfaces with a positive exclusive zone. If set to > -1, the surface indicates that it would not like to be moved to > accommodate for other surfaces, and the compositor should extend it > all the way to the edges it is anchored to. So "0" is "do not overlap", and "-1" is "overlap", okay. The problem is that the overlap boolean comes from !client->no_overlap. Meaning that -n => true => !true => false so -n gives 0 "do not overlap" I think the code is correct, but the description of the argument is miss-leading. Also, we initiate the menu->overlap sooner, because the renderer need this to gather the maximum available geometry correctly. I'm not sure if this the best way to to so.
stacyharper
force-pushed
the
wbarraco/push-qzlyvkqrvtrz
branch
from
674a14c to
d3eb9c3
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Replace: #431
wayland: overhaul the context gathering workflow
The current init workflow has multiple limitations. Asking for the Wayland folks brings me to implement this alternative approach:
https://gitlab.freedesktop.org/wayland/wayland/-/issues/576
Previously we was using the global advertised wl_outputs. We then wait for the wl_surface.enter event to know which output we are displayed on. (We also use this to determine the surface scale value, not the fractional value). This is wrong, and slowly deprecated by the protocol. Other layer shell surface might limit the available geometry our menus can use. This also means we receive this information very late in the workflow, after commiting the first layer_shell with a random max_height.
The correct way is to first create a layer shell, anchored to the four corners. Its configure event then advertises us of the available geometry.
This bump the wl_compositor version to 6, to receive the wl_surface.preferred_buffer_scale directly, instead of computing it ourselves using the surf_outputs.
wayland: fix --no-overlap meaning and behavior
As I understand "no overlap", it means "do not overlap". This correspond to this call from the Wayland backend:
zwlr_layer_surface_v1_set_exclusive_zone(..., overlap ? -1 : 0);
The spec says:
So "0" is "do not overlap", and "-1" is "overlap", okay.
The problem is that the overlap boolean comes from !client->no_overlap. Meaning that -n => true => !true => false so -n gives 0 "do not overlap"
I think the code is correct, but the description of the argument is miss-leading.
Also, we initiate the menu->overlap sooner, because the renderer need this to gather the maximum available geometry correctly. I'm not sure if this the best way to to so.