1
0
Fork
You've already forked layercheck
1

WIP: Add wp_viewporter + example #1

Open
Consolatis wants to merge 0 commits from Consolatis:feature/add_wp_viewporter into main
pull from: Consolatis:feature/add_wp_viewporter
merge into: vyivel:main
vyivel:main
First-time contributor
Copy link

Second commit makes things work at least on labwc. I am not sure what is the expected behavior of compositors though with 3 different sizes:

  • layershell size
  • buffer size
  • viewporter size

Which one of those should be used when calculating the anchor positions?

Second commit makes things work at least on labwc. I am not sure what is the expected behavior of compositors though with 3 different sizes: - layershell size - buffer size - viewporter size Which one of those should be used when calculating the anchor positions?
@ -142,1 +148,4 @@
if (surface->viewport) {
int w = surface->vp_src_width ? surface->vp_src_width : (int)width;
int h = surface->vp_src_height ? surface->vp_src_height : (int)height;
Author
First-time contributor
Copy link

These should likely subtract surface->vp_src_x and surface->vp_src_y if using the dimensions of the configure event.

These should likely subtract `surface->vp_src_x` and `surface->vp_src_y` if using the dimensions of the configure event.

Viewport doesn't matter here, the only thing that does is the resulting surface size.

zwlr_layer_surface_v1.set_size is a part of the client-side surface configuration (https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/28#note_594954) and shouldn't be sent in response to a server configuration event.

Viewport doesn't matter here, the only thing that does is the resulting surface size. `zwlr_layer_surface_v1.set_size` is a part of the client-side surface configuration (https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/28#note_594954) and shouldn't be sent in response to a server configuration event.
Author
First-time contributor
Copy link

Viewport doesn't matter here, the only thing that does is the resulting surface size.

So when I get it right, wlroots should use the surface size (viewport ? viewport : buffer) rather than the desired layershell size for wlr_scene_layer_surface_v1_configure()? Then what is the point of the desired layershell size in the protocol?
It also states:

Sets the size of the surface in surface-local coordinates. The
compositor will display the surface centered with respect to its
anchors.

So to me it seems that wlroots is actually correct by using the layershell size and its the client that should set a new layershell size when changing the viewport or buffer size.

zwlr_layer_surface_v1.set_size is a part of the client-side surface configuration (https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/28#note_594954) and shouldn't be sent in response to a server configuration event.

Right, usually the client would have some code path outside of the configuration handler. The only reason that is being done in this PR is that it needs the requested width and height from the compositor so it was a quick way to test.

> Viewport doesn't matter here, the only thing that does is the resulting surface size. So when I get it right, wlroots should use the surface size (`viewport ? viewport : buffer`) rather than the desired layershell size for `wlr_scene_layer_surface_v1_configure()`? Then what is the point of the desired layershell size in the protocol? It also states: > Sets the size of the surface in surface-local coordinates. The > compositor will display the surface centered with respect to its > anchors. So to me it seems that wlroots is actually correct by using the layershell size and its the client that should set a new layershell size when changing the viewport or buffer size. > `zwlr_layer_surface_v1.set_size` is a part of the client-side surface configuration (https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/28#note_594954) and shouldn't be sent in response to a server configuration event. Right, usually the client would have some code path outside of the configuration handler. The only reason that is being done in this PR is that it needs the requested width and height from the compositor so it was a quick way to test.
This pull request is broken due to missing fork information.
View command line instructions

Checkout

From your project repository, check out a new branch and test the changes.
git fetch -u feature/add_wp_viewporter:Consolatis-feature/add_wp_viewporter
git switch Consolatis-feature/add_wp_viewporter

Merge

Merge the changes and update on Forgejo.

Warning: The "Autodetect manual merge" setting is not enabled for this repository, you will have to mark this pull request as manually merged afterwards.

git switch main
git merge --no-ff Consolatis-feature/add_wp_viewporter
git switch Consolatis-feature/add_wp_viewporter
git rebase main
git switch main
git merge --ff-only Consolatis-feature/add_wp_viewporter
git switch Consolatis-feature/add_wp_viewporter
git rebase main
git switch main
git merge --no-ff Consolatis-feature/add_wp_viewporter
git switch main
git merge --squash Consolatis-feature/add_wp_viewporter
git switch main
git merge --ff-only Consolatis-feature/add_wp_viewporter
git switch main
git merge Consolatis-feature/add_wp_viewporter
git push origin main
Sign in to join this conversation.
No reviewers
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
vyivel/layercheck!1
Reference in a new issue
vyivel/layercheck
No description provided.
Delete branch "Consolatis:feature/add_wp_viewporter"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?