Created attachment 58532 [details] Process-ABS_-X-Y-even-if-multitouch-is-enabled.patch Currently xf86-input-evdev can not handle devices, which use pens creating pure ABS_X, ABS_Y events and multitouch events at the same time. Thats because non multitouch events get blocked, if mt_mask is set. The following patch changes the behavior to unblock ABS_X and ABS_Y events. This should fix problems occurring with mixed multitouch and pen tablets, smartboards and similar devices. It's been tested with a promethean smartboard[1] greetings Max Krueger and Thorsten Wissmann [1]http://git.cs.fau.de/?p=re06huxa/promethean-activboard
This probably needs a little thought on what types of pen+touch we want to support and how their events should look. I'm copy&pasting this sequence from linux-input list were patch was originally proposed. Here is proposed event sequence for pen+touch combo device (single /dev/input device) from Chase Douglas: # finger touch (Note lack of tool, it's assumed to be finger) ABS_MT_SLOT 0 ABS_MT_TRACKING_ID 42 ABS_MT_POSITION_X finger_x ABS_MT_POSITION_Y finger_y SYN_MT_REPORT ABS_X finger_x ABS_Y finger_y SYN_REPORT # finger release ABS_MT_SLOT 0 ABS_MT_TRACKING_ID -1 SYN_REPORT # pen motion BTN_TOOL_PEN 1 ABS_X pen_x ABS_Y pen_y SYN_REPORT # finger touch begin ABS_MT_SLOT 0 ABS_MT_TRACKING_ID 42 ABS_MT_POSITION_X finger_x ABS_MT_POSITION_Y finger_y SYN_MT_REPORT BTN_TOOL_PEN 0 ABS_X finger_x ABS_Y finger_y SYN_REPORT The important part to note here is ABS_X/Y values can be related to Pen or Touch and its only possible to tell difference by looking at current value of BTN_TOOL_PEN. I believe the proposed patch assumes ABS_X/Y would not be sent from kernel side for touch case. If we decide thats good approach then patch works. If we decide we want to support "pointer emulation" for pen+touch devices then probably the patch should make use of "in_proximity" somehow (maybe "else if (!pEvDev->mt_mask || (pEvDev->in_proximity && pEvDev->new_var_tool_is_not_touch)"). One day a pen+touch single /dev/input touchpad may show up; in which case BTN_TOOL_FINGER would be sent. Or it may be sent even for touchscreens that also set INPUT_PROP_DIRECT property. So having a new_var_tool_is_not_touch will be most helpful for those two cases.
would the wacom driver work for these devices? It should already deal with this event sequence since it multiplexes.
Yes, I think the xf86-input-wacom driver would work with this device (if mapped away from xf86-input-evdev anyways) since it is basically same as wacom_w8001 device. The one difference between wacom_w8001 and the "recommended" list of events in comment #1 is wacom_w8001 does not send ABS_X/Y events during finger touches/MT events. xf86-input-wacom was designed to handle that combo gracefully but never tested since real driver didn't exist. So if it didn't work right, that is area bug would be.
This is a mass change of bugs. Bugs assigned to me that haven't been updated in the last 3 years are closed as WONTFIX, because, well, let's at least be honest about it. Please do not re-open unless you have a really good reason to do so (e.g. you're fixing it yourself). If it hasn't been fixed in the last 3 years, it probably won't be fixed anytime soon either. Sorry.
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.