[Desktop-packages] [Bug 621432]
I don't know If this is caused by the same issue, but the problem is quite siilar, so I attach this as a commen instead of filing a new bug. I'm using debian testing / x.org 1.17.2 with a Lenovo U41 which has an ALPS touchpad. The problem is that the touchpad is way faster on the horizontal axis than on the vertical axis: while a swipe from left to right will move the pointer approximately from the left to the right screen edge, a complete top-down swipe only covers one quarter of the screen - of course influenced by the acceleration settings. Fiddling with the "VertResolution" and "HorizResolution" options didn't show any effect for me. Looking at the code it seems that these options were actually rendered useless when the synaptics driver scaling was removed in commit #0fb59b3487d57523a03f078a2061e2ea0cacbc7c. The driver always passes the resolution values reported by the device to the server instead of the overwritten ones from the config. Some debugging later, this is what the device reports to the server: minx: 0, maxx: 4095, resx: 40 miny: 0, maxy: 2047, resy: 71 So it looks like the device has indeed a different resolution in x and y and this seems to get mix up the scaling somehow. I tried to make the driver pass the VertResolution and HorizResolution parameters instead of the device values by changing some lines from synaptics.c: xf86InitValuatorAxisStruct(dev, 0, axes_labels[0], min, max, priv->resx * 1000, 0, priv->resx * 1000, Relative); into xf86InitValuatorAxisStruct(dev, 0, axes_labels[0], min, max, priv->synpara.resolution_horiz * 1000, 0, priv->synpara.resolution_horiz * 1000, Relative); and xf86InitValuatorAxisStruct(dev, 1, axes_labels[1], min, max, priv->resy * 1000, 0, priv->resy * 1000, Relative); into xf86InitValuatorAxisStruct(dev, 1, axes_labels[1], min, max, priv->synpara.resolution_vert * 1000, 0, priv->synpara.resolution_vert * 1000, Relative); After that, setting both "VertResolution" and "HorizResolution" to the same value, makes the touchpad behave as expected. But I think the real problem is somewhere deeper in getevents.c As far as I understand the scale_for_device_resolution function tries to map the touch pad size to the screen size which works fine as long as resolution_ratio equals 1 which is the case for all pads with an equal x/y resolution and breaks on devices with uneven resolutions. But why is the resolution involved in the scaling anyway? If we try to map 1the device size to the screen size we don't need to bother about the device resolution. The axis sizes and the screen resolution should be enough?! -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to xserver-xorg-input-synaptics in Ubuntu. https://bugs.launchpad.net/bugs/621432 Title: Touchpad speed asymetrical (horizontal faster than vertical) Status in Xserver Xorg Input Synaptics: Confirmed Status in xserver-xorg-input-synaptics package in Ubuntu: Fix Released Bug description: Binary package hint: xserver-xorg-input-synaptics Using Ubuntu Maverick on a Samsung NC10 : since that release, moving my touchpad horizontally makes the pointer to move faster than moving it vertically. I already had this behavior when I was using X from xorg-edgers PPA with Lucid. Please let me know if you need additionnal informations. ProblemType: Bug DistroRelease: Ubuntu 10.10 Package: xserver-xorg-input-synaptics 1.2.2-2ubuntu3 [modified: usr/bin/synclient usr/bin/syndaemon] ProcVersionSignature: Ubuntu 2.6.35-15.21-generic 2.6.35.1 Uname: Linux 2.6.35-15-generic i686 Architecture: i386 DRM.card0.LVDS.1: status: connected enabled: enabled dpms: On modes: 1024x600 edid-base64: AP///wAOFMQEAAsTAQOAFw54ClB1klhWkicfUFQBAQEBAQEBAQEBAQEBAQEBlBEAsEBYGSAwIDYA3oIZDwAAACBuBQ8A/gBDUFQgICAgICAgICAg/gBDTEFBMTAyTkEwQSAgAGU= DRM.card0.VGA.1: status: disconnected enabled: disabled dpms: Off modes: edid-base64: Date: Fri Aug 20 23:57:05 2010 InstallationMedia: Ubuntu 10.10 "Maverick Meerkat" - Alpha i386 (20100812) MachineType: SAMSUNG ELECTRONICS CO., LTD. NC10 ProcCmdLine: BOOT_IMAGE=/boot/vmlinuz-2.6.35-15-generic root=UUID=14c3da20-90cd-416c-932d-fc86ad750d06 ro quiet splash ProcEnviron: LANG=fr_FR.utf8 SHELL=/bin/bash SourcePackage: xserver-xorg-input-synaptics dmi.bios.date: 09/08/2009 dmi.bios.vendor: Phoenix Technologies Ltd. dmi.bios.version: 11CA.M015.20090908.RHU dmi.board.name: NC10 dmi.board.vendor: SAMSUNG ELECTRONICS CO., LTD. dmi.board.version: Not Applicable dmi.chassis.asset.tag: No Asset Tag dmi.chassis.type: 10 dmi.chassis.vendor: SAMSUNG ELECTRONICS CO., LTD. dmi.chassis.version: N/A dmi.modalias: dmi:bvnPhoenixTechnologiesLtd.:bvr11CA.M015.20090908.RHU:bd09/08/2009:svnSAMSUNGELECTRONICSCO.,LTD.:pnNC10:pvrNotApplicable:rvnSAMSUNGELECTRONICSCO.,LTD.:rnNC10:rvrNotApplicable:cvnSAMSUNGELECTRONICSCO.
[Desktop-packages] [Bug 726832]
I don't know If this is caused by the same issue, but the problem is quite siilar, so I attach this as a commen instead of filing a new bug. I'm using debian testing / x.org 1.17.2 with a Lenovo U41 which has an ALPS touchpad. The problem is that the touchpad is way faster on the horizontal axis than on the vertical axis: while a swipe from left to right will move the pointer approximately from the left to the right screen edge, a complete top-down swipe only covers one quarter of the screen - of course influenced by the acceleration settings. Fiddling with the "VertResolution" and "HorizResolution" options didn't show any effect for me. Looking at the code it seems that these options were actually rendered useless when the synaptics driver scaling was removed in commit #0fb59b3487d57523a03f078a2061e2ea0cacbc7c. The driver always passes the resolution values reported by the device to the server instead of the overwritten ones from the config. Some debugging later, this is what the device reports to the server: minx: 0, maxx: 4095, resx: 40 miny: 0, maxy: 2047, resy: 71 So it looks like the device has indeed a different resolution in x and y and this seems to get mix up the scaling somehow. I tried to make the driver pass the VertResolution and HorizResolution parameters instead of the device values by changing some lines from synaptics.c: xf86InitValuatorAxisStruct(dev, 0, axes_labels[0], min, max, priv->resx * 1000, 0, priv->resx * 1000, Relative); into xf86InitValuatorAxisStruct(dev, 0, axes_labels[0], min, max, priv->synpara.resolution_horiz * 1000, 0, priv->synpara.resolution_horiz * 1000, Relative); and xf86InitValuatorAxisStruct(dev, 1, axes_labels[1], min, max, priv->resy * 1000, 0, priv->resy * 1000, Relative); into xf86InitValuatorAxisStruct(dev, 1, axes_labels[1], min, max, priv->synpara.resolution_vert * 1000, 0, priv->synpara.resolution_vert * 1000, Relative); After that, setting both "VertResolution" and "HorizResolution" to the same value, makes the touchpad behave as expected. But I think the real problem is somewhere deeper in getevents.c As far as I understand the scale_for_device_resolution function tries to map the touch pad size to the screen size which works fine as long as resolution_ratio equals 1 which is the case for all pads with an equal x/y resolution and breaks on devices with uneven resolutions. But why is the resolution involved in the scaling anyway? If we try to map 1the device size to the screen size we don't need to bother about the device resolution. The axis sizes and the screen resolution should be enough?! -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to xserver-xorg-input-synaptics in Ubuntu. https://bugs.launchpad.net/bugs/726832 Title: Touchpad speed scales with multimonitor size per axis Status in XOrg-Driver-Synaptics: Confirmed Status in xserver-xorg-input-synaptics package in Ubuntu: Incomplete Bug description: When enabling a second screen, say horizontally next to the primary screen, horizontal touchpad speed increases proportionally to the increase in horizontal resolution. I assume the same happens when enabling multiple screens in a vertical configuration. So, it seems that touchpad speed is relative to the total screen layout size in each axis. This is quite irritating. It would be more reasonable to define speed in absolute terms (pixels/sec) rather than relative terms (% x/y resolution / sec), thereby keeping speed in both axes constant, regardless of the addition/removal of extra screens. I've noticed this on my Thinkpad W510 running Maverick amd64, the latest nvidia binary blob, utouch 1.1, synaptics-dkms 1.0.0, and xserver-xorg-input-synaptics 1.2.2-2ubuntu5 Note that external mice don't exhibit this problem. This might be why this situation isn't encountered often: when plugged into an external monitor, the user is more likely to also plug in an external mouse rather than rely on the touchpad. This was brought up by Ricardo Caldeira at https://bugs.launchpad.net /xorg-driver-synaptics/+bug/308191/comments/187, and Duncan McGreggor replied at https://bugs.launchpad.net/xorg-driver- synaptics/+bug/308191/comments/189. To manage notifications about this bug go to: https://bugs.launchpad.net/xorg-driver-synaptics/+bug/726832/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
