>This is a shame. I'd be willing to help make it happen, by either writing code or helping fund someone else to You might consider joining the IRC/Matrix chann

>This is a shame. I'd be willing to help make it happen, by either writing code or helping fund someone else to You might consider joining the IRC/Matrix channel and making an offer to one of the maintainers. >Now for something like syncing the cursor size, that belongs in Wayland. Duh. The Wayland compositor handles displays, their scale factors, and the hardware cursor. It's just common sense. No, unfortunately it doesn't and it isn't. You're describing something that isn't Wayland. I've seen upstream Wayland developers following the rule of "it should only be a Wayland protocol if it requires access to Wayland object ids" and idle-inhibit does follow that rule (you can inhibit on a window id). Anything to do with mouse settings doesn't follow that rule. There was a conscious decision to keep settings handling out of Wayland protocols because, among other reasons, Wayland is designed for a specific thing (windowing) and is bad at being a settings database. It doesn't really even have a way to identify hardware devices, those are all abstracted away under "outputs" and "seats" which don't actually need to correspond to any physical device. >Aren't systemd user instances per user and not per session? How can you deal with DBus in that context? You only have one session bus per user and it's the one used by systemd. I mean, you can start more buses but why would you need to when none of the services you want will be using that?