Created attachment 37948 [details] [review] Don't treat Pen event as tool if device is also Touch capable I have a touchscreen that doesn't work properly with evdev. It takes moving events properly, but taps are always done at the previous coordinates. So to tap, you'd need to drag the pointer to the touch area, and then tap. I'm using Debian Squeeze, and I was able to reproduce the problem with squeeze and upstream git evdev. I can see the events correctly when I dump it with evtest, but apparently xorg evdev driver is ignoring the coordinates sent with taps. After, searching through the code, it's apparently ignoring the coordinates because the tool is not set, and it has a special treatment for wacom tablets that ignores absolute events if tool is not set. The problem is that this device reports ToolPen and Touch, so after first correct tap (tool is initalized at TRUE), tool will always be FALSE during taps, and coordinates will be ignored. The attached patch is an attempt to fix that with minimal impact on the code. evtest dump with two taps at different coordinates: # evtest /dev/input/event5 Input driver version is 1.0.0 Input device ID: bus 0x3 vendor 0x1cb6 product 0x6681 version 0x110 Input device name: "IDEACO IDC 6681" Supported events: Event type 0 (Sync) Event type 1 (Key) Event code 272 (LeftBtn) Event code 273 (RightBtn) Event code 320 (ToolPen) Event code 330 (Touch) Event type 3 (Absolute) Event code 0 (X) Value 5756 Min 0 Max 8191 Event code 1 (Y) Value 1878 Min 0 Max 8191 Event code 2 (Z) Value 0 Min 0 Max 65535 Event code 3 (Rx) Value 0 Min 0 Max 65535 Event code 24 (Pressure) Value 0 Min 0 Max 1 Event type 4 (Misc) Event code 4 (ScanCode) Testing ... (interrupt to exit) Event: time 1282139749.122391, type 3 (Absolute), code 1 (Y), value 1820 Event: time 1282139749.122402, type 3 (Absolute), code 0 (X), value 5354 Event: time 1282139749.122407, -------------- Report Sync ------------ Event: time 1282139749.130384, type 4 (Misc), code 4 (ScanCode), value d0042 Event: time 1282139749.130388, type 1 (Key), code 330 (Touch), value 1 Event: time 1282139749.130392, type 1 (Key), code 320 (ToolPen), value 1 Event: time 1282139749.130405, -------------- Report Sync ------------ Event: time 1282139749.202378, type 3 (Absolute), code 1 (Y), value 1832 Event: time 1282139749.202394, -------------- Report Sync ------------ Event: time 1282139749.210391, type 4 (Misc), code 4 (ScanCode), value d0042 Event: time 1282139749.210397, type 1 (Key), code 330 (Touch), value 0 Event: time 1282139749.210403, type 1 (Key), code 320 (ToolPen), value 0 Event: time 1282139749.210422, -------------- Report Sync ------------ Event: time 1282139757.770838, type 3 (Absolute), code 1 (Y), value 1808 Event: time 1282139757.770847, type 3 (Absolute), code 0 (X), value 3828 Event: time 1282139757.770852, -------------- Report Sync ------------ Event: time 1282139757.778833, type 4 (Misc), code 4 (ScanCode), value d0042 Event: time 1282139757.778839, type 1 (Key), code 330 (Touch), value 1 Event: time 1282139757.778845, type 1 (Key), code 320 (ToolPen), value 1 Event: time 1282139757.778861, -------------- Report Sync ------------ Event: time 1282139757.818821, type 4 (Misc), code 4 (ScanCode), value d0042 Event: time 1282139757.818825, type 1 (Key), code 330 (Touch), value 0 Event: time 1282139757.818828, type 1 (Key), code 320 (ToolPen), value 0 Event: time 1282139757.818839, -------------- Report Sync ------------ # lsusb -v -d 1cb6:6681 Bus 005 Device 002: ID 1cb6:6681 Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 8 idVendor 0x1cb6 idProduct 0x6681 bcdDevice 1.00 iManufacturer 1 IDEACO iProduct 2 IDC 6681 iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 59 bNumInterfaces 2 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xa0 (Bus Powered) Remote Wakeup MaxPower 100mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 3 Human Interface Device bInterfaceSubClass 0 No Subclass bInterfaceProtocol 0 None iInterface 0 HID Device Descriptor: bLength 9 bDescriptorType 33 bcdHID 1.10 bCountryCode 0 Not supported bNumDescriptors 1 bDescriptorType 34 Report wDescriptorLength 254 Report Descriptors: ** UNAVAILABLE ** Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0008 1x 8 bytes bInterval 10 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 3 Human Interface Device bInterfaceSubClass 0 No Subclass bInterfaceProtocol 0 None iInterface 0 HID Device Descriptor: bLength 9 bDescriptorType 33 bcdHID 1.10 bCountryCode 0 Not supported bNumDescriptors 1 bDescriptorType 34 Report wDescriptorLength 71 Report Descriptors: ** UNAVAILABLE ** Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0008 1x 8 bytes bInterval 10 Device Status: 0x0000 (Bus Powered) Note that you have a second HID interface, but it's not reporting anything. Also, evdev "4 points only" calibration makes it less precise of about 15 pixels (at first sight) on the left part of the screen. Windows 7 allows to use more points during calibration (just like evtouch did), which makes it very precise.
Created attachment 37949 [details] [review] Fix Touchscreen detection Another problem we have here is that touchscreen is not detected properly, since Evdev has no way to tell what type a device is. It's detected as a tablet. Fix device type detection so that this kind of device will be reported as a touchscreen in the future. Please note that this patch and the previous one are based on git HEAD, so they need commit 899218e18120918138f6d7420465763422d5b3b7 "Don't count BTN_TOUCH as tool. (#29428)" to work, if someone ever wanted to backport them to evdev-2.3 branch.
Created attachment 37950 [details] [review] Rewriting of first patch based on more correct touchscreen detection If we have correct device type detection (previous attachment), we can rewrite the first patch (attachment 37948 [details] [review]: Don't treat Pen…) to be less intrusive and more generic to touchscreens. This patch depends on attachment 37949 [details] [review]: Fix Touchscreen detection
Created attachment 37953 [details] [review] Another approach: narrow special treatment to tablets Another approach, if we have correct device type detection (attachment 37949 [details] [review]: Fix Touchscreen detection), is to narrow the special treatment of tool to tablets. I can't say which approach is the best. I don't have any tablet to test if it will cause a regression. Maybe I should add Adam Jackson in Cc; he added the special treatment for Wacom tablets in commit 6271494f.
Review of attachment 37948 [details] [review]: this patch is too generic. all tablets I've seen so far that have BTN_TOOL_PEN also have BTN_TOOL_TOUCH so you essentially just disable the tool setting for those.
just to let you know, the review isn't my only comment here. I'm still trying to figure out how to integrate this without breaking other devices.
(In reply to comment #4) > Review of attachment 37948 [details] [review]: > > this patch is too generic. all tablets I've seen so far that have BTN_TOOL_PEN > also have BTN_TOOL_TOUCH so you essentially just disable the tool setting for > those. Well, then I guess this applies to attachment 37949 [details] [review] too, because it uses the same test to differentiate touchscreens from tablets (has TOOL_PEN and does not have TOOL_TOUCH). (In reply to comment #5) > just to let you know, the review isn't my only comment here. I'm still trying > to figure out how to integrate this without breaking other devices. Me too, and that's why I tried to provide three different patchsets : - attachment 37948 [details] [review] - attachment 37949 [details] [review] and attachment 37950 [details] [review] - attachment 37949 [details] [review] and attachment 37953 [details] [review] Unfortunately, at least for device type detection this won't be enough. I didn't find another way to rework the code flow when I looked at it; maybe we'll have to resort to quirk lists for "bad" devices that don't report proper HID information.
http://cgit.freedesktop.org/~whot/xf86-input-evdev/log/?h=proximity I think something like this may make sense, though I'm still fighting with some unrelated bug when it comes to wacom handling.
Another approach: add an Option to allow user to force device type. This is a touchscreen, so I'll have to create an InputClass file in /etc/X11/xorg.conf.d anyway to add touchscreen calibration value. One could create a new option to force device type for a matching device, e.g: Option "DeviceType" "touchscreen" These would match evdev flags and/or XInput types "touchscreen", "touchpad", "tablet", "keyboard", "mouse"… Ideally, this would be added at XInput level, but right now evdev level is enough since it's the only driver relying on type detection to have different behavior per device.
should be fixed by the commit below, can you confirm this please? commit b48f4c41c0d3386bba3e9d8fa3da91f18aae190b Author: Peter Hutterer <peter.hutterer@who-t.net> Date: Mon Oct 11 09:33:28 2010 +1000 Add proximity support.
(In reply to comment #9) > should be fixed by the commit below, can you confirm this please? > > commit b48f4c41c0d3386bba3e9d8fa3da91f18aae190b > Author: Peter Hutterer <peter.hutterer@who-t.net> > Date: Mon Oct 11 09:33:28 2010 +1000 > > Add proximity support. I compiled git master today, and the problem is indeed fixed. Thank you.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.