Bug 1104789

I've also noticed that the laptop's touchscreen (hid-multitouch) coordinates get messed up as well when I connect the external monitor.

The xserver appears to scale both devices' input coordinates to the new Screen 0 resolution (5760x2160) that includes both monitors.

Created attachment 902361 [details]
Script to help manually fix pointerss

I've found a workaround.

The attached script will calculate the 'Coordinate Transformation Matrix' to fix the touchpad cursor movement. The same matrix also fixes the touchscreen input coordinates.

The touchpad also requires an adjustment to the xinput 'Device Accel Velocity Scaling' setting. (My touchpad's normal value is hard-coded in the script.)

I plug in the external monitor, run the script. I then execute the commands it prints out to fix scaling. I can unplug the external monitor, run the script, and execute the commands to fix scaling again.

This is hacky and the script isn't documented, but it does work on my Fedora 20 installation.

Peter,

Any ideas / plans to fix cases like this ?

Thanks,

Hans

It looks like it has been proposed to implement the mapping and scaling of touch input devices to outputs in gnome settings daemon (https://bugzilla.gnome.org/show_bug.cgi?id=709600).

The referenced bug is not trying to fix the scaling problem I have with the touchpad, but looks like it would address the problem I have with the integrated touchscreen.

The function calculate_viewport_matrix(...) in gsd-device-mapper.c in attachment 268914 of the referenced gnome bug 709600 is similar to what I tried to do to fix the scaling.

I think it makes sense to limit the scaling of my touchpad to the primary display similar to their handling of laptop touchscreens, but the acceleration problem would also need to be addressed.

Abrahm

It's an xserver bug, I've got some patches for this locally but need to finish them off.

> https://admin.fedoraproject.org/updates/FEDORA-2014-7665/xorg-x11-server-1.14.4-10.fc20
>  whot - 2014-06-26 00:32:34
> Can you guys please attach an evemu-record description of your
> touchpad to bug 1104789, something is clearly broken but it
> seems to be device-dependent 

$ xinput --list | grep -i touchpad
⎜   ↳ SynPS/2 Synaptics TouchPad              	id=12	[slave  pointer  (2)]

$ xinput --disable 12

# evemu-record /dev/input/by-path/platform-i8042-serio-1-event-mouse
[see attachment]

$ xinput --enable 12

Created attachment 912393 [details]
evemu-record.log

xorg-x11-server-1.14.4-10.fc20 has partially addressed the problem.

Cursor movement caused by slow finger input on the touchpad appears to be about the same before and after I plug in the large external monitor. YAY!

Touchpad cursor acceleration still scales inversely with the number of pixels, and the touch screen input still scales with the number of pixels as well.

The patch used in -10 is making my touchpad move painfully slow. I've filed a bug at https://bugzilla.redhat.com/show_bug.cgi?id=1113709

Dowgrading to -5 or -9 reverts the behavior. Removing fix-up-cooridinate-scaling-when-external-monitors.patch and rebulding -10 causes it to work as well.

*** Bug 1113709 has been marked as a duplicate of this bug. ***

xorg-x11-server-1.14.4-11.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/xorg-x11-server-1.14.4-11.fc20

Note that this update reverts the patch added in -10, it broke a couple of other touchpads. So it just restores the status quo.

*** Bug 1113807 has been marked as a duplicate of this bug. ***

*** Bug 1113704 has been marked as a duplicate of this bug. ***

*** Bug 1113799 has been marked as a duplicate of this bug. ***

*** Bug 1113814 has been marked as a duplicate of this bug. ***

Coming in from https://bugzilla.redhat.com/show_bug.cgi?id=1113704:

I have _no_ external monitor attached and the touchpad is slooooooow.

The update in bodhi seem solve problem : https://admin.fedoraproject.org/updates/xorg-x11-server-1.14.4-11.fc20?_csrf_token=431a4ff9340e1b0dba48fda8d869032c3edcf368

Please test it and leave karma.

*** Bug 1114094 has been marked as a duplicate of this bug. ***

Package xorg-x11-server-1.14.4-11.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-server-1.14.4-11.fc20'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2014-7810/xorg-x11-server-1.14.4-11.fc20
then log in and leave karma (feedback).

*** Bug 1114130 has been marked as a duplicate of this bug. ***

I had to use command 'yum update --enablerepo=updates-testing xorg-x11-* ' to install the 1.14.4-11 updates which appear to not cause breakage.

(In reply to Robert Lightfoot from comment #22)
> I had to use command 'yum update --enablerepo=updates-testing xorg-x11-* '
> to install the 1.14.4-11 updates which appear to not cause breakage.

This works for me, too.

The update (xorg-x11-server-common-1.14.4-10.fc20.x86_64) just hit my Dell Latitude D630 yesterday.  I have a screen resolution of 1440x900 and have not hooked any external monitors up to it... much less really high resolution ones... and now the touchpad is unusable because it has a tiny resolution... of (guessing) 40x20 pixels... no matter how fast I move it... so it takes about 30-something full swipes of the touchpad to go from the bottom left corner of the screen to the top right corner.  I used to be able to do that in 1-ish swipes but now it takes 30 something... so the touchpad had basically become unusable.  Luckily I also have an eraser head pointer device and that is working fine.

So, wow... the fix that addresses this bug might have fixed the problem for someone with a large external display, but it broke it normal usage for this user using the internal display only.  Help, I'm not fond of using the eraser head... and I feel sorry for anyone who might have hit this new bug without an additional input device that still works.

Here's a new bug report that addresses the bug caused by this fix:
https://bugzilla.redhat.com/show_bug.cgi?id=1114180

*** Bug 1114180 has been marked as a duplicate of this bug. ***

I installed xorg-x11-server-common-1.14.4-11.fc20.x86_64 from the updates-testing repo and it did not resolve the issue for me.

A routine update to xorg-x11-server-1.14.4-10.fc20 broke my touchpad really badly, as folks described by 1114180 which got marked as duplicate of this.

Commenting to confirm that installing xorg-x11-server-common-1.14.4-11.fc20 from the updates-testing repo fixed this for me.

(In reply to Scott Dowdle from comment #27)
> I installed xorg-x11-server-common-1.14.4-11.fc20.x86_64 from the
> updates-testing repo and it did not resolve the issue for me.

if KDE run this
sudo systemctl restart kdm.service

I can confirm this. Happened to me after I've updated today. My system is a Compaq Presario C700 notebook with Fedora 20 64 bits.

Fixing this problem with

sudo yum update --enablerepo=updates-testing xorg-x11-*

broke my Adobe Flash plugin on Fedora 20, 64 bit.

Any hints?

(In reply to Markus from comment #31)
> Fixing this problem with
> 
> sudo yum update --enablerepo=updates-testing xorg-x11-*
> 
> broke my Adobe Flash plugin on Fedora 20, 64 bit.
> 
> Any hints?

I can not confirm this. Flash is still working here, I used the lpf-flash* to install it before this xorg-x11-* issue poped up.

I have the same problem. After do a yum update, and restart the system, my mousepad back with a very slow movement.

Dell 1420

yum update

xorg-x11-server-Xorg.x86_64              1.14.4-10.fc20

rendered the touchpad on my Dell 6430u nearly unusable. No external monitors involved.

conrad and christian - install 1.14.4-11.fc20 as mentioned in comment 22 and see if this resolved your issue

xorg-x11-server-1.14.4-11.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.

Just to reitterate, xorg-x11-server-1.14.4-11.fc20 did *NOT* fix it for me.

(In reply to Robert Lightfoot from comment #35)
> conrad and christian - install 1.14.4-11.fc20 as mentioned in comment 22 and
> see if this resolved your issue
Yes, thank you this appears to have resolved the issue for me.

I have two laptops affected by this bug and only one got fixed by the new xorg-x11-server-1.14.4-11.fc20 patch.

DELL Latitude E7440 (FIXED):
Output of /proc/bus/input/devices for the touchpad

I: Bus=0011 Vendor=0002 Product=0008 Version=0300
N: Name="AlpsPS/2 ALPS DualPoint TouchPad"
P: Phys=isa0060/serio1/input0
S: Sysfs=/devices/platform/i8042/serio1/input/input6
U: Uniq=
H: Handlers=mouse1 event6 
B: PROP=8
B: EV=b
B: KEY=e420 70000 0 0 0 0
B: ABS=260800001000003


DELL Latitude E6400 (NOT FIXED):
Output of /proc/bus/input/devices for the touchpad

I: Bus=0011 Vendor=0002 Product=0008 Version=0200
N: Name="AlpsPS/2 ALPS DualPoint TouchPad"
P: Phys=isa0060/serio1/input0
S: Sysfs=/devices/platform/i8042/serio1/input/input5
U: Uniq=
H: Handlers=mouse1 event5 
B: PROP=0
B: EV=b
B: KEY=420 70000 0 0 0 0
B: ABS=1000003

Both of these laptops have trackpoints (joystick nub) which have continued to work flawlessly during both patches. External USB mice continue to work. I'll provide more information about the hardware if requested.

Here's the output of /proc/bus/input/devices for my Dell Latitude D630 that is not fixed by the latest update:

I: Bus=0011 Vendor=0002 Product=0008 Version=0200
N: Name="AlpsPS/2 ALPS DualPoint TouchPad"
P: Phys=isa0060/serio1/input0
S: Sysfs=/devices/platform/i8042/serio1/input/input5
U: Uniq=
H: Handlers=mouse1 event5 
B: PROP=0
B: EV=b
B: KEY=420 70000 0 0 0 0
B: ABS=1000003

On futher examination (doing a cold boot rather than than just a warm boot), my touchpad is working fine with the update.

(In reply to Scott Dowdle from comment #41)
> On futher examination (doing a cold boot rather than than just a warm boot),
> my touchpad is working fine with the update.

I can confirm that this solved my issue as well for the DELL Latitude E6400 laptop.

If the patch does not solve the issue with a reboot, a full cold boot should be tried before reporting further issues here.

*** Bug 1114195 has been marked as a duplicate of this bug. ***

I had the same issue running Fedora 20 on "Dell Studio 1440/14z" Laptop and the testing update solved it.
Thanks
Yasir

the -11 update fixed my t440s

First, sorry to everyone, I didn't expect that to break that badly. Still not sure what's going on here and whether it was the backport or the actual patch that caused it since both work just fine here.

Ferry: you have the same touchpad that I have and it worked fine here (the patch was developed on a T440s). Slight change in acceleration but not really that noticable, so I really wonder what is going on here.

what's the output of:
 gsettings list-recursively | grep "touchpad motion"

Do you use GNOME or something else? What's the output of xinput list-props "SynPS/2 Synaptics TouchPad".

was this with a display plugged in, without a display?

Can you estimate the slowdown? 50% of before, 10% of speed before?

(In reply to Peter Hutterer from comment #46)
> First, sorry to everyone, I didn't expect that to break that badly. Still
> not sure what's going on here and whether it was the backport or the actual
> patch that caused it since both work just fine here.
> 
> Ferry: you have the same touchpad that I have and it worked fine here (the
> patch was developed on a T440s). Slight change in acceleration but not
> really that noticable, so I really wonder what is going on here.
> 
> what's the output of:
>  gsettings list-recursively | grep "touchpad motion"
> 

org.gnome.settings-daemon.peripherals.touchpad motion-acceleration 5.1200000000000001
org.gnome.settings-daemon.peripherals.touchpad motion-threshold 5
org.gnome.settings-daemon.peripherals.touchpad motion-acceleration 5.1200000000000001
org.gnome.settings-daemon.peripherals.touchpad motion-threshold 5


> Do you use GNOME or something else? What's the output of xinput list-props
> "SynPS/2 Synaptics TouchPad".

I use a default F20 install with gnome.

Device 'SynPS/2 Synaptics TouchPad':
	Device Enabled (134):	1
	Coordinate Transformation Matrix (136):	1.000000, 0.000000, 0.000000, 0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000
	Device Accel Profile (265):	1
	Device Accel Constant Deceleration (266):	2.500000
	Device Accel Adaptive Deceleration (267):	1.000000
	Device Accel Velocity Scaling (268):	12.500000
	Synaptics Edges (289):	1310, 4826, 2220, 4636
	Synaptics Finger (290):	25, 30, 0
	Synaptics Tap Time (291):	180
	Synaptics Tap Move (292):	218
	Synaptics Tap Durations (293):	180, 180, 100
	Synaptics ClickPad (294):	1
	Synaptics Middle Button Timeout (295):	0
	Synaptics Two-Finger Pressure (296):	282
	Synaptics Two-Finger Width (297):	7
	Synaptics Scrolling Distance (298):	-99, -99
	Synaptics Edge Scrolling (299):	0, 0, 0
	Synaptics Two-Finger Scrolling (300):	1, 1
	Synaptics Move Speed (301):	1.000000, 1.750000, 0.040331, 0.000000
	Synaptics Off (302):	2
	Synaptics Locked Drags (303):	0
	Synaptics Locked Drags Timeout (304):	5000
	Synaptics Tap Action (305):	0, 0, 0, 0, 1, 3, 2
	Synaptics Click Action (306):	1, 3, 2
	Synaptics Circular Scrolling (307):	0
	Synaptics Circular Scrolling Distance (308):	0.100000
	Synaptics Circular Scrolling Trigger (309):	0
	Synaptics Circular Pad (310):	0
	Synaptics Palm Detection (311):	0
	Synaptics Palm Dimensions (312):	10, 200
	Synaptics Coasting Speed (313):	20.000000, 50.000000
	Synaptics Pressure Motion (314):	30, 160
	Synaptics Pressure Motion Factor (315):	1.000000, 1.000000
	Synaptics Grab Event Device (316):	1
	Synaptics Gestures (317):	1
	Synaptics Capabilities (318):	1, 0, 0, 1, 1, 1, 1
	Synaptics Pad Resolution (319):	1, 1
	Synaptics Area (320):	0, 0, 0, 0
	Synaptics Soft Button Areas (321):	3068, 0, 4326, 0, 0, 0, 0, 0
	Synaptics Secondary Soft Button Areas (322):	3395, 0, 0, 2248, 2740, 3395, 0, 2248
	Synaptics Noise Cancellation (323):	8, 8
	Device Product ID (252):	2, 7
	Device Node (253):	"/dev/input/event4"



> 
> was this with a display plugged in, without a display?

without a display. just the laptop itself

but now you make me doubt myself.
I might have booted on the dock with 1 DP display plugged in. unsure now.

> 
> Can you estimate the slowdown? 50% of before, 10% of speed before?

more like 10% than 50%. way way slower. and the accelaration setting of the gnome control panel didn't work at all. I dialled it way up and that didn't have any effect.

I'm now on the -11 update and that works just fine

(In reply to Peter Hutterer from comment #46)
> First, sorry to everyone, I didn't expect that to break that badly. Still
> not sure what's going on here and whether it was the backport or the actual
> patch that caused it since both work just fine here.
> 
> Ferry: you have the same touchpad that I have and it worked fine here (the
> patch was developed on a T440s). Slight change in acceleration but not
> really that noticable, so I really wonder what is going on here.
> 
> what's the output of:
>  gsettings list-recursively | grep "touchpad motion"
> 
> Do you use GNOME or something else? What's the output of xinput list-props
> "SynPS/2 Synaptics TouchPad".
> 
> was this with a display plugged in, without a display?
> 
> Can you estimate the slowdown? 50% of before, 10% of speed before?

Same desktop environment as Ferry, F20 with Gnome 3, running on Dell 6430u laptop (AlpsPS/2 ALPS DualPoint Touchpad and 1600x900px display), no external monitor attached at any time as I don't own one. I echo the observation that the scaling was much less than 50%, more like 10%.

This morning updated from updates-testing repository fixed the issue on my ASUS X54C (both with or without monitor plugged in). Well... Sort of... The mouse pointer is a little bit too fast now :)

Ok, Hans found the issue with my patch - I was running a non-F20 kernel and that had the resolutions set on my touchpad. For any touchpad without resolutions (e.g. T440 on F20 kernels) the scaling is simply too big - the server uses a default of 100 units/mm if no resolution is set, but the t440 only has a res of 43 units/mm, so a >50% slowdown. Other touchpads are affected likewise.

Also, fwiw, -9 and -11 are the same code except for the version number, so any change in behaviour is either cosmic ray influence or imagined :)

We'll figure out a solution hopefully within the next day or two. In the meantime please don't comment with "me too" or "-11 fixed it" on this bug to keep the noise down.

*** Bug 1113934 has been marked as a duplicate of this bug. ***

*** Bug 1113934 has been marked as a duplicate of this bug. ***

Test build cooking at: http://koji.fedoraproject.org/koji/taskinfo?taskID=7115903

Please give it a try. For resolution-less devices I had to guess some generic factor, so this may feel different on each device and it may still feel slower or faster than the build beforehand, there's not much we can do there. The effect of the monitor should go away though, the touchpad speed is constant for the server session.

Apologies, that test build failed after the first two builds succeeded. Here's the one that fully finished: http://koji.fedoraproject.org/koji/taskinfo?taskID=7119558
I tweaked the speed too, so if you tried the one from Comment 53 please make sure you try this one too

I've installed the build from taskID 7119558.

Slow cursor movement does not change significantly with the change in screen resolution caused by plugging in the external monitor.

Cursor acceleration, however, is still significantly affected by the change in screen resolution.

"Cursor acceleration, however, is still significantly affected by the change in screen resolution."
I'm having troubles parsing this: are you saying the default speed is now too slow, or that it still changes as you change resolution?

(In reply to Peter Hutterer from comment #56)
> "Cursor acceleration, however, is still significantly affected by the change
> in screen resolution."
> I'm having troubles parsing this: are you saying the default speed is now
> too slow, or that it still changes as you change resolution?

No. I have no problem with the base speed. You've done a good job keeping the change to a minimum, and I see no change when I plug in a monitor *when I move my finger across my touchpad slowly*. One slow horizontal swipe takes the cursor from the left across about 1/3 or 1/4 of the screen in both cases.

When I move my finger quickly, the cursor does not move the same with and without the external monitor. On my particular laptop, one swift horizontal swipe takes the cursor all the way across the screen with no external monitor. With an external monitor, the same swipe takes the cursor only about 1/2 way across the screen.

The original workaround included scaling the xinput property 'Device Accel Velocity Scaling' to counteract these effects.

Is that a better description?

urgh, right. confirmed, and sort-of fixed though I'm not sure this is upstreamable without significant nightmares. Anyway, test build available here: http://koji.fedoraproject.org/koji/taskinfo?taskID=7135537

(In reply to Peter Hutterer from comment #58)
> urgh, right. confirmed, and sort-of fixed though I'm not sure this is
> upstreamable without significant nightmares. Anyway, test build available
> here: http://koji.fedoraproject.org/koji/taskinfo?taskID=7135537

The test build seems to have broken acceleration. Slow and fast cursor movements both now travel just more that half the width of my primary monitor.

Abrahm

yeah, that's the downside of the whole thing, finding some middle ground that works for all touchpads. I'm gonna have to admit that this bug will likely not find its way into F20, though F21 is a possibility. I've reverted the original change upstream now as well and it won't be fixed until at least 1.16.1. sorry.

(In reply to Peter Hutterer from comment #60)
> yeah, that's the downside of the whole thing, finding some middle ground
> that works for all touchpads. I'm gonna have to admit that this bug will
> likely not find its way into F20, though F21 is a possibility. I've reverted
> the original change upstream now as well and it won't be fixed until at
> least 1.16.1. sorry.

I'd like to try to modify your last set of patches to work better with the laptops that I have available to me if you wouldn't mind. I can't seem to find a downloadable src rpm on koji for that last build. Can you help me?

Abrahm

The one you're looking for is d70fc32e12ffb257903c280c0c81c1ebb2be0734 on this branch here:
http://cgit.freedesktop.org/~whot/xserver/log/?h=wip/touchpad-resolution-scaling

Just an update: the last approach had to be reverted again upstream since it still didn't work. No better solution yet, ETIME mainly.

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.