Bug 1104789

Summary: Touchpad sensitivity changes dramatically when I plug in an external monitor
Product: [Fedora] Fedora Reporter: Abrahm Scully <abrahm.scully>
Component: xorg-x11-serverAssignee: Peter Hutterer <peter.hutterer>
Status: CLOSED EOL QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 20CC: alex.g.schultz, arcfi, arielnmz, bartwiegmans, chepioq, chtorregrosa, conrad.leonard, dev, dowdle, gustavo, hauberg, hdegoede, htaira, ibancioiu, jefftaylor42, kylepablo, luca.cavalli, mailings, mail, markus.ortel, peter.hutterer, steolaf, xgl-maint, yasir.elsharif
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: xorg-x11-server-1.14.4-11.fc20 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-06-29 21:02:25 EDT Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Attachments:
Description Flags
Script to help manually fix pointerss
none
evemu-record.log none

Description Abrahm Scully 2014-06-04 13:14:40 EDT
Description of problem:
When I plug in an external high-resolution monitor (3840x2160, 621mm x 341mm), my laptop's touchpad cursor movement becomes scaled so high it becomes difficult to use. Gnome enables the monitor and places it logically to the right of my laptop's built-in display (1920x1080, 293mm x 165mm). xrandr reports screen 0 has dimensions 5760x2160.

Before I plug in the external monitor, a slow finger drag across my touchpad brings the cursor almost half way across my laptop's built-in display. After I plug in the external monitor, a slow finger draw only part way across my touchpad will move the cursor all the way across the built-in display.

The cursor movement is scaled so much the movement in the X axis is jumpy.

Version-Release number of selected component (if applicable):
xorg-x11-server-Xorg-1.14.4-0.fc20.x86_64

How reproducible:
100%

Steps to Reproduce:
1. Plug in high-resolution external monitor.
2.
3.

Actual results:
The change in screen resolution changes the touchpad's cursor movement so much it becomes difficult to use.

Expected results:
The change in screen resolution does not noticeably affect the touchpad's cursor movement.

Additional info:
I am using a Dell XPS 13 9333 running Fedora 20 (and the 3.15.0-0.rc8.git0.1.fc21.x86_64 kernel to address other issues).
Comment 1 Abrahm Scully 2014-06-04 16:39:51 EDT
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.
Comment 2 Abrahm Scully 2014-06-04 18:59:14 EDT
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.
Comment 3 Hans de Goede 2014-06-05 04:19:35 EDT
Peter,

Any ideas / plans to fix cases like this ?

Thanks,

Hans
Comment 4 Abrahm Scully 2014-06-05 11:02:52 EDT
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
Comment 5 Peter Hutterer 2014-06-05 18:06:30 EDT
It's an xserver bug, I've got some patches for this locally but need to finish them off.
Comment 6 ArcFi 2014-06-26 05:55:16 EDT
> 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
Comment 7 ArcFi 2014-06-26 05:56:42 EDT
Created attachment 912393 [details]
evemu-record.log
Comment 8 Abrahm Scully 2014-06-26 12:32:48 EDT
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.
Comment 9 Jason Montleon 2014-06-26 13:50:36 EDT
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.
Comment 10 Peter Hutterer 2014-06-26 21:25:52 EDT
*** Bug 1113709 has been marked as a duplicate of this bug. ***
Comment 11 Fedora Update System 2014-06-26 21:56:47 EDT
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
Comment 12 Peter Hutterer 2014-06-26 22:15:19 EDT
Note that this update reverts the patch added in -10, it broke a couple of other touchpads. So it just restores the status quo.
Comment 13 Rex Dieter 2014-06-27 07:44:02 EDT
*** Bug 1113807 has been marked as a duplicate of this bug. ***
Comment 14 Hans de Goede 2014-06-27 08:12:31 EDT
*** Bug 1113704 has been marked as a duplicate of this bug. ***
Comment 15 Hans de Goede 2014-06-27 08:12:47 EDT
*** Bug 1113799 has been marked as a duplicate of this bug. ***
Comment 16 Hans de Goede 2014-06-27 08:13:04 EDT
*** Bug 1113814 has been marked as a duplicate of this bug. ***
Comment 17 Ferry Huberts 2014-06-27 08:30:47 EDT
Coming in from https://bugzilla.redhat.com/show_bug.cgi?id=1113704:

