Created attachment 23851 [details] Xorg.0.log touchpad on my dell latitude D830 is unusable after upgrade to 2.2.0. I made sure to rebuild all xorg libs. downgrading to 2.1.3 gives a working version though. It's kinda hard to describe what's going on, but from the looks of things, moving the mouse seems to generate two events, I'm guessing absolute then relative position... So I see a split-second of the cursor where I think it should be, but then it jumps back to ~32 pixels from the left side, at whatever Y position it's at. My touchpad seems to be detected as a tablet, here's a diff on Xorg.0.log between the two evdev versions: (II) Module evdev: vendor="X.Org Foundation" - compiled for 1.5.3, module version = 2.2.0 + compiled for 1.5.3, module version = 2.1.3 Module class: X.Org XInput Driver ABI class: X.Org XInput driver, version 2.1 (**) AT Translated Set 2 keyboard: always reports core events @@ -431,10 +461,11 @@ (II) AlpsPS/2 ALPS GlidePoint: Found 3 mouse buttons (II) AlpsPS/2 ALPS GlidePoint: Found x and y relative axes (II) AlpsPS/2 ALPS GlidePoint: Found x and y absolute axes -(II) AlpsPS/2 ALPS GlidePoint: Configuring as tablet +(II) AlpsPS/2 ALPS GlidePoint: Found absolute touchpad +(II) AlpsPS/2 ALPS GlidePoint: Configuring as mouse (**) AlpsPS/2 ALPS GlidePoint: YAxisMapping: buttons 4 and 5 (**) AlpsPS/2 ALPS GlidePoint: EmulateWheelButton: 4, EmulateWheelInertia: 10, EmulateWheelTimeout: 200 -(II) XINPUT: Adding extended input device "AlpsPS/2 ALPS GlidePoint" (type: TABLET) +(II) XINPUT: Adding extended input device "AlpsPS/2 ALPS GlidePoint" (type: MOUSE) (II) config/hal: Adding input device PS/2 Mouse
I've added in some debugging lines to EvdevProcessEvent to try to get some more info for this problem. It logs the input_event and then the values sent to xf86PostMotionEventP. From the looks of things, it's taking the value of ABS_PRESSURE and using that for the X position.
Created attachment 23860 [details] ev_event.log
Created attachment 23861 [details] [review] touchpad sanity checks patch Here's a patch that fixes one small bug and adds two sanity checks: bug: when converting touchpad to relative motion, rel is not set when abs is cleared, so events never get posted. sanity checks: if BTN_TOUCH is used, source must be a touchpad correct? ABS_PRESSURE is pretty pointless on a touchpad. With these changes, touchpad works again for me.
thanks for the patch, a few comments: - the first hunk is superfluous. if EVDEV_TOUCHPAD is set, then the device can't post an ABS_PRESSURE event anyway. Or at least it claimed it can't when we asked it during EvdevProbe. If it does, that's actually a kernel bug that needs to be fixed. - same with the second hunk, if it prints out the "found absolute touchpad" message, then EVDEV_TOUCHPAD is already set. The only way how you could trigger this hunk would be if you have a device that has both ABS_PRESSURE and BTN_TOUCH. - please check white-space diffs when submitting a patch, it keeps the noise down. And submitting a git-formatted patch helps maintainers a lot, see also http://wiki.x.org/wiki/Development/Documentation/SubmittingPatches Last hunk is the source for this bug. Pushed as a3ea979c2b70d166d62422b4ba450ce2910389c3. Thanks for fixing this.
I haven't upgraded my kernel recently, so that is not be the issue. Throwing out the first two hunks still leaves me with a broken touchpad. Hacking a little more I've come to the conclusion there are two issues going on: 1) The touchpad is being detected as a tablet. (no EVDEV_TOUCHPAD) 2) ABS_PRESSURE values are overwriting X-axis coordinates. 1) Can be solved with (hopefully) smarter tablet detection. ie if it has multiple buttons and BTN_TOOL_FINGER is valid, it's a touchpad (even if it has ABS_PRESSURE). If it's already been defined as a touchpad, don't call it a tablet. 2) Is happening because it's initialized for RelEvents but still accepting ABS_PRESSURE. axis_map[ABS_PRESSURE] is never initialized, and in my case just happens to overwrite the X value every time. My touchpad sets BTN_TOUCH and BTN_TOOL_FINGER when I touch the touchpad, and send ABS_PRESSURE for any movement, so these changes work for me. Again, this is a Dell D830, so it's a pretty mainstream model...
Created attachment 23896 [details] [review] new patch hunks 1 and 2 fix axis mapping hunks 3 and 4 fix make tablet detection better
can you please attach the output of evtest when you touch the pad? You can get a copy on http://people.freedesktop.org/~whot/evtest.c
Created attachment 23910 [details] evtest output
Created attachment 23938 [details] [review] 0001-Assume-touchscreen-touchpad-if-we-have-_either_-ABS_.patch what do you think of this check? I think it's better than the previous one and should cover the right type of devices.
On Mon, Mar 16, 2009 at 05:11:51PM -0700, bugzilla-daemon@freedesktop.org wrote: > Created an attachment (id=23938) > --> (http://bugs.freedesktop.org/attachment.cgi?id=23938) > 0001-Assume-touchscreen-touchpad-if-we-have-_either_-ABS_.patch > > what do you think of this check? I think it's better than the previous one and > should cover the right type of devices. So what's the actual difference between a touchpad and touchscreen with this: is it just that touchpads know the difference between fingers and other tools, whereas touchscreens do not?
coordinates from touchpads are converted into relative movements in-driver, touchscreens are just passed on as absolute. That's basically it.
Created attachment 23945 [details] [review] clear axis_map patch works for me, but again only in conjunction with the axis_map fix. here's a cleaner axis_map fix which works with your latest patch.
Created attachment 23946 [details] [review] 0001-If-we-have-a-touchpad-print-so-don-t-claim-we-re-c.patch Next one, print "configuring as touchpad" instead of "... tablet". Just a janitor patch. I noticed that I get occasional jumps to the upper right corner when touching the pad (only on the first touch). Do you get this on your pad as well? There seems to be a mixup with calculating the deltas. Jeremy: your axis_map patch is applied locally, will be pushed as soon as we get the rest sorted out.
Created attachment 23949 [details] [review] 0001-Fix-jumpy-touchpads-by-updating-old_vals-only-when-r.patch Ok, this should be the last one. With this one on top, the touchpad works now without the jumps I mentioned before.
--- Comment #11 from Peter Hutterer <peter.hutterer@who-t.net> 2009-03-16 20:18:41 PST --- > coordinates from touchpads are converted into relative movements in-driver, > touchscreens are just passed on as absolute. That's basically it. Hmm. Are you sure we don't need this to come from the kernel, then? I don't think that's a determination we can reliably make in -evdev.
Peter: not sure I had the last problem, but the patches all work for me.
(In reply to comment #15) > --- Comment #11 from Peter Hutterer <peter.hutterer@who-t.net> 2009-03-16 > 20:18:41 PST --- > > coordinates from touchpads are converted into relative movements in-driver, > > touchscreens are just passed on as absolute. That's basically it. > > Hmm. Are you sure we don't need this to come from the kernel, then? I > don't think that's a determination we can reliably make in -evdev. well, ideally, yes. realistically we need to decide this ourselves until the kernel does.
Patches are pushed, thanks for testing. AIUI, this bug is fixed now.
Hi Peter, Is there any chance you could cherry-pick the patches here along with 7cdb200dbe into the 2.2 branch? Maybe roll out a new release? Thanks
> --- Comment #19 from Rémi Cardona <remi@gentoo.org> 2009-03-23 00:22:13 PST --- > Is there any chance you could cherry-pick the patches here along with > 7cdb200dbe into the 2.2 branch? Maybe roll out a new release? sure, didn't get to it today, 2.2.1 is scheduled for tomorrow or wednesday.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.