Alternative (non-CLI) Socket Handover Mechanisms

[Ferdi265]

The current handover mechanism is based on the CLI options that Kwin uses for socket handover and not on any agreed-upon standard. These CLI arguments are inconsistently named (--socket vs --wayland-fd) and also have a CLI option format that not all compositors share (River uses single dash CLI options, cosmic-comp currently has no CLI parsing at all).

This means that there is a need for a different socket handover mechanism. Options include:

• CLI-based, keep the Kwin option naming
  • pro: Kwin and Hyprland already have support
  • con: inconsistent naming
  • con: forces a specific kind of CLI argument format onto compositors
• CLI-based, but with more consistent naming (--wayland-socket and --wayland-fd)
  • pro: consistent naming
  • con: forces a specific kind of CLI argument format onto compositors
• Environment-based, Systemd Socket Activation style: LISTEN_PID, LISTEN_FDS, LISTEN_FDNAMES with the fd as file descriptor 3.
  • pro: potential future integration with systemd possible
  • pro: simple to implement even without systemd
  • con: very generic env var name
• Environment-based, but with custom env vars: WAYLAND_SOCKET_NAME, WAYLAND_SOCKET_FD
  • pro: even simpler to implement
  • con: different from systemd mechanism

[0x5a4]

Heres my 2ct on this:

1. I feel like maintaining KDE Compatibility isnt really necessary, as they have their own tool and anyone using KDE will propably just stick with that. Hyprlands options are so young that breaking them might not be that big of a deal.
2. I like this, but in regards to River and cosmic its kind of a non-option?
3. I've spent around 5 minutes researching systemd socket activation and in my understanding its meant for on-demand kind of services (like pipewire). I just dont think this is the case with wayland compositors. Maybe if someone runs firefox from the tty and then the compositor would start on demand but I feel like that is a very very uncommon situation. (Also the naming is to generic IMO)
4. I like this.

Even though I dislike environment variables for their implicit behaviour, I think the WAYLAND_SOCKET_NAME and WAYLAND_SOCKET_FD ones are the best option here.

[Ferdi265]

Heres my 2ct on this:

1. I feel like maintaining KDE Compatibility isnt really necessary, as they have their own tool and anyone using KDE will propably just stick with that. Hyprlands options are so young that breaking them might not be that big of a deal.

Right, makes sense. I would still support this as an alternative to not break compatibility so early.

2. I like this, but in regards to River and cosmic its kind of a non-option?

Yeah, the options are nice, but it doesn't really work in their cases. I would only go for this if some compositors are absolutely against env vars, in which case I would support both env vars and CLI options.

3. I've spent around 5 minutes researching systemd socket activation and in my understanding its meant for on-demand kind of services (like pipewire). I just dont think this is the case with wayland compositors. Maybe if someone runs firefox from the tty and then the compositor would start on demand but I feel like that is a very very uncommon situation. (Also the naming is to generic IMO)

Socket activation can also be used to allow dependent services to start up in parallel. I tried to launch Sway as a systemd user service once, and had an issue where sometimes services like kanshi or mako failed to start up because they launched before the wayland socket existed. Socket activation can make sure the socket exists earlier and "buffer" connections until the compositor is ready. I need to look into the specifics, but potentially the socket unit can be made to only be active after a session is created (e.g. a user logs in)

4. I like this.

Even though I dislike environment variables for their implicit behaviour, I think the WAYLAND_SOCKET_NAME and WAYLAND_SOCKET_FD ones are the best option here.

Yes, these env vars are basically a direct translation of the CLI options to env vars. Main disadvantage with this over the CLI is that if the compositor doesn't support it, those env vars (and the socket FD!) will leak to all clients in the session. Unknown CLI options are much less likely to be silently ignored (counterexample: cosmic-comp completely ignores its args and the socket would leak even if the CLI option is used if cosmic doesn't support socket handover).

---

Thanks for the feedback! I'm still quite interested in what compositor developers have to say to this, since they are ultimately who will have to consume this API.

[stefonarch]

1. I feel like maintaining KDE Compatibility isnt really necessary, as they have their own tool and anyone using KDE will propably just stick with that. Hyprlands options are so young that breaking them might not be that big of a deal.

Right, makes sense. I would still support this as an alternative to not break compatibility so early.

It could be useful when kwin_wayland is used outside plasma as with lxqt-wayland-session. I tested the feature when it came out and it didn't recover from crash. And there are several methods to make it crash always (using hot corners for example).

[Ferdi265]

1. I feel like maintaining KDE Compatibility isnt really necessary, as they have their own tool and anyone using KDE will propably just stick with that. Hyprlands options are so young that breaking them might not be that big of a deal.

Right, makes sense. I would still support this as an alternative to not break compatibility so early.

It could be useful when kwin_wayland is used outside plasma as with lxqt-wayland-session. I tested the feature when it came out and it didn't recover from crash. And there are several methods to make it crash always (using hot corners for example).

I recently tested LXQt + Kwin with both wl-restart and kwin_wayland_wrapper, and the basics work with both for clients that support recovering (e.g. konsole) if the start script manually exports QT_WAYLAND_RECONNECT=1 before starting Kwin.

[stefonarch]

I recently tested LXQt + Kwin with both wl-restart and kwin_wayland_wrapper, and the basics work with both for clients that support recovering (e.g. konsole) if the start script manually exports QT_WAYLAND_RECONNECT=1 before starting Kwin.

Yes, tested again for good. lxqt-panel doesn't recover, pcmanfm-qt's desktop most of the time, featherpad, telegram and qterminal always.

[stefonarch]

Tested now with wl-restart kwin_wayland and it works fine too. The issue with kwin is that the argument lxqt-session will be executed again, autostarting all applications again.

But using hot corners on kwin_wayland to make it crash can lead also to a complete block of any input and the need of a hard reset. Happened twice now...