GNOME Bugzilla – Bug 739411
Adopt peripherals' settings schemas from gnome-settings-daemon
Last modified: 2014-12-11 15:16:47 UTC
In order to prepare for wayland, there is a plan to make mutter take control over windowing-level device configuration. As such the settings schemas will be shared across gnome-settings-daemon, gnome-control-center, and mutter itself. This calls for a better place to have these. I'm attaching a patch that moves these schemas to gsettings-desktop-schemas. The ID/path remains the same in order to preserve compatibility.
Created attachment 289678 [details] [review] schemas: Adopt peripherals' gschemas from gnome-settings-daemon Now that mutter is potentially looking for these settings, it makes sense to have this at a more generic place than gnome-settings-daemon. The schema ID/path hasn't been changed in order to remain compatible after the switch. The only change to schemas has been around enum values, which are now offered by gdesktop-enums.h
Review of attachment 289678 [details] [review]: ::: headers/gdesktop-enums.h @@ +165,3 @@ +typedef enum +{ + G_DESKTOP_SMARTCARD_REMOVAL_ACTION_NONE, I don't think we want or need to move the smartcard configuration options here. @@ +179,3 @@ +typedef enum +{ + G_DESKTOP_BELL_MODE_ON, Is that still relevant with libinput? @@ +193,3 @@ +typedef enum +{ + G_DESKTOP_WACOM_ROTATION_NONE, We shouldn't move the wacom code yet. @@ +209,3 @@ +typedef enum +{ + G_DESKTOP_NUM_LOCK_STATE_UNKNOWN, I don't think we should be using GSettings to store the num-lock state anymore. ::: schemas/org.gnome.settings-daemon.peripherals.gschema.xml.in.in @@ +1,2 @@ +<schemalist> + <schema gettext-domain="@GETTEXT_PACKAGE@" id="org.gnome.settings-daemon.peripherals" path="/org/gnome/settings-daemon/peripherals/"> Needs to use IDs and paths without "settings-daemon" in them. @@ +17,3 @@ + </schema> + <schema gettext-domain="@GETTEXT_PACKAGE@" id="org.gnome.settings-daemon.peripherals.touchpad" path="/org/gnome/settings-daemon/peripherals/touchpad/"> + <key name="disable-while-typing" type="b"> That's not going to survive the switch to libinput. @@ +52,3 @@ + <description>Acceleration multiplier for mouse motion. A value of -1 is the system default.</description> + </key> + <key name="motion-threshold" type="i"> libinput doesn't use separate motion-acceleration/motion-threshold. @@ +57,3 @@ + <description>Distance in pixels the pointer must move before accelerated mouse motion is activated. A value of -1 is the system default.</description> + </key> + <key name="natural-scroll" type="b"> libinput will get support for mice as well. This probably needs to move to a more generic schema. @@ +64,3 @@ + </schema> + <schema gettext-domain="@GETTEXT_PACKAGE@" id="org.gnome.settings-daemon.peripherals.keyboard" path="/org/gnome/settings-daemon/peripherals/keyboard/"> + <key name="repeat" type="b"> Missing a summary. @@ +67,3 @@ + <default>true</default> + </key> + <key name="click" type="b"> Ditto. @@ +75,3 @@ + <description>Delay between repeats in milliseconds.</description> + </key> + <key name="delay" type="u"> Do repeat-interval and delay match what libinput uses to configure keyboard repeat? @@ +80,3 @@ + <description>Initial key repeat delay in milliseconds.</description> + </key> + <key name="click-volume" type="i"> What's click-volume? I have no idea what it means even in X... @@ +85,3 @@ + <key name="bell-mode" enum="org.gnome.desktop.GDesktopBellMode"> + <default>'on'</default> + <description>Possible values are "on", "off", and "custom".</description> I don't know what custom is supposed to do, but we don't use it at all anywhere in g-s-d. @@ +87,3 @@ + <description>Possible values are "on", "off", and "custom".</description> + </key> + <key name="bell-pitch" type="i"> How will the bell configuration be handled in mutter/libinput? @@ +98,3 @@ + <description>File name of the bell sound to be played.</description> + </key> + <key name="remember-numlock-state" type="b"> This... @@ +103,3 @@ + <description>When set to true, GNOME will remember the state of the NumLock LED between sessions.</description> + </key> + <key name="numlock-state" enum="org.gnome.desktop.GDesktopNumLockState"> ...and this probably shouldn't be in GSettings, they're state, not configuration. And we should always remember num-lock state. @@ +110,3 @@ + </schema> + <schema gettext-domain="@GETTEXT_PACKAGE@" id="org.gnome.settings-daemon.peripherals.mouse" path="/org/gnome/settings-daemon/peripherals/mouse/"> + <key name="locate-pointer" type="b"> Locate pointer isn't really a mouse feature, it's a compositor feature. This should be moved to another schema. @@ +119,3 @@ + <description>Swap left and right mouse buttons for left-handed mice.</description> + </key> + <key name="motion-acceleration" type="d"> Ditto about acceleration/threshold. @@ +129,3 @@ + <description>Distance in pixels the pointer must move before accelerated mouse motion is activated. A value of -1 is the system default.</description> + </key> + <key name="double-click" type="i"> This isn't a "peripheral" setting per se @@ +134,3 @@ + <_description> Length of a double click in milliseconds.</_description> + </key> + <key name="drag-threshold" type="i"> Ditto. @@ +159,3 @@ + </schema> + <schema gettext-domain="@GETTEXT_PACKAGE@" id="org.gnome.settings-daemon.peripherals.input-devices" path="/org/gnome/settings-daemon/peripherals/input-devices/"> + <key name="hotplug-command" type="s"> Will this be used in mutter for X11? I don't think this is translatable to wayland, as all the libinput features will be implemented by gnome-shell.
Created attachment 291191 [details] [review] schemas: Adopt peripherals' gschemas from gnome-settings-daemon Now that mutter is potentially looking for these settings, it makes sense to have this at a more generic place than gnome-settings-daemon. Together with the settings relocation, there has been a settings cleanup and schema/path changes, users are expected to catch up with these. The list of changes is: - keyboard bell settings have been removed - numlock state settings have been removed, deemed as not belonging to configuration - motion threshold/acceleration have been merged in a single "speed" setting - a natural scroll setting has been added to mice - double click/drag thresholds have been removed, not considered a peripheral setting - hotplug commands have been removed, not so useful and not much of a good idea security wise on wayland. - "middle-button-enabled" setting has been renamed to a more intuitive "emulate-middle-button" - settings path has been removed from the touchscreens schema, each touchscreen is expected to have its own path, the schema now contains a "display" setting to which the touchscreen will be mapped. The previous "orientation-lock" setting is actually a toggle for the accelerometer and does not belong here.
I've finally added most suggestions, and made some changes on touchscreens that will help head the right direction here. Just a minor comment: (In reply to comment #2) > @@ +17,3 @@ > + </schema> > + <schema gettext-domain="@GETTEXT_PACKAGE@" > id="org.gnome.settings-daemon.peripherals.touchpad" > path="/org/gnome/settings-daemon/peripherals/touchpad/"> > + <key name="disable-while-typing" type="b"> > > That's not going to survive the switch to libinput. I think this is doable in the compositor, and you could even have finer control over it (ie. unlock the pointer when a really bold move is being done, as opposed to the expected noise)
(In reply to comment #4) > I've finally added most suggestions, and made some changes on touchscreens that > will help head the right direction here. Just a minor comment: > > (In reply to comment #2) > > @@ +17,3 @@ > > + </schema> > > + <schema gettext-domain="@GETTEXT_PACKAGE@" > > id="org.gnome.settings-daemon.peripherals.touchpad" > > path="/org/gnome/settings-daemon/peripherals/touchpad/"> > > + <key name="disable-while-typing" type="b"> > > > > That's not going to survive the switch to libinput. > > I think this is doable in the compositor, and you could even have finer control > over it (ie. unlock the pointer when a really bold move is being done, as > opposed to the expected noise) No, libinput has code to do that, and it does it automatically. There's no "disable while typing" toggle in libinput IIRC.
Review of attachment 291191 [details] [review]: ::: schemas/org.gnome.desktop.peripherals.gschema.xml.in.in @@ +6,3 @@ + <child name="trackball" schema="org.gnome.desktop.peripherals.trackball"/> + <child name="touchscreen" schema="org.gnome.desktop.peripherals.touchscreen"/> + <child name="input-devices" schema="org.gnome.desktop.peripherals.input-devices"/> There's no "input-devices" schema in this file. @@ +77,3 @@ + <default>0</default> + <summary>Pointer speed</summary> + <description>Pointer speed for mice. A value of 0 is the system default.</description> What does 0 correspond to? @@ +83,3 @@ + <default>false</default> + <_summary>Middle button emulation</_summary> + <_description>Enables middle mouse button emulation through simultaneous left and right button click.</_description> clicks (if you press 2 buttons, that's 2 clicks).
(In reply to comment #2) > Review of attachment 289678 [details] [review]: > <snip> > @@ +179,3 @@ > +typedef enum > +{ > + G_DESKTOP_BELL_MODE_ON, > > Is that still relevant with libinput? libinput does nothing with the bell, as it is not really input related. > @@ +17,3 @@ > + </schema> > + <schema gettext-domain="@GETTEXT_PACKAGE@" > id="org.gnome.settings-daemon.peripherals.touchpad" > path="/org/gnome/settings-daemon/peripherals/touchpad/"> > + <key name="disable-while-typing" type="b"> > > That's not going to survive the switch to libinput. Right this is going away, we will likely use "is the user typing" information as an input to do palm detection, but this will happen under the hood. At least that is the plan for now, if somehow we cannot get our palm detection good enough we may re-introduce this, but the plan is to not have a need for it. > @@ +52,3 @@ > + <description>Acceleration multiplier for mouse motion. A value of -1 is > the system default.</description> > + </key> > + <key name="motion-threshold" type="i"> > > libinput doesn't use separate motion-acceleration/motion-threshold. Correct we've a normalized -1.0 - 1.0 scale with 0.0 meaning default, -1.0 progressively getting slower, and 1.0 getting faster. The idea here is to not expose details about the accel algorithm, so that we leave the option open to have per device accel methods, e.g. a touchpad and a mouse may end up using a different accel algorithm. > libinput will get support for mice as well. This probably needs to move to a > more generic schema. Correct, libinput will support natural scrolling on any device with a scroll axis (e.g a mouse wheel, 2fg or edge scrolling, trackpoint middle button scrolling). > @@ +75,3 @@ > + <description>Delay between repeats in milliseconds.</description> > + </key> > + <key name="delay" type="u"> > > Do repeat-interval and delay match what libinput uses to configure keyboard > repeat? libinput does not do keyboard repeat this is left up to the compositor (or toolkit) / up to X, from a scheme pov having delay and repeat-interval (or rate) sounds right though. Any implementation I can think of would use those. > @@ +80,3 @@ > + <description>Initial key repeat delay in milliseconds.</description> > + </key> > + <key name="click-volume" type="i"> > > What's click-volume? I have no idea what it means even in X... I guess this is for keyboards which have a configureable key-click sound ? I know some mice which have a touchstrip which emulates a scroll-wheel which you can configure to make a click-click-click sound (with a tiny builtin speaker) when scrolling with the touch-strip. This is a bit exotic though, it may make sense to just drop this for now. > + <description>Possible values are "on", "off", and > "custom".</description> > + </key> > + <key name="bell-pitch" type="i"> > > How will the bell configuration be handled in mutter/libinput? I don't know about mutter, from libinput pov this is: "not our problem"
Created attachment 292463 [details] [review] schemas: Adopt peripherals' gschemas from gnome-settings-daemon Now that mutter is potentially looking for these settings, it makes sense to have this at a more generic place than gnome-settings-daemon. Together with the settings relocation, there has been a settings cleanup and schema/path changes, users are expected to catch up with these. The list of changes is: - keyboard bell settings have been removed - numlock state settings have been removed, deemed as not belonging to configuration - motion threshold/acceleration have been merged in a single "speed" setting - a natural scroll setting has been added to mice - double click/drag thresholds have been removed, not considered a peripheral setting - hotplug commands have been removed, not so useful and not much of a good idea security wise on wayland. - "middle-button-enabled" setting has been removed as it doesn't have libinput configuration equivalence yet. - the touchpad-enabled setting has been renamed to a more generic "send-events", although it's still in the touchpad schema. The enum is generic and might be used on other schemas in the future. - Unlike the settings-daemon schema, each touchscreen is expected to have its own path, the schema now contains a "display" setting to which the touchscreen will be mapped. The previous "orientation-lock" setting is actually a toggle for the accelerometer, and thus removed from the touchscreen schema. - There is a very basic schema for drawing tablets (wacom and the such), only containing display mapping. Other settings would move eventually when they can be honored on libinput.
(In reply to comment #7) > (In reply to comment #2) > > Review of attachment 289678 [details] [review] [details]: > > @@ +80,3 @@ > > + <description>Initial key repeat delay in milliseconds.</description> > > + </key> > > + <key name="click-volume" type="i"> > > > > What's click-volume? I have no idea what it means even in X... > > I guess this is for keyboards which have a configureable key-click sound ? I > know some mice which have a touchstrip which emulates a scroll-wheel which you > can configure to make a click-click-click sound (with a tiny builtin speaker) > when scrolling with the touch-strip. > > This is a bit exotic though, it may make sense to just drop this for now. It's actually an accessibility feature, which would probably be handled in the compositor.
Review of attachment 292463 [details] [review]: Looks good.
Attachment 292463 [details] pushed as b5b48a8 - schemas: Adopt peripherals' gschemas from gnome-settings-daemon
(In reply to comment #9) > > > Review of attachment 289678 [details] [review] [details] [details]: > > > @@ +80,3 @@ > > > + <description>Initial key repeat delay in milliseconds.</description> > > > + </key> > > > + <key name="click-volume" type="i"> <snip> > It's actually an accessibility feature, which would probably be handled in the > compositor. I agree, for better accessibility support, there should be something akin to XBell() in the wayland protocol, so the compositor can blink, play a file, a sine wave... But that's out of the scope of this bug.