Bug 1057786

attach the output of xinput list-props "device name" please (xinput list gives you the name).

Created attachment 859543 [details]
output of 'xinput list-props "SynPS/2 Synaptics TouchPad"'

this sounds quite odd, the settings are normal. have you ruled out a hardware issue? there certainly shouldn't be that many issues with it.

If so, please record a few event sequences with evemu-record, I'll try to reproduce it here.

Talkes to some further guys which never T530 and T540. They all basically report issues with the touchpad hardly being usable so it sounds quite unlikely that my machine has a hardware issue. I'll try to grab some other distro live-cd to see if they have the same issue.
When trying to record events via evemu-record, I am told:

error: this device is grabbed and I cannot record events

Do I have to boot non-graphical to be able to record events in the touchpad?

I used Lenovo T430 earlier, and the touchpad that one had worked "OK" in Fedora. 
Now I have Lenovo T440s, and the touchpad in this one is *horrible*!

I can agree 100% that "hardly usable" is the correct term to describe the touchpad on recent lenovos.

Some of the issues with the touchpad on t440s:

- While you type with the keyboard mouse cursor randomly jumps to random places messing up your writing/apps.
- Clicking the "right side" of the touchpad surface results in right click, not left click like would assume. This is *very* annoying.
- Choosing/marking text with the touchpad is almost impossible due to the same problem as earlier.
- Touching the touchpad with multiple fingers *stops* all touchpad processing for a while.
- When you touch the touchpad to do a "left click" the mouse cursor jumps to other location. Very annoying.


etc

I just received a T540p and the touchpad is completely useless. Some specific things I've noticed:

1) There's a red line on the touchpad. The assumption would be that touching above that line does not move the mouse, but is reserved for clicking. This is not true. Moving or touching above the red line still moves the mouse pointer all over the place. 

2) When trying to "click", a human finger may move a bit during the press down. I am repeatedly hit by the mouse pointer moving off of the target I am trying to click on. It often takes me several attempts to click on something. 

3) when preparing to click, I may scroll my finger around below the red line, while one finger rests above the red line, preparing to click. However, 2 fingers touching the pad at the same time means the mouse pointer can no longer move.

4) I have been 100% unable to figure out how to middle-click. I found this related bug:  https://bugzilla.redhat.com/show_bug.cgi?id=1068716

5) On my previous laptop, to disable the trackpad, I would execute:

synclient TouchpadOff=0 # off
synclient TouchpadOff=1 # on


These commands do not seem to work at all on the T540p.

Please don't mix up the 40 series with the 30 series, very different touchpads. I've submitted an update that should handle the 40 series today.
https://admin.fedoraproject.org/updates/xorg-x11-drv-synaptics-1.7.4-4.fc20
This bug is about the 530, not the 540.

