cursor jumping to screen border

[Samuel Creshal]

Even with xserver-xorg-core at version 2:1.10.1-1ubuntu1.2, incomplete valuators still cause the cursor to jump to the screen corners.

http://up.tao.at/download/c8a578b047fc4fbb205c4f0bee52532e/xev_with_new_xserver ← Last tap (time 1494xxx) ended up with the cursor not where it should again (coordinates 600,675 would be correct, 1079,675 aren't).
http://up.tao.at/download/69e5a847d775f8fde8185fcf9345f0d9/evtest_with_new_xserver ← incomplete valuators, both on X and Y axis.

ProblemType: Bug
DistroRelease: Ubuntu 11.04
Package: xorg 1:7.6+4ubuntu3.1
ProcVersionSignature: Ubuntu 2.6.38-11.48-server 2.6.38.8
Uname: Linux 2.6.38-11-server x86_64
Architecture: amd64
CompizPlugins: No value set for `/apps/compiz-1/general/screen0/options/active_plugins'
Date: Wed Aug 24 10:33:26 2011
DistUpgraded: Fresh install
DistroCodename: natty
DistroVariant: ubuntu
GraphicsCard:
 Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller [8086:2a42] (rev 07) (prog-if 00 [VGA controller])
   Subsystem: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller [8086:2a42]
   Subsystem: Intel Corporation Device [8086:2a42]
InstallationMedia: Ubuntu-Server 11.04 "Natty Narwhal" - Release amd64 (20110426)
MachineType: OEM OEM
ProcEnviron:
 LANGUAGE=en_US:en
 PATH=(custom, no user)
 LANG=en_US.UTF-8
 SHELL=/bin/zsh
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-2.6.38-11-server root=UUID=825941db-d8b4-41af-8208-b095c47eba13 ro quiet
Renderer: Unknown
SourcePackage: xorg
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 02/12/2009
dmi.bios.vendor: Phoenix Technologies, LTD
dmi.bios.version: 6.00 PG
dmi.board.name: Cantiga
dmi.board.vendor: Intel
dmi.board.version: PILLAR ROCK FAB2
dmi.chassis.type: 3
dmi.chassis.vendor: OEM
dmi.chassis.version: OEM
dmi.modalias: dmi:bvnPhoenixTechnologies,LTD:bvr6.00PG:bd02/12/2009:svnOEM:pnOEM:pvrOEM:rvnIntel:rnCantiga:rvrPILLARROCKFAB2:cvnOEM:ct3:cvrOEM:
dmi.product.name: OEM
dmi.product.version: OEM
dmi.sys.vendor: OEM
version.compiz: compiz N/A
version.ia32-libs: ia32-libs 20090808ubuntu13
version.libdrm2: libdrm2 2.4.23-1ubuntu6
version.libgl1-mesa-dri: libgl1-mesa-dri 7.10.2-0ubuntu2
version.libgl1-mesa-dri-experimental: libgl1-mesa-dri-experimental N/A
version.libgl1-mesa-glx: libgl1-mesa-glx 7.10.2-0ubuntu2
version.xserver-xorg: xserver-xorg 1:7.6+4ubuntu3.1
version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:6.14.0-0ubuntu4.1
version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.14.0-4ubuntu7.1
version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:0.0.16+git20110107+b795ca6e-0ubuntu7

[Timo Aaltonen (tjaalton)]

Ok, something still missing what makes a touchscreen behave like wacoms used to.

[Timo Aaltonen (tjaalton)]

Looks like we're missing one commit which is in the 1.10.x series. I'll push a new version to test.

[Timo Aaltonen (tjaalton)]

Actually, that same code is modified by our multitouch patch, so I think that particular commit (02d77caa36e430909a) doesn't apply here, and this is a new issue altogether?

[Chase Douglas (chasedouglas)]

Timo,

Please generate device recordings by following the instructions at https://wiki.ubuntu.com/Multitouch/Testing/uTouchEvEmu#Debugging. Then attach the device.record and device.prop file to the bug.

Thanks!

[Chase Douglas (chasedouglas)]

We can't really debug this issue without a device recording, so I'm moving this to incomplete.

[Samuel Creshal (samuel-creshal)]

re from vacation. Apparently, the hard disk with my developing environment is currently missing/stolen, so it might take some time to get back on testing.

[Samuel Creshal (samuel-creshal)]

evemu report showing broken valuators. Note that I never even came close to the screen borders while tapping/wiping, yet the cursor regularly jumped to the edges.

[Samuel Creshal (samuel-creshal)]

Btw.: Tested with vanilla xorg 10.4 under Arch Linux: No cursor jumps, no flickering. Seems to be really related to your custom patches.

[Jussi Pakkanen (jpakkane)]

When I play back the recording, the behaviour is the following (on both natty and oneiric):

A swipe from bottom to top. Then it stands still for a while and jitters a bit within a radius of ̃~5 pixels.

A second swipe from bottom to top. Then jitter as above.

After this the cursor jumps around different places a couple of times and then the recording ends.

Is this what is supposed to happen? If yes, then this would seem to be a kernel/device driver bug, because these movements are in the evemu trace file. It never jumps to any corners that I can see. Testing with xev gives only sane coordinates.

[Samuel Creshal (samuel-creshal)]

I never even came near the screen borders. This is what happens when I replay the record:
http://up.tao.at/download/e66a9a1d8828a299ca41fea9272a38f4/MVI_0823.mkv

For reference, what happens if you tap/swipe: http://up.tao.at/download/9748d6fb8231d96633ae160a8d0d4ceb/MVI_0824.mkv
What should happen (Arch with vanilla Xorg): http://up.tao.at/download/c203c555df265e22bd02384d77c0da5f/MVI_0825.mkv

[Jussi Pakkanen (jpakkane)]

If you look at the second video very carefully you can see that the cursor does not jump to the corner when the selection expands.

What probably happens is that the application that does the background selection does not handle XInput valuators properly. An extremely similar bug was fixed in Qt recently.

The reason this bug does not happen in Arch is that it does not provide this new XInput data so it uses "classic X" cursor location.

To fix this bug we need to find out which app does XFCE desktop selection, how it reads XInput data and fix that.

[Samuel Creshal (samuel-creshal)]

It's not just Xfce, it's the same behaviour in Gnome (Classic/Fallback, gfx chip of the embedded computer used is too weak for Unity) and Openbox with any program (no matter whether desktop, Firefox, Chromium, xev…).

However, I just noticed that the bug *only* occurs if the evdev axes swap is enabled (via xinput property 253 or xorg.conf-option "SwapAxes"). Without swapping, the behaviour is the same as in Arch (with swapping). Looks like a bug in that function?

[Jussi Pakkanen (jpakkane)]

It seems that in static EvdevProcessValuators the x and y coordinates are flipped and the result written back in the valuators. I could not fully decipher what the code is doing but attached is a patch which at least roughly shows where I think the problem is.

Chase, any comments on this?

[Ubuntu Foundations Team Bug Bot (crichton)]

The attachment "reorganize_valuator_masks.patch" of this bug report has been identified as being a patch. The ubuntu-reviewers team has been subscribed to the bug report so that they can review the patch. In the event that this is in fact not a patch you can resolve this situation by removing the tag 'patch' from the bug report and editing the attachment so that it is not flagged as a patch. Additionally, if you are member of the ubuntu-sponsors please also unsubscribe the team from this bug report.

[This is an automated message performed by a Launchpad user owned by Brian Murray. Please contact him regarding any issues with the action taken in this bug report.]

[Chase Douglas (chasedouglas)]

Jussi,

I don't think unsetting the valuator is necessary. The mask is zero'd on every evdev sync event, and only new values are set. I think this is really due to the axis swapping property being set. See my next comment :).

[Chase Douglas (chasedouglas)]

Samuel,

The evdev swap axes property has been deprecated since Natty. We are aware of issues with swap axes and the new masked valuators, but we don't have plans to resolve them.

There is a much more robust solution in the form of the Input Transformation Matrix property. It allows for any 2D affine transformation to be applied to the input, including rotation and inversion. Please see:

https://wiki.ubuntu.com/X/InputCoordinateTransformation

I am guessing that if you switch to using the transformation property this issue will go away, so I'm going to mark this as "Won't Fix". If you still have issues when the swap axes properties are not enabled, please reopen the bug.

Thanks!

[Samuel Creshal (samuel-creshal)]

> The evdev swap axes property has been deprecated since Natty.
I'd suggest putting that warning into the Xorg log (if the option is detected) and the manpage, I'm pretty sure that other users will have similar problems.

> There is a much more robust solution in the form of the Input Transformation
> Matrix property.
I'm already using the ITF for dual screen scaling, so I'm pretty sure that won't be a problem – will try tomorrow. Thanks for the feedback.

[Josh Bowman (bowman-josh)]

On the documentation front, I'd also have to mention that the xinput_calibrator still sets the Swap Axes property if you have a device that needs them to be swapped.

I have an eGalax touchscreen (0xeef:0001) with swapped axes that also happens to not always send the valuators for both axes between each pair of SYN events, and I'd be embarrassed to admit how long I've spent trying to track this down.

Anyway, I'm attaching a patch that resolves the issue for me. I've used the old_vals valuator_mask as a temporary inside EvdevProcessValuators, so the swap still works when values for both axes *are* available. (If that's not okay, we could create some other temporary.)

I will look into the affine transform, of course. But this patch keeps the system working, without changing the calibration routines.

Patch is based on xserver-xorg-input-evdev-dev_2.6.0-1ubuntu13 from Oneiric.

[Yaroslav Sterkhov (ellanteres)]

Looks I'm getting same eefect with newest releases of Ubuntu and evdev drivers (tried alot of combos, throughout 2012 year).
Simply, using transformation matrix with evdev driver wich inverts, scales or shift coordinates causes either jumping to border of screen or jitter when touch even happening, which makes usage of multi-display configuration with one or more touchscreens. Tested with 26.x and 3.2.x kernels, with all release since february of 2012. Using touchscreens: 3M MicroTouch EX II (since 3.x kerel their driver i sjust wrapper of evdev.. before that it calibration utility doesn't support multiple touchscreens) , also rugged BARQ screens (which supposed to be used with evdev).

This is conundrum, because even if I could even have skill to fix it and rebuild driver (but I have not enough knowledge to do so)our company would accept only official distros in production.