I have _no_ external monitor attached and the touchpad is slooooooow.
Comment 18 dominique 2014-06-27 13:33:44 EDT
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.
Comment 19 Hans de Goede 2014-06-27 14:25:35 EDT
*** Bug 1114094 has been marked as a duplicate of this bug. ***
Comment 20 Fedora Update System 2014-06-27 17:49:50 EDT
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).
Comment 21 Hans de Goede 2014-06-28 02:32:23 EDT
*** Bug 1114130 has been marked as a duplicate of this bug. ***
Comment 22 Robert Lightfoot 2014-06-28 05:23:44 EDT
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.
Comment 23 Bart Wiegmans 2014-06-28 05:32:15 EDT
(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.
Comment 24 Scott Dowdle 2014-06-28 06:10:44 EDT
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.
Comment 25 Scott Dowdle 2014-06-28 06:44:58 EDT
Here's a new bug report that addresses the bug caused by this fix:
https://bugzilla.redhat.com/show_bug.cgi?id=1114180
Comment 26 Iosif Bancioiu 2014-06-28 07:01:55 EDT
*** Bug 1114180 has been marked as a duplicate of this bug. ***
Comment 27 Scott Dowdle 2014-06-28 12:27:20 EDT
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.
Comment 28 Alex Schultz 2014-06-28 14:31:15 EDT
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.
Comment 29 Iosif Bancioiu 2014-06-28 14:36:32 EDT
(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
Comment 30 Benjamin Ariel Nava Martinez 2014-06-28 16:49:10 EDT
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.
Comment 31 Markus 2014-06-28 17:24:50 EDT
Fixing this problem with

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

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

Any hints?
Comment 32 Bernhard Schuster 2014-06-28 18:07:36 EDT
(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.
Comment 33 Christian 2014-06-28 19:40:53 EDT
I have the same problem. After do a yum update, and restart the system, my mousepad back with a very slow movement.

Dell 1420
Comment 34 Conrad 2014-06-28 21:49:56 EDT
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.
Comment 35 Robert Lightfoot 2014-06-28 22:55:28 EDT
conrad and christian - install 1.14.4-11.fc20 as mentioned in comment 22 and see if this resolved your issue
Comment 36 Fedora Update System 2014-06-28 22:56:06 EDT
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.
Comment 37 Scott Dowdle 2014-06-29 00:22:06 EDT
Just to reitterate, xorg-x11-server-1.14.4-11.fc20 did *NOT* fix it for me.
Comment 38 Conrad 2014-06-29 01:21:31 EDT
(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.
Comment 39 Dezponia Veil 2014-06-29 02:57:07 EDT
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.
Comment 40 Scott Dowdle 2014-06-29 06:00:02 EDT
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
Comment 41 Scott Dowdle 2014-06-29 07:18:32 EDT
On futher examination (doing a cold boot rather than than just a warm boot), my touchpad is working fine with the update.
Comment 42 Dezponia Veil 2014-06-29 07:22:54 EDT
(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.
Comment 43 Hans de Goede 2014-06-29 07:26:38 EDT
*** Bug 1114195 has been marked as a duplicate of this bug. ***
Comment 44 Yasir M Elsharif 2014-06-29 13:28:00 EDT
I had the same issue running Fedora 20 on "Dell Studio 1440/14z" Laptop and the testing update solved it.
Thanks
Yasir
Comment 45 Ferry Huberts 2014-06-29 13:31:41 EDT
the -11 update fixed my t440s
Comment 46 Peter Hutterer 2014-06-29 23:21:17 EDT
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?
Comment 47 Ferry Huberts 2014-06-30 02:04:30 EDT
(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
Comment 48 Conrad 2014-06-30 02:17:18 EDT
(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%.
Comment 49 Luca Cavalli 2014-06-30 03:12:41 EDT
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 :)
Comment 50 Peter Hutterer 2014-06-30 05:07:44 EDT
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.
Comment 51 Peter Hutterer 2014-07-01 19:37:44 EDT
*** Bug 1113934 has been marked as a duplicate of this bug. ***
Comment 52 Peter Hutterer 2014-07-01 20:13:26 EDT
*** Bug 1113934 has been marked as a duplicate of this bug. ***
Comment 53 Peter Hutterer 2014-07-08 02:51:22 EDT
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.
Comment 54 Peter Hutterer 2014-07-09 01:38:24 EDT
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
Comment 55 Abrahm Scully 2014-07-10 08:44:34 EDT
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.
Comment 56 Peter Hutterer 2014-07-10 17:30:11 EDT
"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?
Comment 57 Abrahm Scully 2014-07-11 12:12:15 EDT
(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?
Comment 58 Peter Hutterer 2014-07-13 23:58:25 EDT
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
Comment 59 Abrahm Scully 2014-07-14 21:46:20 EDT
(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
Comment 60 Peter Hutterer 2014-07-16 02:57:16 EDT
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.
Comment 61 Abrahm Scully 2014-07-18 02:09:57 EDT
(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
Comment 62 Peter Hutterer 2014-07-18 03:03:44 EDT
The one you're looking for is d70fc32e12ffb257903c280c0c81c1ebb2be0734 on this branch here:
http://cgit.freedesktop.org/~whot/xserver/log/?h=wip/touchpad-resolution-scaling
Comment 63 Peter Hutterer 2014-08-26 18:02:07 EDT
Just an update: the last approach had to be reverted again upstream since it still didn't work. No better solution yet, ETIME mainly.
Comment 64 Fedora End Of Life 2015-05-29 08:01:38 EDT
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.
Comment 65 Fedora End Of Life 2015-06-29 21:02:25 EDT
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.