Red Hat Bugzilla – Bug 1035469
clickpad with trackpoint doesn't have top buttons by default
Last modified: 2014-01-17 23:20:46 EST
Fedora 20 beta, T440s with clickpad.
During the install and after rebooting into the OS, the touchpad is one big left button. Necessary to manually edit the X config file to get middle or right click. Should default to something more likely to be useful. I ended up with this config:
Option "SoftButtonAreas" "55% 0 0 0 35% 55% 0 0"
Which is not EXACTLY where the paint on the T440s shows the buttons, but I got tired of messing with it and it's close enough.
I think a good default would at least set the right 30-40% of the touchpad to right click, even though it's impossible to know where a given laptop has paint. Defaults could skip middle button, maybe, or make it pretty small.
It's sort of hard to figure out the best config experimentally because the touchpad seems to have sort of fuzzy boundaries for where it registers the click; maybe it's my imagination but if I move my finger slowly to the right while clicking, it seems to count a wider area as left button, while if I move my finger slowly left while clicking, it counts a wider area as right button.
Not sure what's going on but I just can't get consistent results when trying to determine where the boundary is by clicking.
we usually set the default on clickpads 50/50 split vertically, on the bottom 18%. that's set if the INPUT_PROP_BUTTONPAD is set so I'm surprised you ended up with one big left button only.
can you attach your log and the evemu-describe output of the touchpad please? Thanks.
on a longer note: we can't easily match to the t440s because they look the same, patches are in the works for the next xserver but until then you'll have to manually configure the lot, sorry.
correction, we can detect this. Please give these rpms a test. The interesting bits are in the rules file and the .conf file but I had to take a guess in both.
First, the t440 should match in the udev rule, please check udevadm info --export-db to see if the INPUT_ID.tags is applied to the touchpad.
The xorg.conf.d snippet configures the top 20% as buttons, with the middle button being 20% in the middle of the touchpad. not sure if that's in-line with the actual painted buttons, I'm operating off a photo only here.
Thanks, you are right that the bottom-right corner is a right button. I must not have clicked there when installing because the touchpad is big and the bottom right is far from the trackpoint, so it's almost physically impossible.
Will try the RPMs.
Before reading your latest comment, I had just recorded the evemu-describe and screenshotted the user manual showing the default config on windows, so I'll attach those just in case they are useful.
I measured with a ruler and it is a 10cm pad and the middle button is marked with raised bumps 2cm wide in the middle. So 20% is correct, though my current config of "60% 0 0 0 40% 60% 0 0" doesn't seem to quite match the physical 60% and 40% points, fwiw. (It's sort of hard to tell - fingers too fat.)
Created attachment 835577 [details]
evemu-describe for touchpad
Created attachment 835578 [details]
evemu-describe for trackpoint
Created attachment 835579 [details]
default config on windows
Created attachment 835581 [details]
udevadm info --export-db output with 1.7.2-3
reassigning to right component, now I know why I didn't see this earlier...
Thanks for the Windows config, this means we'll have to split the device as a whole, we don't support multiple independent button areas. So I'll drop the 20% parts of the configuration and use your 60/40/0 as above. I've had reports about the actual extents of the touchpad being quite off from what's being reported, that may account for the mismatch of the buttons.
(In reply to Havoc Pennington from comment #7)
> Created attachment 835581 [details]
> udevadm info --export-db output with 1.7.2-3
ok, I matched on the wrong thing. in /usr/lib/udev/rules.d/70-touchpad-quirks.rules, please replace product_name with product_version and t440 with T440.
udevadm trigger --action=change --verbose --subsystem-match=input
should apply that, and you should see the ID_INPUT.tags applied to the synaptics device with:
udevadm info -n /dev/input/event3
with that rule change,
$ udevadm info -n /dev/input/event3 | grep tags
xorg-x11-drv-synaptics-1.7.1-6.fc20 has been submitted as an update for Fedora 20.
xorg-x11-drv-synaptics-1.7.1-6.fc19 has been submitted as an update for Fedora 19.
* should fix your issue,
* was pushed to the Fedora 20 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing xorg-x11-drv-synaptics-1.7.1-6.fc20'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).
xorg-x11-drv-synaptics-1.7.1-6.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
can you please backport this onto F19.
FOr the moment I'm still stuck on F19 and I'd _really_ like this fix as well since the default behaviour is thoroughly annoying ;-)
Ferry: please see Comment 11
ah, sorry. missed that :-)
xorg-x11-drv-synaptics-1.7.1-6.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.