GNOME Bugzilla – Bug 746840
touchpad spontaneously loses ability to use right click button
Last modified: 2015-06-30 17:40:39 UTC
My logitech wireless touchpad has two hidden mechanical buttons in it (on the bottom corners). Normally the left corner left clicks and the right corner right clicks. Spontaneously (for instance when i start hexchat), the right corner starts delivering left click. Once it breaks, it stays broken until I log out. I did some digging and I eventually found this code: https://git.gnome.org/browse/mutter/tree/src/backends/x11/meta-input-settings-x11.c?id=3a2920d4bc13fbff6ee8da4de691d258ed6412cd#n202 ... case G_DESKTOP_TOUCHPAD_CLICK_METHOD_DEFAULT: /* XXX: We can't be much smarter yet, x11 doesn't expose default settings */ case G_DESKTOP_TOUCHPAD_CLICK_METHOD_FINGERS: values[1] = 1; break; ... The CLICK_METHOD_FINGERS disables soft button areas on the touchpad (soft button areas are counter-intuitively required to make the physical buttons work on a logitech device). CLICK_METHOD_FINGERS is only normally used for macbooks. In fact, the driver default has this: if (libevdev_get_id_vendor(tp->device->evdev) == VENDOR_ID_APPLE)• → → return LIBINPUT_CONFIG_CLICK_METHOD_CLICKFINGER;• → else• → → return LIBINPUT_CONFIG_CLICK_METHOD_BUTTON_AREAS;• The comment above says mutter can't be smarter, since there's no way to get the default settings. There is, though, since we just need to query the settings at startup. The current settings at startup time are the defaults. Ideally we should also restore the defaults at shutdown to make sure gnome-shell --replace works properly, but that's bonus points.
(In reply to Ray Strode [halfline] from comment #0) > My logitech wireless touchpad has two hidden mechanical buttons in it (on > the bottom corners). > > Normally the left corner left clicks and the right corner right clicks. > > Spontaneously (for instance when i start hexchat), the right corner starts > delivering left click. Once it breaks, it stays broken until I log out. > > I did some digging and I eventually found this code: > > https://git.gnome.org/browse/mutter/tree/src/backends/x11/meta-input- > settings-x11.c?id=3a2920d4bc13fbff6ee8da4de691d258ed6412cd#n202 > > ... > case G_DESKTOP_TOUCHPAD_CLICK_METHOD_DEFAULT: > /* XXX: We can't be much smarter yet, x11 doesn't expose default > settings */ > case G_DESKTOP_TOUCHPAD_CLICK_METHOD_FINGERS: > values[1] = 1; > break; > ... Hmm. I wonder if that default-means-click-fingers (which is the opposite of the default in all PC laptops a, and not supported on touchpads without buttonpads under the touchpad) was deliberate or not. Anyway, are you saying this code here gets called spontaneously for example when starting hexchat? That sounds a bit odd. Otherwise this sounds like a libinput bug, rather than a bug in mutter. > > The CLICK_METHOD_FINGERS disables soft button areas on the touchpad (soft > button areas are counter-intuitively required to make the physical buttons > work on a logitech device). CLICK_METHOD_FINGERS is only normally used for > macbooks. In fact, the driver default has this: The physical buttons may simply just be one button which uses on the finger position to determine whether a press should be right or left click. This is what BUTTON_AREAS click method does. CLICKFINGER disables the area based detection and counts the number of touching fingers to determine whether a press should be right or left click. Assuming your device is the kind that uses the finger position to determine the type of click, you'd need to use the BUTTON_AREAS method. > > if (libevdev_get_id_vendor(tp->device->evdev) == VENDOR_ID_APPLE)• > → → return LIBINPUT_CONFIG_CLICK_METHOD_CLICKFINGER;• > → else• > → → return LIBINPUT_CONFIG_CLICK_METHOD_BUTTON_AREAS;• > > The comment above says mutter can't be smarter, since there's no way to get > the default settings. There is, though, since we just need to query the > settings at startup. The current settings at startup time are the defaults. > Ideally we should also restore the defaults at shutdown to make sure > gnome-shell --replace works properly, but that's bonus points.
(In reply to Jonas Ådahl from comment #1) > Hmm. I wonder if that default-means-click-fingers (which is the opposite of > the default in all PC laptops a, and not supported on touchpads without > buttonpads under the touchpad) was deliberate or not. I think so, but clearly the right way forward is to just use the X server default for the default setting. > Anyway, are you saying this code here gets called spontaneously for example > when starting hexchat? That sounds a bit odd. Yea, I didn't track down why. The key point is the code doesnt run at login, but only later, so the driver defaults (which are right) get used until the function runs and then the right click button works no more, and I have to right click with two finger touch. > Otherwise this sounds like a libinput bug, rather than a bug in mutter. You lost me. How could this be a libinput bug? libinput is just doing what it's incorrectly being told to do (use CLICK_METHOD_FINGERS) > The physical buttons may simply just be one button which uses on the finger > position to determine whether a press should be right or left click. This is > what BUTTON_AREAS click method does. yup, exactly. > CLICKFINGER disables the area based > detection and counts the number of touching fingers to determine whether a > press should be right or left click. right, we're on the same page. > Assuming your device is the kind that > uses the finger position to determine the type of click, you'd need to use > the BUTTON_AREAS method. which the driver correctly picks from the code snippet i pasted: > > > > if (libevdev_get_id_vendor(tp->device->evdev) == VENDOR_ID_APPLE)• > > → → return LIBINPUT_CONFIG_CLICK_METHOD_CLICKFINGER;• > > → else• > > → → return LIBINPUT_CONFIG_CLICK_METHOD_BUTTON_AREAS;• The thing to realize is users will always have click-method set to G_DESKTOP_TOUCHPAD_CLICK_METHOD_DEFAULT. we don't expose that setting in the UI, just gsettings. So it's a genuine mutter bug that DEFAULT hardcodes CLICKFINGER, instead of, say, using the default queried from the X server at startup
(In reply to Ray Strode [halfline] from comment #2) > (In reply to Jonas Ådahl from comment #1) > > Hmm. I wonder if that default-means-click-fingers (which is the opposite of > > the default in all PC laptops a, and not supported on touchpads without > > buttonpads under the touchpad) was deliberate or not. > I think so, but clearly the right way forward is to just use the X server > default for the default setting. > > > Anyway, are you saying this code here gets called spontaneously for example > > when starting hexchat? That sounds a bit odd. > Yea, I didn't track down why. The key point is the code doesnt run at login, > but only later, so the driver defaults (which are right) get used until the > function runs and then the right click button works no more, and I have to > right click with two finger touch. Sounds like two bugs then: one that the configuration is applied at login, and the other that "default" incorrectly overrides the default configuration. > > > Otherwise this sounds like a libinput bug, rather than a bug in mutter. > You lost me. How could this be a libinput bug? libinput is just doing what > it's incorrectly being told to do (use CLICK_METHOD_FINGERS) I meant that if this code was *not* run at the time the issue happened, it'd be a bug in libinput, but if the reason is the spontaneous configuration then its not a bug in libinput. > > > The physical buttons may simply just be one button which uses on the finger > > position to determine whether a press should be right or left click. This is > > what BUTTON_AREAS click method does. > yup, exactly. > > > CLICKFINGER disables the area based > > detection and counts the number of touching fingers to determine whether a > > press should be right or left click. > right, we're on the same page. > > > Assuming your device is the kind that > > uses the finger position to determine the type of click, you'd need to use > > the BUTTON_AREAS method. > which the driver correctly picks from the code snippet i pasted: > > > > > > > if (libevdev_get_id_vendor(tp->device->evdev) == VENDOR_ID_APPLE)• > > > → → return LIBINPUT_CONFIG_CLICK_METHOD_CLICKFINGER;• > > > → else• > > > → → return LIBINPUT_CONFIG_CLICK_METHOD_BUTTON_AREAS;• > > The thing to realize is users will always have click-method set to > G_DESKTOP_TOUCHPAD_CLICK_METHOD_DEFAULT. we don't expose that setting in > the UI, just gsettings. So it's a genuine mutter bug that DEFAULT hardcodes > CLICKFINGER, instead of, say, using the default queried from the X server at > startup
(In reply to Jonas Ådahl from comment #3) > (In reply to Ray Strode [halfline] from comment #2) > > (In reply to Jonas Ådahl from comment #1) > > > Hmm. I wonder if that default-means-click-fingers (which is the opposite of > > > the default in all PC laptops a, and not supported on touchpads without > > > buttonpads under the touchpad) was deliberate or not. > > I think so, but clearly the right way forward is to just use the X server > > default for the default setting. > > > > > Anyway, are you saying this code here gets called spontaneously for example > > > when starting hexchat? That sounds a bit odd. > > Yea, I didn't track down why. The key point is the code doesnt run at login, > > but only later, so the driver defaults (which are right) get used until the > > function runs and then the right click button works no more, and I have to > > right click with two finger touch. > > Sounds like two bugs then: one that the configuration is applied at login, > and the other that "default" incorrectly overrides the default configuration. Err, meant *not* applied at login.
Hi, > Sounds like two bugs then: one that the configuration is applied at login, > and the other that "default" incorrectly overrides the default configuration. yea > I meant that if this code was *not* run at the time the issue happened, it'd > be a bug in libinput, but if the reason is the spontaneous configuration > then its not a bug in libinput. Ah, I see what you were saying now.
Indeed, the setting isn't applied at login. My touchpad defaults to button-areas, but I want clickfinger since my touchpad is smooth. On X11 I can alter the default via Xorg config, but on Wayland I need to depend on mutter to do this.
xf86-input-libinput exports the "libinput something Default" properties now to get the default from libinput at runtime. http://cgit.freedesktop.org/xorg/driver/xf86-input-libinput/commit/?id=8d4e03570cbdbb53bae57452614cbe45b6eb46f8 sorry about the delay, i released 0.9.0 today so that should make its way through the distros soonish.
Isn't this fixed in 3.16.1 ?
i don't believe so.
So this bug is just about that /* XXX: We can't be much smarter yet, x11 doesn't expose default settings */ case? In that case it will be fixed shortly. But there seems to be some more talk here about settings not being applied at login, which should be fixed in 3.16.1 already.
yup, cool.
Has there been any update here?
https://git.gnome.org/browse/mutter/commit/?id=dac30a222ed9ddbb0be519be948c80d4f0cf303c
I thought I saw a fix go by, thanks.
Though, I believe this gives us the libinput default not the Xorg default (which might be different because of xorg.conf changes), so (I think?) some users will still end up in a situation where their config may spontaneously change.
Peter, does xf86-input-libinput factor in xorg.conf changes when figuring out what to set the property to?
no, that was a conscious decision we made when adding the Default property to reset it to HW defaults (well, libinput defaults). see https://bugs.freedesktop.org/show_bug.cgi?id=89574 I guess the argument here is that if GNOME overrides the configuration anyway, changes should be made there rather than stacking configuration methods.
So comment 15 was wrong about "spontaneously changes" since I believe we do apply the setting at login time now. Still, I think the argument mentioned in comment 17 is wrong. Why would we ignore xorg.conf ? We don't for other settings. Peter are you okay with changing it? Bastien are you okay with it getting changed?
(In reply to Ray Strode [halfline] from comment #18) > So comment 15 was wrong about "spontaneously changes" since I believe we do > apply the setting at login time now. > > Still, I think the argument mentioned in comment 17 is wrong. Why would we > ignore xorg.conf ? We don't for other settings. We do ignore it for plenty of settings, where we overwrite them. It also wouldn't work with Wayland.
i'm not going to argue too strongly since it ultimately won't matter in a wayland future, but I can't think of a good reason to override. there's no pro's and obvious cons
If xorg.conf and gsettings disagree, which do we pick? There's also no way to tell what the xorg.conf setting is, or whether it was set by a conf file.
(In reply to Jasper St. Pierre from comment #21) > If xorg.conf and gsettings disagree, which do we pick? gsettings of course. This whole bug is about what to do when gsettings is set to the "use the system default" setting. > There's also no way to tell what the xorg.conf setting is, or whether it was set by a conf file. There are two distinct, and viable ways identified in this very report: - read the value at start up. (see last two sentences of comment 0), - updating the property provided by xf86-input-libinput to account for the xorg.conf (which it's already reading after all). Note that property was added for this bug. It's not a question of "can't", it's a question of "didn't, but why?" (see comment 17). Anyway, already had a debate about this on IRC. bottom line is it doesn't really matter. it's a corner case, and that corner case will be gone in a year anyway when we've all jumped on the wayland train.