gnome-settings-daemon & wayland

[Rui Tiago Cação Matos <tiagomatos gmail com>]

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