(In reply to Andre Dietisheim from comment #4)
> Do I have to boot non-graphical to be able to record events in the touchpad?

see http://www.freedesktop.org/wiki/Evemu/

Somewhat related:  http://lists.freedesktop.org/archives/xorg/2014-March/056486.html

Rob:  Try adding the following to /etc/X11/xorg.conf.d/40-synaptics.conf

Section "InputClass"
Identifier "Clickpad buttons"
MatchDriver "synaptics"
Option "SoftButtonAreas" "66% 0 0 50% 33% 65% 0 50%"
Option "AreaTopEdge" "2621"
Option "PalmDetect" "1"
EndSection

For me, palm detection is pretty much pointless, I still constantly will be tying and find myself erasing entire paragraphs or getting the touchpad 'locked' in a state of click where I have to hit it a few times to get it back to a 'normal' state.

So.....to disable it altogether:


[jpriddy@oblong ~]$ xinput 
⎡ Virtual core pointer                    	id=2	[master pointer  (3)]
⎜   ↳ Virtual core XTEST pointer              	id=4	[slave  pointer  (2)]
⎜   ↳ Microsoft Microsoft® Nano Transceiver v1.0	id=10	[slave  pointer  (2)]
⎜   ↳ Microsoft Microsoft® Nano Transceiver v1.0	id=11	[slave  pointer  (2)]
⎜   ↳ TPPS/2 IBM TrackPoint                   	id=16	[slave  pointer  (2)]
⎜   ↳ SynPS/2 Synaptics TouchPad              	id=15	[jpriddy@oblong ~]$ xinput disable 15
[slave  pointer  (2)]
⎣ Virtual core keyboard                   	id=3	[master keyboard (2)]
    ↳ Virtual core XTEST keyboard             	id=5	[slave  keyboard (3)]
    ↳ Power Button                            	id=6	[slave  keyboard (3)]
    ↳ Video Bus                               	id=7	[slave  keyboard (3)]
    ↳ Sleep Button                            	id=8	[slave  keyboard (3)]
    ↳ Microsoft Microsoft® Nano Transceiver v1.0	id=9	[slave  keyboard (3)]
    ↳ Yubico Yubico Yubikey II                	id=12	[slave  keyboard (3)]
    ↳ Integrated Camera                       	id=13	[slave  keyboard (3)]
    ↳ AT Translated Set 2 keyboard            	id=14	[slave  keyboard (3)]
    ↳ ThinkPad Extra Buttons                  	id=17	[slave  keyboard (3)]

[jpriddy@oblong ~]$ xinput disable 15


Boom.  Off.

Note that you cant use it to click either, but it does leave the red thing (trackpoint i guess?) still working.

John: there's an Option "Ignore" if you want to just remove the device altogether. With the newest patches you can use option "TouchpadOff" to disable the touchpad but leave clicks working.

Palm detection is broken, we know it, no-one had the time to fix it yet. and the data we get from the touchpad for palms is hard to distinguish from fingers in many cases.

Created attachment 880250 [details]
Unusable Use Case 1

In use case 1, your goal is to click on 4 different folders using a left-click mechanism without moving your finger off the trackpad. 

On the top of the image, we can see the window, and the initial mouse position. To the right, we can see the instructions for this usecase. 

On the bottom left, we see the current configuration of the trackpad and why it's so confusing. The right-click is very very poorly placed, and very difficult to find. It also means you often right-click completely by accident during the case of a normal situation. 

In the above image, the user clicks on t1, then moves over to t2, clicks it, and then, when moving to click on t3, finds himself inside the right-click zone. The user is confused, lifts his finger, and begins to search again for a left-click area. 

On the botton right, though, we see a more sane configuration for the trackpad. The user has the entire bottom of the trackpad to be a left-click, which is 100% expected. The user experiences no error in this situation.

Created attachment 880251 [details]
Unusable Use Case 2

In this usecase, the mouse pointer is already at the correct location. The user has no visual clues on the trackpad as to where the proper right-click area is. He clicks the upper-riught, above the red line, where he could reasonably expect the right-click to be. It is not there. The user instead has to search all over for the right click.

Created attachment 880252 [details]
Unusable Use Case 3

In this use case, the user wants to drag something from the right of his screen to the left, drop it, and then right-click on the drop point. 

When the user places his finger somewhere on the right side, though, he is directly in the right-click zone, and ends up right-clicking the folder rather than initiating a drag.

The user must search around for a place to click that is NOT right-click. This is pretty difficult, though, as the user would expect the top-right to be a right-click.  Even if he is aware of the given configuration, the right-click rectangle takes up half of the width of the trackpad, which them limits how far to the left he can drag it. 

Then, afterwards, the user struggles to find the right-click zone again. 

For users who use the "nipple" in the keyboard as their primary mouse, they would typically use their thumbs to perform the clicking. Past lenovo hardware had the left and right click buttons directly below the spacebar. To reach the right-click, though, this type of user must now awkwardly rotate their hand so their thumb can reach the bottom-right quadrant of the trackpad, which becomes VERY tiring. 

Rotating your right hand from typing position will make it very difficult for your right thumb to locate the right-click section, since it is (incorrectly) placed in the bottom-right of the trackpad. 

The left thumb is a much more natural fit to reach the right-click without hurting your wrist, but, this is completely counter-intuitive to users' past experience. Using your left thunmb to right-click on the bottom-right of the trackpad is awkward beyond belief.

I will post more usecases in the future. These are just the three that I decided to do before I went to bed. 

I very often find that when iterating through a row of items, such as in a spreadsheet or other, attempting to right-click on each item, it simply changes from right-click to left-click and I must awkwardly adjust by performing small mouse-movements over and over and over. One second I'm right-clicking, the next I'm left-clicking, or vice versa. This is very very jarring. 

Another bug:  I would strongly strongly suggest that the area above the red line (as seen in the screenshots) does NOT respond to mouse movements, but ONLY clicks. 

There is a very big problem when your click area is the same as your scroll area. The big problem is when you perform a click, pressure moves from one side of your thumb to the other. This change in pressure is understood as you scrolling along the trackpad, when you're not. You're not trying to scroll, you're trying to click. 

But the software / drivers interpret this as you scrolling, not just clicking. Your pointer moves off of your target during the click. 

I know you say this bug is about the 30 series, but I have asked others and they have experienced the exact same behavior. I really don't think this behavior is specific to t540p. I believe most users simply gave up on the 30 and 40 trackpads and switched to mouse.

One stop in an office and I immediately had 5 people of various different laptop models agreeing with my observations. 

If you can try to replciate these issues, that'd be great. If the issues are replicatable, then I encourage you to try to find a more usable solution. The reason people don't complain is because they just gave up and didn't feel like listing all the specific problems. Even the author of this bug here said the number of problems were too many to iterate, and he just listed the first 3 he could think of.

Rob: as I said in comment #7, this bug was supposed to be about the T530. Please DO NOT report T540 problems here, it just confuses the issue, the two touchpads are very different.
The t540 problems are supposed to be solved with the latest versions in rawhide and f20 updates-testing. If these versions don't work, please file a new bug.


Andre, I still need some recordings of when things go wrong, otherwise I can't reproduce it here. Also, I suspect this is a dupe of 877464 which was fixed in https://admin.fedoraproject.org/updates/xorg-x11-drv-synaptics-1.7.4-4.fc20

Peter, ack your request to keep the separate platforms separate, but wanted to add that 440 is also an issue, fyi. Was led here by list post.

Peter, echoing comment #15 of Cale. Honestly I never know how to effectively file bug reports on things of this sort but the trackpad on 440 is so bad I had to disable it in the config file and procure an external mouse.

This message is a reminder that Fedora 20 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 20. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '20'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 20 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Fedora 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.