Wayland support in gnome-settings-daemon

gnome-settings-daemon is organized in plugins; these take care of many tasks that need a long-running process in the session. Some of these tasks are essentially just applying settings that are stored in GSettings to configure the display server (ie X). In a Wayland world, the roles of display server and compositing manager are merged, and these tasks can just be handled inside the compositor (ie gnome-shell).

Moving code into GNOME shell were it makes sense can be done ahead of an actual Wayland implementation. Doing so will make the transition easier, GNOME shell can then either apply the settings internally when run as a Wayland compositor, or configure the X server when running under X.

Here is a look at the individual gnome-settings-daemon plugins.

a11y keyboard

This plugin is applying settings to configure keyboard accessibility features (AccessX) in the X server. These features have to be reimplemented in the input handling layer of the Wayland compositor, and it makes sense to apply the settings there as well.

a11y settings

The sole purpose of this plugin is to enable the toolkit-accessibility setting for GTK+ 2 clients when either the screen reader or the screen keyboard are enabled. This could just as well be done in gnome-shell.

background

Already gone.

clipboard

A clipboard manager. The clipboard manager interface will need adjustments for Wayland.

color

  • Listens to device-added/-removed signals from colord and applies user-specific device color calibration.
  • Watches the per-user ICC profiles and registers them with the daemon.

The first point for applying color profiles to a monitor will have to be updated for Wayland, and has already been written and reviewed for the Weston compositor. A similar patch will be needed for gnome-shell. The second part of the plugin can remain unchanged, so perhaps splitting the color profile into color-profiles and color-x11 might be a good idea.

cursor

Hides the cursor when appropriate (mouse is not in use, or on touchscreens, etc). In a Wayland world, this needs to be done in the compositor.

housekeeping

Removes temporary files and clean up trash. No change under Wayland.

keyboard

Applies input configuration to the X server (XKB) and IBus. Both of these things are probably better off in the compositor under Wayland.

media keys

Implements global keyboard shortcuts. The actual key grabbing is already done in GNOME shell, via the org.gnome.Shell.KeyGrabber D-Bus interface.

mouse

Launches mousetweaks and gsd-locate-pointer as required and applies settings to input devices (mouse and touchpad). Under Wayland, the mouse accessibility features and the locate pointer need to be implemented in the compositor, and the settings naturally belong there as well.

orientation

Listens to accelerometer events and applies orientation changes via XRANDR. Easier to do in the compositor under Wayland.

power

Applies various power-related settings, e.g. initiating suspend, or dimming the screen. It also forwards upower status to GNOME shell. The code that is using XRANDR to learn about lid close status and to apply brightness settings will have to be adapted under Wayland, and may be better off in the compositor.

Translates cups messages into notifications. No change under Wayland.

remote display

Updates animation settings when it thinks we are on a remote display. The code that tries to detect Xvnc will need to be adjusted.

screensaver proxy

Implements org.freedesktop.ScreenSaver D-Bus api by forwarding to org.gnome.ScreenSaver in GNOME shell. Could just as well be implemented in the same place.

smartcard

TBD

sound

Does nothing but flushing the pulseaudio sample cache if the sound theme changes. Not sure if this is even necessary.

updates

Checks PackageKit for software updates periodically and sends notifications. No change under Wayland.

wacom

TBD

xrandr

TBD

xsettings

TBD

Initiatives/Wayland/gnome-settings-daemon (last edited 2013-11-22 20:55:37 by WilliamJonMcCann)