wl_subsurface_place_above ignores parent #1865
Comments
|
Moved to wlroots, because it would be an issue with wlroots's subsurface code rather than sway's. Yeah, I have a suspicion our implementation of subsurfaces is not 100% conformant. |
|
Weston achieves this with a dummy subsurface for the parent in the subsurface list (see |
|
Hi there @christianrauch, Do you mind trying out my PR(#2676) to see if the issue has been fixed for you, when you have the time? Thanks! |
|
I am not using sway on a regular basis. I only test libdecoration against released versions from time-to-time. If the example above works in your setup, I am happy to close this issue after the PR has been merged. |
|
I'm seeing a similar issue with a new experimental Firefox backend (https://bugzilla.mozilla.org/show_bug.cgi?id=1695500). Will try the MR in the coming days, in any case it would be great to see this fixed :) |
|
The root cause is that wlroots has a single list of subsurfaces, and these can only be placed above the parent. Instead, we should have two lists, one for subsurfaces under the parent, one for subsurfaces above the parent. |
|
@berylline , yep, I meant your PR :) Concerning the issue: while libdecoration is certainly already a great unit test for compositors, the new FF backend can also already get tested quite easily. It also uses viewports a lot and may uncover bugs: |
|
@berylline as @emersion already pointed out and from a quick look over the PR it does not yet fix the issue here. Hope you'll find time to get back to it - subsurfaces are IMHO one of the coolest and most powerful features of Wayland :) |
Prior to this commit, subsurfaces could only be placed above their
parent. Any place_{above,below} request involving the parent would
fail with a protocol error.
However the Wayland protocol allows using the parent surface in the
place_{above,below} requests, and allows subsurfaces to be placed
below their parent.
Weston's implementation adds a dummy wl_list node in the subsurface
list. However this is potentially dangerous: iterating the list
requires making sure the dummy wl_list node is checked for, otherwise
memory corruption will happen.
Instead, split the list in two: one for subsurfaces above the parent,
the other for subsurfaces below.
Tested with wleird's subsurfaces demo client.
Closes: swaywm#1865
|
Can you try #2948? |
|
Looks good, thanks! I tested with the new experimental Firefox backend which can be enabled in nightly via |
|
Thanks for testing! Yeah, feel free to file new issues. |
Prior to this commit, subsurfaces could only be placed above their
parent. Any place_{above,below} request involving the parent would
fail with a protocol error.
However the Wayland protocol allows using the parent surface in the
place_{above,below} requests, and allows subsurfaces to be placed
below their parent.
Weston's implementation adds a dummy wl_list node in the subsurface
list. However this is potentially dangerous: iterating the list
requires making sure the dummy wl_list node is checked for, otherwise
memory corruption will happen.
Instead, split the list in two: one for subsurfaces above the parent,
the other for subsurfaces below.
Tested with wleird's subsurfaces demo client.
Closes: #1865
Prior to this commit, subsurfaces could only be placed above their
parent. Any place_{above,below} request involving the parent would
fail with a protocol error.
However the Wayland protocol allows using the parent surface in the
place_{above,below} requests, and allows subsurfaces to be placed
below their parent.
Weston's implementation adds a dummy wl_list node in the subsurface
list. However this is potentially dangerous: iterating the list
requires making sure the dummy wl_list node is checked for, otherwise
memory corruption will happen.
Instead, split the list in two: one for subsurfaces above the parent,
the other for subsurfaces below.
Tested with wleird's subsurfaces demo client.
Closes: swaywm#1865
Prior to this commit, subsurfaces could only be placed above their
parent. Any place_{above,below} request involving the parent would
fail with a protocol error.
However the Wayland protocol allows using the parent surface in the
place_{above,below} requests, and allows subsurfaces to be placed
below their parent.
Weston's implementation adds a dummy wl_list node in the subsurface
list. However this is potentially dangerous: iterating the list
requires making sure the dummy wl_list node is checked for, otherwise
memory corruption will happen.
Instead, split the list in two: one for subsurfaces above the parent,
the other for subsurfaces below.
Tested with wleird's subsurfaces demo client.
Closes: swaywm/wlroots#1865
Using
wl_subsurface_place_abovefails withwl_subsurface@92: error 0: place_above: wl_surface@9 is not a parent or siblingon a parent surface that has previously been used inwl_subcompositor_get_subsurface.This works on GNOME shell and
weston. Therefore, I assume for the moment that this is a sway compositor issue. This might as well be a client issue, but sway should at least behave like the reference compositor weston and show the same window surfaces.sway 1.2 debug log: sway.log
steps:
meson build && ninja -C builddemo.shwayland log on sway 1.2: wl_sway.txt
wayland log on GNOME shell 3.28: wl_gnome.log
The text was updated successfully, but these errors were encountered: