Multiple event loops/backends (X11 and Wayland)

[dekrain]

Description

Hello! I am developing an audio app that supports plugins. Most plugin formats support X11, and recently starting to support Wayland as well, and my main application windows will support either.
I'm trying to figure out a way to have 2 event loops running at once to support the two windowing systems, using mio/calloop to dispatch between them. It seems there's currently (in 1.30) a lock that prevents multiple loops to be created. Only on the web the lock can be dropped. It seems that beyond this, there shouldn't be any problem with having multiple loops on some platforms, at least unix.
Can you allow having multiple loops running (maybe with somthing like allow_event_loop_recreation)? Or some other solution to support this use case?

Relevant platforms

Wayland, X11

[dekrain]

Considering allow_event_loop_recreation, maybe it should be refactored such that EVENT_LOOP_CREATED is not a boolean, but additionally has a state where new loops can be created without limits.

[dekrain]

I can see that the new beta 0.31 version is structured differently, and this check is performed per loop type, so possibly this issue will disappear once the new version is released. But it still affects versions <=0.30.

[kchibisov]

Why do you need to run both in parallel though? You usually just run one and pick current windowing system. And winit's event loop does exactly that, it'll pick Wayland on Wayland and X11 on X11.

Running e.g. both X11/Wayland in parallel doesn't make much sense.

[dekrain]

It does make sense if I want to, for example, run my app windows as Wayland windows (where supported), and X11 windows for plugins only supporting X11, and eventually Wayland plugin windows for those plugins supporting it.
In particular, it would also allow to mix plugins that support Wayland embedding with those supporting X11 embedding.

[kchibisov]

Then maybe they should run as subprocesses? Like X11 has global error handler, so your plugins can crash your application, etc.

[dekrain]

Then maybe they should run as subprocesses?

That is certainly an option, but it would result in a more complicated architecture, and may not always be practical to do so.
I like having a choice in the specific approach where it's possible.

Moreover, it seems I would need to make some modifications myself, since I also need to implement XEmbed on the embedder's side. For that, I need to hook up directly into the event loop to receive raw window events for the window I hand over to the plugins. There's doesn't seem to be a clean way to do that, except maybe calling XWindowEvent before the normal event polling, but that doesn't seem reliable.
I believe the right way to approach that would be to expose enough of internal details (maybe an XEvent filter hook?) so that it can be implemented in an external crate (I'm thinking something like xembed-winit) instead of winit directly, since it's a niche and platform-specific functionality, but for that to work, there needs to be a way to interoperate with winit's workings.

Edit: I figured out the XEmbed initial event things, but it's a bit hacky, like I said earlier. Still a better integration with the event loop would be useful for catching later events.

[kchibisov]

winit has xembed support...

Do you control those plugins or how it all works? Can you more clearly define a problem and how communication works, but please, put it simply.

[dekrain]

winit has xembed support...

But that is only for embedding windows in a passed-in parent. It also has a minimum amount of support, only setting the XEmbed info property, it doesn't handle XEmbed events for example.

I am writing an XEmbed host, and while I already figured out I didn't need the full thing, my issues were due to other causes, I still think it would be useful to have a door open to support these use cases, namely:

• receiving XEmbed events, which are client events of the _XEMBED type, and
• detecting when a child window attaches, which is the part I implemented.

Do you control those plugins or how it all works? Can you more clearly define a problem and how communication works, but please, put it simply.

Currently, I have implemented clap support, which uses a method where I pass in a parent window ID to the plugin, and the plugin opens its own X connection and sets up its window to be an XEmbed client to the one I passed in.

[kchibisov]

I think the most realistic solution for you would be to write a wayland compositor at this point, so you can control all of that client mess correctly and have X11 plugins interacting with Wayland plugins, otherwise such interactions won't really work.

How winit will run doesn't really matter, and you don't need multiple event loops.

Example of such compositor is gamescope, the system76 bar (it embeds wayland clients). Maybe you can even reuse the system76 solution for what you do and just write GUI interface.

[kchibisov]

Maybe you can just reuse this thing to some degree https://github.com/pop-os/cosmic-panel .

Though if you rely on xembed like embedding, custom protocol would be required, I guess for wayland, but in anyway, you should be more like Wayland compositor if you want to mix X11 and Wayland, any other solution won't fly, since X11 and Wayland isolated, and if you embed both but then you can not simple move things from one plugin to another it'll probably be odd, so you need to supervise both in one way or another, I think.