Independent wl_display Connections

[ehopperdietzel]

I'm unsure if there's a straightforward way to map X Windows to specific processes. If feasible, it would be beneficial to create separate wl_display connections for each. This approach would simplify surface grouping for the compositor and help with other client-specific stuff. Moreover, it would enhance WPV's resilience to errors. For instance, if a compositor posts a protocol error, only the affected wl_client would terminate, preventing other X apps from crashing as well.

[talex5]

If every X application got its own window then they wouldn't be able to communicate. e.g. drag-and-drop wouldn't work and running commands like xprop wouldn't work.

[ehopperdietzel]

I'm unsure if there's a straightforward way to map X Windows to specific processes

Sorry, I explained it wrong. I meant to group X windows by X client. Then, create a separate wl_display connection for each X client (all this happening in the same process). This way, on the Wayland side, if an app triggers a protocol error or the compositor decides to end the connection, only a single wl_display connection would end, preventing surfaces associated with other X clients from being destroyed.

drag-and-drop wouldn't work and running commands like xprop wouldn't work.

This wouldn't be affected.

[talex5]

Xwayland is the thing that uses wl_display. If you want multiple Wayland connections, you need multiple Xwayland processes (which is possible, but then X apps can't communicate with each other except via the proxy, which breaks some things).

[ehopperdietzel]

Oops, I'm sorry, I had the wrong idea about Xwayland all this time. So, if I understand correctly now, does wayland-proxy-virtwl act as an intermediary Wayland compositor (without rendering) and open its own connection with the 'real' compositor to pass XWayland buffers and wl_surfaces (clones) + roles?

[talex5]

Yes, that's right. There's some more details at https://roscidus.com/blog/blog/2021/10/30/xwayland/

[ehopperdietzel]

Wow, thank you! Such an amazing post, I am learning a lot from it. I think the initial suggestion I made is possible though. Since wpv is acting like a Wayland client to the 'real' compositor, it could open individual wl_display connections with it (faking being multiple clients when it is actually one process) and group all resources associated with an X11 app with a dedicated wl_display. This way, if the compositor posts a protocol error, only a single connection (the X11 app) will die and not all. Also, even if there aren't protocol errors, a compositor may decide to kill a client, for example, if it is unresponsive. I imagine doing this would be way more complex and tedious, especially for stuff like clipboard/dnd, but it would make it more robust and solve problems related to input focus management, grouping stuff by client, and so on, on the compositor-side.