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

[Peter Hutterer]

On Tue, Jun 24, 2014 at 10:47:14AM +0100, Colin Macdonald wrote:
> 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).

it's doable, and with libevdev fairly simple nowadays, we'd only have to
call libevdev_set_abs_info() and be done with it. Send a patch and I'll
merge this.

Cheers,
   Peter