GNOME Bugzilla – Bug 787804
range of scroll-wheel-emulation-button too small
Last modified: 2017-10-26 11:00:22 UTC
Created attachment 359942 [details] [review] Patch to increase size the range for scroll-wheel-emulation-button in org.gnome.desktop.peripherals.trackball (schemas/org.gnome.desktop.peripherals.gschema.xml.in) is too small for libinput buttons I own a Logitech Marble Trackball and would like to use it with gnome on wayland. To use scrolling effectively, I need to set the scroll method of libinput to button and set the scroll button to BTN_SIDE, which is 275. This is not covered by the range. Possible values can be found here: https://cgit.freedesktop.org/wayland/libinput/tree/include/linux/input.h
Carlos, Peter? Could you also check whether there's any other similar problems in gsettings-desktop-schemas?
KEY_MAX is currently 0x2ff, so you could consider clamping it to that. As it's looking now, devices are unlikely to have a button beyond that (or even near that) that can be used for button scrolling. this setting cannot currently work in wayland with the low limit because none of the BTN_* defines have a value below 0x110. But there's a separate bug on top of that: mutter as of ba194bd19e2f9bb045bf0a14b94429745fb27a66 (today) passes that value to the libinput xorg driver. That driver expects an X button number (hence the schema's 24 range), setting it to anything higher won't work across the backends. libinput expects the raw button number, so setting it to a sequential button number won't work.
also, fwiw, couldn't find any other schema that may be affected
(In reply to Bastien Nocera from comment #1) > Carlos, Peter? > > Could you also check whether there's any other similar problems in > gsettings-desktop-schemas? Other settings are good here. Just the tablet pad button mapping settings do something similar, and buttons are sequentially numbered in both backends for those. (In reply to Peter Hutterer from comment #2) > But there's a separate bug on top of that: mutter as of > ba194bd19e2f9bb045bf0a14b94429745fb27a66 (today) passes that value to the > libinput xorg driver. That driver expects an X button number (hence the > schema's 24 range), setting it to anything higher won't work across the > backends. libinput expects the raw button number, so setting it to a > sequential button number won't work. Can we at least assume X will label BTN_ buttons sequentially (except the 4-7 range of course)? I don't like much sticking to X semantics in settings, but it should be consistent across sessions, and seems easier to figure out this way than the other way around.
> Can we at least assume X will label BTN_ buttons sequentially (except the 4-7 range of course)? yep, the libinput driver sets the number of buttons based on the highest event code and maps them accordingly. So if you have BTN_EXTRA, you will get 9 buttons, regardless of whether you have BTN_SIDE or not (LMR + 4 scroll + side + extra). I don't think that behaviour will change, it's just not really worth it and almost all hardware has the buttons in sequential order anyway. Note that the above applies for pointer devices only (i.e. mice), tablets have different rules but that doesn't matter here anyway.
Could one of you please review the patch? Because it's unclear whether it's an ack or a nack.
Comment on attachment 359942 [details] [review] Patch to increase size Right, sorry. This is nack, IMHO it makes sense to keep settings consistent across backends. I think mutter/wayland can work out the BTN evcode out of the current setting, I'm now looking how to fix it there.
(In reply to Carlos Garnacho from comment #7) > Comment on attachment 359942 [details] [review] [review] > Patch to increase size > > Right, sorry. This is nack, IMHO it makes sense to keep settings consistent > across backends. I think mutter/wayland can work out the BTN evcode out of > the current setting, I'm now looking how to fix it there. OK, let me reassign this to mutter, where the fix would ultimately live.
Created attachment 360918 [details] [review] backends/native: Fix handling of trackball settings The org.gnome.desktop.peripherals.trackball.scroll-wheel-emulation-button setting contains buttons X11-style. Work out the BTN evcode that applies to it when applying the setting on the libinput device.
Review of attachment 360918 [details] [review]: ACK
Oops, the button>0 case needs method = ON_BUTTON_DOWN, fixed locally.
Pushed to master after some time forgotten in a branch... gnome-3-26 shall follow. Attachment 360918 [details] pushed as c71faff - backends/native: Fix handling of trackball settings