(Bug #64029 fixes the crash related to this.) 1) The Kernel spec says multitouch devices should give ABS_X and ABS_Y events as well as ABS_MT_POSITION_X. [http://lists.x.org/archives/xorg/2013-July/055823.html] 2) Many drivers (maybe even most?) for Android devices don't give ABS_X. I've personally played with Note 8 (synaptics_s7301 touchscreen driver), Nexus 5 (synaptics RMI4 drivder). I've looked at several other drivers (various Atmel MaXTouch, there is a mainline atmel_mxt_ts driver which does the right thing but seems devices often use older mxt224 drivers...). 3) Its not clear if many drivers are destined for mainline (Android looks like a fragmented and horrid dev scene compared to GNU/Linux). The device turnover is so fast. 4) The cause here is probably the Android docs: https://source.android.com/devices/tech/input/touch-devices.html#touch-device-classification which suggest (or at least imply) its OK for multitouch to not give ABS_X. 5) Fixing these upstream is a noble goal but difficult to have much impact---I've grabbed the cyanogenmod sources for my Note 8 and Nexus 5 with the thought to to look into doing this. But even if I fix these two drivers, it is not likely to reach many people. 6) Its much easier to compile a new xf86-input-evdev than to recompile and replace an Android OS. For example, I have a standard Fedora 20 in a chroot on my devices, which can talk to the framebuffer, even with (essentially) the out-of-box OS (called "ROM" in Android community)... Pen works great, just no touchscreen b/c of this. ---------------------- Given the above, I think it might be more pragmatic to work around the the ABS_X issue. We could still give a (WW) warning (instead of an error) pointing out its contrary to kernel spec. I'm hopeful that such a workaround would involve changes only to evdev.c. Please advise if you think that's not the case (so I can decide whether to tackle this or 5) above).
I hacked a little on this at [https://github.com/cbm755/xf86-input-evdev], in the noabsx branch.
There are plenty of desktop devices which not always send absolute coordinates as well.. ran into it with BARQ rugged displays (they have embedded touchscreen and keys on the bevel) and rugged Dell's with egalax sensor.. as I wasn't using any driver for that , but standard one - because producer doesn't provide drivers for kernel above 2.6, claiming that "new kernels would support them all" - I think it's design of controller's firmware. Another issue with those that they weren't sending coordinates at certain events at all, which was causing jittery on older version of Xorg.. now it seems to be fixed
Feel free to send a patch to xorg-devel, I'll review it
commit b370ccdff8f721de75d3d91486cc4807668d040c Author: Colin B. Macdonald <macdonald@maths.ox.ac.uk> Date: Thu Jun 26 12:17:59 2014 +0100 Workaround lack of ABS_X on MT devices (#80470)
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.