Hi, I'd like to start a discussion about gnome-settings-daemon in a wayland session. With the move towards wayland there are some things currently handled by gnome-settings-daemon that will have to be either disabled or grow a wayland code path.
At first, we have to keep in mind that we need to support two scenarios with a few nuances: we must keep the current plain X session without regressions and we must support a wayland session without forgetting that there's still an X server (and X clients) running. XWayland isn't a regular X server though. For instance, it won't honor some xkb calls, instead it will get keymaps and xkb state from the wayland protocol like any other wayland client. Pointer control like acceleration and threshold is also a NOP in xwayland as are DPMS settings. So, my proposal is that we go through the various plugins and check on a case by case basis what needs to be done. For instance, on the keyboard plugin I'm planning to move all the input source stuff to another file and only instantiate it on an X session. Things like key auto repeat settings though have to remain there even on a wayland session since auto repeat is a client side thing in wayland so we still want to configure xwayland to do it with the desktop settings. The input sources part of the keyboard plugin will move mostly into gnome-shell since it's just a matter of reading gsettings and applying things to the lower levels of the compositor stack. Talking to ibus-daemon needs to be closely coordinated so doing it in JS from gnome-shell is also the natural thing to do. The mouse plugin seems like it can be totally disabled under wayland since everything it does is needless for xwayland. Everything it does is setting values so I think it should also be moved to a JS implementation in gnome-shell which just pokes the values into libinput's API. Also, the locate pointer feature is something that's overdue to move into the compositor anyway. I haven't looked closely at other plugins yet but I suppose that some of them don't need any change like datetime, housekeeping or sound, while others might just need small fixes like the color or xrandr plugins. The a11y story under wayland is still fuzzy but IMO slow, bounce and sticky keys can be implemented on clients while mouse keys and hover-to-click clearly belong in the compositor. This means that the a11-keyboard plugin will likely need to be split so that slow, bounce and sticky keys are still configured in xwayland while mouse keys isn't. Of course they are all still needed in regular X sessions. The wacom plugin likely needs a bit of refacturing too but I'm not familiar with it. Does that sound like a (start) of a plan? Rui _______________________________________________ desktop-devel-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/desktop-devel-list
