Query and expose XShape regions

[emersion]

X11 clients using XShape expect their buffers to be clipped.

https://gitlab.gnome.org/GNOME/mutter/-/blob/5ec9bde64fbc07e057e78b04c3b0b66a86c07f6e/src/x11/window-x11.c#L2378

---

wlroots has migrated to gitlab.freedesktop.org. This issue has been moved to:

https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/2404

[aplund]

The clipping and shape of Xeyes works OK under weston.

[emersion]

This would indicate that we don't need that Mutter XShape code, and that we do something else wrong, but I have not idea what.

[emersion]

Another test client: https://gist.github.com/aplund/40b188039ab540b14cb3964b409f9acb

[psychon]

Random guess: weston seems to use a reparenting WM with a depth=32 parent window (using a random depth=32 visual).
Searching for xcb_reparent_window in wlroots finds no matches, so I guess that it is not reparenting.

However, I have no idea why that would make such a difference...
Perhaps something in the X server applies the shape when drawing a window without an alpha channel to a window with an alpha channel?

[emersion]

Ahah, I just asked a user to try this patch disabling reparenting in Weston to see if that made a difference there. Unfortunately my own Weston doesn't seem to support XShape properly...

[aplund]

Ahah, I just asked a user to try this patch disabling reparenting in Weston to see if that made a difference there. Unfortunately my own Weston doesn't seem to support XShape properly...

With weston's drm backend, the patch makes transparency not work anymore.

With weston's wayland backend, transparency doesn't work either way.

[emersion]

Hm, interesting that the backend makes a difference, not sure what would cause that. I've been testing with both backends and it's never working properly on my setup.

Anyways, maybe we can try to set a 32-bit visual on our root window and see if it improves things.

[emersion]

FWIW, X11-native composition managers (like xcompmgr) do query the xshape region and use it to clip their rendering.

[psychon]

Since the conversation is so far only about rendering: How is input handled? In X11, you can click "between the eyes" of xeyes and the window behind xeyes gets the mouse click. I wonder what happens with Xwayland when

• another X11 window is behind xeyes? (I guess: The X11 server applies the input region and does the "click through")
• another wayland native window is behind xeyes?
• Another wayland native window is behind xeyes and behind that is another X11 window? (= is the mouse button event sent to the wrong window?)

[emersion]

It seems to me that Xwayland applies an input region on the wl_surface via the Wayland protocol, but I'd need to check. In any case clicks aren't sent to the X11 client.