Bug 1035469 - clickpad with trackpoint doesn't have top buttons by default
Summary: clickpad with trackpoint doesn't have top buttons by default
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-synaptics
Version: 20
Hardware: x86_64
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Peter Hutterer
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-11-27 20:58 UTC by Havoc Pennington
Modified: 2014-01-18 04:20 UTC (History)
5 users (show)

Fixed In Version: xorg-x11-drv-synaptics-1.7.1-6.fc20
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-12-20 01:53:03 UTC


Attachments (Terms of Use)
evemu-describe for touchpad (2.97 KB, text/plain)
2013-12-12 04:37 UTC, Havoc Pennington
no flags Details
evemu-describe for trackpoint (1.16 KB, text/plain)
2013-12-12 04:37 UTC, Havoc Pennington
no flags Details
default config on windows (125.81 KB, image/png)
2013-12-12 04:38 UTC, Havoc Pennington
no flags Details
udevadm info --export-db output with 1.7.2-3 (120.64 KB, text/plain)
2013-12-12 04:50 UTC, Havoc Pennington
no flags Details

Description Havoc Pennington 2013-11-27 20:58:40 UTC
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.

Comment 1 Peter Hutterer 2013-12-11 21:46:20 UTC
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.

Comment 2 Peter Hutterer 2013-12-12 04:27:58 UTC
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.

http://koji.fedoraproject.org/koji/taskinfo?taskID=6282408

Comment 3 Havoc Pennington 2013-12-12 04:36:27 UTC
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.)

Comment 4 Havoc Pennington 2013-12-12 04:37:05 UTC
Created attachment 835577 [details]
evemu-describe for touchpad

Comment 5 Havoc Pennington 2013-12-12 04:37:32 UTC
Created attachment 835578 [details]
evemu-describe for trackpoint

Comment 6 Havoc Pennington 2013-12-12 04:38:04 UTC
Created attachment 835579 [details]
default config on windows

Comment 7 Havoc Pennington 2013-12-12 04:50:41 UTC
Created attachment 835581 [details]
udevadm info --export-db output with 1.7.2-3

Comment 8 Peter Hutterer 2013-12-12 05:20:15 UTC
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

Comment 9 Havoc Pennington 2013-12-12 13:49:21 UTC
with that rule change,
$ udevadm info -n /dev/input/event3 | grep tags
E: ID_INPUT.tags=touchpad_softbutton_top

Comment 10 Fedora Update System 2013-12-13 00:06:53 UTC
xorg-x11-drv-synaptics-1.7.1-6.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/xorg-x11-drv-synaptics-1.7.1-6.fc20

Comment 11 Fedora Update System 2013-12-13 00:22:27 UTC
xorg-x11-drv-synaptics-1.7.1-6.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/xorg-x11-drv-synaptics-1.7.1-6.fc19

Comment 12 Fedora Update System 2013-12-13 17:57:33 UTC
Package xorg-x11-drv-synaptics-1.7.1-6.fc20:
* 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:
https://admin.fedoraproject.org/updates/FEDORA-2013-23359/xorg-x11-drv-synaptics-1.7.1-6.fc20
then log in and leave karma (feedback).

Comment 13 Fedora Update System 2013-12-20 01:53:03 UTC
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.

Comment 14 Ferry Huberts 2013-12-20 12:06:32 UTC
@Peter,

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 ;-)

Comment 15 Peter Hutterer 2013-12-23 00:03:33 UTC
Ferry: please see Comment 11

Comment 16 Ferry Huberts 2013-12-23 16:14:46 UTC
ah, sorry. missed that :-)

Comment 17 Fedora Update System 2014-01-18 04:20:46 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.