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):
Steps to Reproduce:
1. Install fedora 22 on dell vostro 5470
2. Update (or not) you system
right key does not work
Right key works normally.
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.
Can you please do:
sudo dnf install evemu-record
<note which event# device is your touchpad>
sudo evemu-record /dev/input/event# > touchpad-rightclick.log
<click the right button area of the touchpad once>
And then attach touchpad-rightclick.log here?
Created attachment 1017914 [details]
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?
This was the return:
Kernel says: x [0..3420], y [0..2223]
Touchpad sends: x [0..3420], y [0..2223]
And that looks good to, weird.
Can you please do:
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, 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
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).
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:
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.
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).
This is working by default on fedora 24, so I think we can close the bug,