I don't see anything like that on the X11 side, and from reading about it a bit it seems to me that WS_EX_TRANSPARENT has some specific behavior that we should be implementing instead of magically delegating to the compositor. There are some details about it that we would possibly miss by doing that.
I was able to find information about WS_EX_TRANSPARENT, but information about the combo `WS_EX_TRANSPARENT|WS_EX_LAYERED` is limited, and I am not sure at which level of the stack this should be applied ideally. As Esme notes, doing this at the host window system level at least gives us pass through to host windows, but what we are giving up in terms of other behaviors, I don't know.
FWIW, I ran some quick tests (Win10) and at least `WindowFromPoint()` seems to respect (i.e., pass through) `WS_EX_TRANSPARENT|WS_EX_LAYERED`.
One reason I have gone for this approach for winewayland (mentioned in the second paragraph of the commit message), is that if we allow `WS_EX_TRANSPARENT|WS_EX_LAYERED` windows to get the Wayland input focus, the cursor many not be properly set leading to the linked bug (null cursor, pointer constraints kicking in etc). I tried a few ways to work around the focus issue, but in the end not allowing mouse input and focus at all was the simplest and seemed consistent with the spirit of the flags.
Actually, checking WineX11, it seems to not be handling the cursor part fully correctly either at the moment (screenshots of FL Studio 2025, the small text popup under the cursor is `WS_EX_TRANSPARENT|WS_EX_LAYERED` ):
Whereas on Win10 and winewayland + this MR we get:
Perhaps solving the cursor issue (if this is caused and fixed at the core level) could also help with winewayland and allow us to not *need* this MR (although we may still *want* it for the passthrough-to-host-windows feature).