On 12/22/2011 04:48 AM, Ben Bucksch wrote: > On 22.12.2011 07:41, Chase Douglas wrote: >> You can fiddle with the input class like you have been to resolve this. >> Add these lines to your input class: >> >> Driver "evdev" >> Option "Mode" "Absolute" > > I did this, but then the clicks by tapping don't work at all anymore. > I.e. mouse cursor follows my finger, but I cannot activate anything.
If I had to guess, BTN_TOOL_FINGER is likely still getting in the way of things in the evdev driver. >> Or, fix your driver so it works properly. Simply removing the >> registration of the BTN_TOOL_EVENT should work. It doesn't even use >> BTN_TOOL_FINGER. I've seen this exact issue on almost every driver of >> Android origin, like they're all copy& pasted. > > Do you think I should still proceed this way, given above? It looks like you need to fix your kernel driver. You could hack up xserver-xorg-input-evdev to disregard the BTN_TOOL_FINGER event, but I would only do that if you can't fix the kernel driver. >> You may know this already as well, but your driver/device is only >> operating as a single-touch capable device. maXTouch chips all support >> at least some multitouch, IIRC. There is an upstream Linux driver for >> these chips, and it supports multitouch. > > Yes, I know. For a start, I'd be quite happy to get a single finger and > a nice onscreen keyboard working properly. > > You mean hid-multitouch or some other one? The hid-multitouch didn't > work, because the USD IDs are not registered and apparently the udev > rules trich failed as well. I'll try adding the IDs and recompile the > kernel, if you think that will make it work properly. No, the maXTouch chips are handled by atmel_mx_ts in drivers/input/touchscreen/atmel_mx_ts.c. -- Chase _______________________________________________ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
