Hide Forgot
Description of problem: I'm using fedora 22 on Dell Vostro 5470. The touchpad works fine, except for the right key. This right key is not working at all. Version-Release number of selected component (if applicable): kernel-4.0.0-1.fc22.x86_64 How reproducible: Always Steps to Reproduce: 1. Install fedora 22 on dell vostro 5470 2. Update (or not) you system 3. Actual results: right key does not work Expected results: Right key works normally. Additional info: xev output: ButtonPress event, serial 36, synthetic NO, window 0x1a00001, root 0xeb, subw 0x0, time 390538, (104,65), root:(199,220), state 0x0, button 1, same_screen YES ButtonRelease event, serial 36, synthetic NO, window 0x1a00001, root 0xeb, subw 0x0, time 390653, (104,65), root:(199,220), state 0x100, button 1, same_screen YES $ dmesg | grep elan: [ 1.391531] psmouse serio1: elantech: assuming hardware version 4 (with firmware version 0x361f05) [ 1.405507] psmouse serio1: elantech: Synaptics capabilities query result 0x00, 0x15, 0x0e.
Hi, Can you please do: sudo dnf install evemu-record sudo evemu-record <note which event# device is your touchpad> <press ctrl+c> sudo evemu-record /dev/input/event# > touchpad-rightclick.log <click the right button area of the touchpad once> <press ctrl+c> And then attach touchpad-rightclick.log here? Thanks, Hans
Created attachment 1017914 [details] evemu-record
Hi, The log looks fine, weird that things are note working. Can you please do: sudo dnf install libevdev-utils And then run touchpad-edge-detector on your touchpad, and post the output here? Regards, Hans
This was the return: Kernel says: x [0..3420], y [0..2223] Touchpad sends: x [0..3420], y [0..2223]
Hi again, And that looks good to, weird. Can you please do: xinput list And then: xinput list-props <id> Where the id is the id for your touchpad, and then copy and paste the output of the second command to a comment here in bugzilla ? Thanks, Hans
Thanks Hans, here it goes: $xinput list-props 13 Device 'ETPS/2 Elantech Touchpad': Device Enabled (139): 1 Coordinate Transformation Matrix (141): 1.000000, 0.000000, 0.000000, 0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000 libinput Tapping Enabled (273): 1 libinput Accel Speed (274): 0.215054 libinput Natural Scrolling Enabled (275): 1 libinput Send Events Modes Available (259): 1, 1 libinput Send Events Mode Enabled (260): 0, 0 libinput Left Handed Enabled (276): 0 libinput Scroll Methods Available (277): 1, 0, 0 libinput Scroll Method Enabled (278): 1, 0, 0 libinput Click Methods Available (279): 1, 1 libinput Click Method Enabled (280): 0, 1 Device Node (261): "/dev/input/event5" Device Product ID (262): 2, 14
Hi again. Ah yes, somehow you've configured your touchpad for clickfinger, so to rightclick you can click anywhere on the pad with 2 fingers (instead of clicking with 1 finger). To change this setting from the cmdline do: xinput set-prop 13 'libinput Click Method Enabled' 1 0 And then your right bottom area should give you right clicks with a single finger again. As for why this was changed, that is a good question. Which desktop environment are you running? And try looking into your desktop environment mouse settings and see if you can change this there (use xinput list-props to see if anything has changed). Regards, Hans
Thanks man, that is it! I'm using gnome 3.16 and yes, I set Touch to Click but it usually does not affect the right click behavior (weird). After set the Click Method Enabled (there is not a graphical way to set this, I guess), I can use the right click and the touch to click as well.
(In reply to Hans de Goede from comment #7) > Ah yes, somehow you've configured your touchpad for clickfinger, so to > rightclick you can click anywhere on the pad with 2 fingers (instead of > clicking with 1 finger). > Hmm, I bet this has something to do with mutter: https://git.gnome.org/browse/mutter/tree/src/backends/x11/meta-input-settings-x11.c#n202 This is a known bug (not sure with have a bug number though) and should be fixed in a future release of mutter. Right now, this piece of code is randomly called by mutter (I am not sure what triggers it), but it will revert back the settings to a clickpad each time this happens. You should be able to force the software buttons by calling: $> gsettings set org.gnome.desktop.peripherals.touchpad click-method 'areas' Moving the bug to mutter then.
*** Bug 1218805 has been marked as a duplicate of this bug. ***
Confirming this issue is there also for Fedora 23.
(In reply to Jan Vlug from comment #11) > Confirming this issue is there also for Fedora 23. Can you try the workaround from comment 7 ?
I already applied the work-around from commment #9. That one works. The issue appeared probably after fiddling with the touchpad settings in gnome settings. If it is helpful, can can try to reproduce it.
I guess you don't have the original gsettings anymore, but if you can reproduce what changes the return value of gsettings get org.gnome.desktop.peripherals.touchpad click-method then we can narrow down what's happening.
IIRC, there was a problem with the default value. The weird part is that there is a patch that seems to fetch the default value at launch[1]. In the code I pointed at (before dac30a22, looking at the timestamps), the default code was to rely on clickfinger by default. Now, I would expect mutter to not turn the default value back to clickfinger given that the code has been integrated for a while now (unless the xorg part is not working accordingly). [1] https://git.gnome.org/browse/mutter/commit/src/backends/x11/meta-input-settings-x11.c?id=dac30a222ed9ddbb0be519be948c80d4f0cf303c
This is working by default on fedora 24, so I think we can close the bug,