evdev: workaround for missing ABS_X/Y on multitouch devices (mostly Android)
Peter Hutterer
peter.hutterer at who-t.net
Tue Jun 24 18:39:46 PDT 2014
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
More information about the xorg-devel
mailing list