GNOME Bugzilla – Bug 747931
Available scroll method should be checked before setting
Last modified: 2021-07-05 13:49:25 UTC
G_DESKTOP_TOUCHPAD_SCROLL_METHOD_TWO_FINGER_SCROLLING should be set (regardless of gsettings value) if gsettings scroll-method is G_DESKTOP_TOUCHPAD_SCROLL_METHOD_EDGE_SCROLLING and the device supports only 2fg scroll and vice versa... Similar code in g-s-d: https://git.gnome.org/browse/gnome-settings-daemon/tree/plugins/mouse/gsd-mouse-manager.c#n767
This is necessary when there is e.g. multiple touchpad devices with different available scrolling method sets...
Created attachment 301693 [details] [review] backends/native: Set supported scroll method Proposed patch for native backend (untested).
Created attachment 301694 [details] [review] backends/x11: Set supported scroll method Proposed patch for x11 backend (untested).
(In reply to Ondrej Holy from comment #1) > This is necessary when there is e.g. multiple touchpad devices with > different available scrolling method sets... There's only one way to correctly do this in the multiple touchpad case: have per device settings. The question is, how important is that use case? Does it justify the complexity in added gsettings schemas and code to support it like we have for wacom? The wacom case is worth it because it's actually common for users to have more that one and use more than one at the same time IIUC. The case for multiple touchpads and particularly *using* multiple touchpads at the same time seems weaker to me. (In reply to Ondrej Holy from comment #0) > G_DESKTOP_TOUCHPAD_SCROLL_METHOD_TWO_FINGER_SCROLLING should be set > (regardless of gsettings value) if gsettings scroll-method is > G_DESKTOP_TOUCHPAD_SCROLL_METHOD_EDGE_SCROLLING and the device supports only > 2fg scroll and vice versa... The current code is already doing that implicitly. The native backend only sets the requested mode if the libinput device supports it, meaning that otherwise the device will keep its default scroll method. I suppose the X backend ends up doing the same implicitly too since it just sets a method and if the device doesn't support it I suppose the X driver will silently let the default configured.
(In reply to Rui Matos from comment #4) > (In reply to Ondrej Holy from comment #1) > > This is necessary when there is e.g. multiple touchpad devices with > > different available scrolling method sets... > > There's only one way to correctly do this in the multiple touchpad case: > have per device settings. Agree, but this involves redesign of g-c-c mouse panel... > The question is, how important is that use case? Does it justify the > complexity in added gsettings schemas and code to support it like we have > for wacom? I'm not convinced about we need this... > The wacom case is worth it because it's actually common for users to have > more that one and use more than one at the same time IIUC. > > The case for multiple touchpads and particularly *using* multiple touchpads > at the same time seems weaker to me. I can imagine that people have embedded touchpad in notebook at docking station and use another one e.g. embedded in the external keyboard... > (In reply to Ondrej Holy from comment #0) > > G_DESKTOP_TOUCHPAD_SCROLL_METHOD_TWO_FINGER_SCROLLING should be set > > (regardless of gsettings value) if gsettings scroll-method is > > G_DESKTOP_TOUCHPAD_SCROLL_METHOD_EDGE_SCROLLING and the device supports only > > 2fg scroll and vice versa... > > The current code is already doing that implicitly. The native backend only > sets the requested mode if the libinput device supports it, meaning that > otherwise the device will keep its default scroll method. I suppose the X > backend ends up doing the same implicitly too since it just sets a method > and if the device doesn't support it I suppose the X driver will silently > let the default configured. Currently a new scroll method isn't set if it isn't supported, but it doesn't set another method... Imagine usecase with one device, e.g. gsettings value is 2fg scroll, but no scroll is enabled for the device and the device supports only edge scroll. g-c-c toggle for scroll isn't sensitive, because only one method is available. So users can't enable the scroll and also scroll method is not applied by mutter, because isn't supported... But maybe it isn't necessary if every device has enabled any scroll method by default... (I agree that this code isn't really elegant, but do not have better idea how to deal with)
(In reply to Ondrej Holy from comment #5) > Currently a new scroll method isn't set if it isn't supported, but it > doesn't set another method... > > Imagine usecase with one device, e.g. gsettings value is 2fg scroll, but no > scroll is enabled for the device and the device supports only edge scroll. > g-c-c toggle for scroll isn't sensitive, because only one method is > available. So users can't enable the scroll and also scroll method is not > applied by mutter, because isn't supported... > > But maybe it isn't necessary if every device has enabled any scroll method > by default... Right, so it's a matter of defaults. Are the defaults not working? Perhaps we should improve the defaults in that case.
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/mutter/-/issues/ Thank you for your understanding and your help.