evdev: workaround for missing ABS_X/Y on multitouch devices (mostly Android)

[Colin Macdonald]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

I filed this as
[https://bugs.freedesktop.org/show_bug.cgi?id=80470].  But perhaps
worthy of maillist discussion...

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]
[https://bugs.freedesktop.org/show_bug.cgi?id=64029]

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).

thanks,
Colin

- -- 
Colin Macdonald
University Lecturer in Numerical Methodologies
Tutorial Fellow at Oriel College
University of Oxford
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJTqUkhAAoJEAzlCRPFMm7lsmEH/2j+Ywed9fH1I9GkBcxgoov+
UuCm+MQGAcTFIvbnZu6ETPehzz5fVRMz5GkU8DGGzPjJFuqE9hzEZ/oanM8jB7Ac
ei0CQz3vod7es78lgq1T/fzSS6+fuJBkrz+5Hr4ENXh9OzaAmkVy6bsawRZMAAmX
A/Qkpukm4TdnYatkGgcNYGi/VXqRA95pYXG8ocZg5IWifxZuCQGIIsBuTp+cjIFk
I7bsFPfRYRMtNzt/aPUtGc4d/MEFmyvSMGNvaKD0SrNnn/qg8Fg9XeSVVMmK2yS5
qm84RswgDdzJY95T+FFF3vV152oTU7RiYX5yCijn+sY3qmWsNli3PWhlWTZ7OeU=
=p41R
-----END PGP SIGNATURE-----