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 _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
