Hi all, Here are some notes I took while studying linux kernel driver and xdrv. Writing it out helped me make sure I understood the kernel's use of Serial #'s before giving my thumbs up to a related patch.
Maybe lots of you knew this stuff already but I didn't have total picture yet. Hopefully, it will help others. Maybe it will help the Waltop crew understand what current xdrv understands so they can possibly emulate in their kernel drivers (although I think they already know this stuff as well). Warning: I own none of these devices beyond Bamboo P&T to verify actual behavior. Also, I invented a few phrases; such as sub-device; to help me explain things easier. Wacom devices can contain one or more input sub-devices and these often share similar characteristics. The #1 example of this is that a stylus often has both a "pen" sub-device and an "eraser" sub-device and both of these have X/Y and Pressure values. This example shows a physical form of mutual exclusions since you must flip the sytlus to get the other sub-device (ignoring users that have more then one stylus). There are cases where multiple sub-devices can work concurrently. Things that can currently work concurrently: 1) Stylus or Mouse Tool (Pen, Eraser, Mouse, etc) 2) Mouse Tool of Intuos 1 or 2 (when #1 is Stylus Tool) 3) Buttons located on a wacom Pad (and Mouse wheel? How about strips?) 4) Secondary finger on multitouch devices such as Bamboo P&T In the case of Intous 1/2, the hardware internally supports assigning a serial # to each device coming into proximity to ease indivual tracking regardless of order of going out of proximity. There are perhaps other cases were concurrent operations are possible but they are restricted by kernel driver. For example, even though its possible to report Bamboo's P&T Touch events at same time as Stylus events, the Touch events are disabled while Stylus is in proximity. This is because your hand will most likely be resting on tablet while using stylus and these would be unwanted events. For USB devices, sub-device input data is multiplexed over a single Linux /dev/input device. To aid applications in demultiplexing the data, the concept of a serial channel was created. Each time a sub-device transmits input data, it will send a MSC_SERIAL event with a serial # of current sub-device and it will send an ABS_MISC set to a hardcode DEVICE_ID when in proximity or a 0 when going out of proximity. For all devices except Intous 1 and 2, the Stylus, Mouse, and Touch events of first finger are hard code to serial # 1 and any Pad buttons are hard coded to 0xffffffff (-1) for Intous series and 0xf0 for all others. If the Wacom device supports multi-touch then the second finger is assigned to serial # 2. Its OK to assign Stylus, Mouse, and Touch events to same serial # because they are mutually exclusive. For Intous devices, the Pad data is assigned to channel 0xffffffff (-1) and the Stylus/Mouse data are assigned a dynamic serial # as reported by hardware. A major concern with above approach is that the Linux input subsystem will filter out duplicate values for the same abs/key/event shared between multiple sub-devices of the same channel. If, for example, a pen wanted to inform application that it was at X coordinate 100 and then an eraser also wanted to inform application it was at X coordinate 100 then the eraser event would normally be filtered. For sub-devices that share same serial channel, the kernel driver enforces a rule to work around this issue. As a sub-device goes out of proximity, the kernel driver sets all its abs/key/event values to zero value (applications must deal with recieving these!). This also requires applications to assume all abs/key/events are at zero value when first coming into proximity. This way, for example, when a new sub-device needs to send an initial ABS_X with value of 0 the event will be filtered by linux input subsystem because of input filtering and application must assume its at zero. For concurrent sub-devices on different serial channels, this same trick doesn't work. There is an outstanding issue were if two concurrent sub-devices need to report abs/key/event values with same value then the linux input subsystem will drop one of the events. For sub-devices operating in Absolute, mode this isn't so bad (I think!) as the sub-device will eventually recover when updating absolute values once they slightly differ. For devices operating in relative mode, it will often appear as jerky cursor movement or Gesture logic becoming confused. Intous 1&2, Bamboo P&T, and Tablet PC users are the only ones that need to worry about this loss of data. Only Bamboo P&T normally operates in Relative mode and so see's the issue the most (TODO: How about Intous's Mouse?). The follow is a list of abs/key/events that each sub-device can send with some related information about possible values. Bamboo P&T and Tablet PC's -------------------------- * Stylus device - Channel 1 (implied) ABS_X - 0 during out-of-proximity ABS_Y - 0 during out-of-proximity ABS_PRESSURE - 0 during out-of-proximity ABS_DISTANCE BTN_TOUCH BTN_STYLUS BTN_STYLUS2 BTN_TOOL_PEN/BTN_TOOL_RUBBER - 1/0 based on proximity ABS_MISC - STYLUS/ERASER_DEVICE_ID/0 based on proximity FIXME: Send MSC_SERIAL to be consistent. * Finger 1 - Channel 1 ABS_X - 0 during out-of-proximity ABS_Y - 0 during out-of-proximity ABS_MISC - TOUCH_DEVICE_ID/0 based on proximity MSC_SERIAL - 1 always BTN_TOUCH - 1/0 based on proxmity BTN_TOOL_DOUBLE_TAP - 1/0 based on proximity * Finger 2 - Channel 2 ABS_X - 0 during out-of-proximity ABS_Y - 0 during out-of-proximity ABS_MISC - TOUCH_DEVICE_ID/0 based on proximity MSC_SERIAL - 2 always BTN_TOUCH - 1/0 based on proxmity BTN_TOOL_TRIPLE_TAP - 1/0 based on proximity * Pad Buttons (Only Bamboo) - Channel 0xf0 BTN_0, BTN_1, BTN_2, BTN_3 - 1/0 based on button press BTN_TOOL_FINGER - 1/0 based on proximity - FIXME: Align with others nd fix to 0xf0. ABS_MISC - PAD_DEVIDE_ID/0 based on proximity MSC_SERIAL - 0xf0 always Graphire 4 and MO ----------------- * Stylus - Channel 1 (implied) ABS_X ABS_Y ABS_PRESSURE BTN_TOUCH BTN_STYLUS BTN_STYLUS2 BTN_TOOL_PEN/BTN_TOOL_RUBBER ABS_MISC STYLUS/ERASER_DEVICE_ID FIXME: Send MSC_SERIAL to be consistent. * Mouse - Channel 1 (implied) ABS_X ABS_Y BTN_LEFT BTN_RIGHT ABS_DISTANCE REL_WHEEL - FIXME: Issue with Pad for G4? ABS_MISC - CURSOR_DEVICE_ID/0 based on proximity FIXME: Send MSC_SERIAL to be consistent. * Pad Buttons/Wheel - Channel 0xf0 BTN_0, BTN_4 - 1/0 based on button press BTN_1, BTN_5 (Graphire MO) REL_WHEEL (Graphire 4) ABS_WHEEL (Graphire MO) BTN_TOOL_FINGER - fixed to 0xf0 ABS_MISC - PAD_DEVICE_ID/0 based on proximity MSC_SERIAL - 0xf0 always Intuos ------ * Mouse - channels ? to ? ABS_X ABS_Y ABS_DISTANCE ABS_TILT_X ABS_TILT_Y BTN_LEFT, BTN_MIDDLE, BTN_RIGHT, BTN_SIDE, BTN_EXTRA ABS_THROTTLE ABS_RZ BTN_TOOL_MOUSE/BTN_TOOL_LENS ABS_MISC - Device ID(which is BTN_TOOL_*)/0 based on proximity MSC_SERIAL - dynamic serial # reported by HW * Stylus - channels ? to ? ABS_X ABS_Y ABS_DISTANCE ABS_TILT_X ABS_TITLE_Y ABS_PRESSURE BTN_STYLUS, BTN_STYLUS2, BTN_TOUCH ABS_WHEEL BTN_TOOL_PENCIL/BTN_TOOL_PEN/BTN_TOOL_BRUSH/BTN_TOOL_RUBBER/BTN_TOOL_AIRBRUSH ABS_MISC - Device ID(which is BTN_TOOL_*)/0 based on proximity MSC_SERIAL - dynamic serial # reported by HW * Pad Buttons - channel 0xffffffff (-1) BTN_0, BTN_1, BTN_2, BTN_3, BTN_4, BTN_5, BTN_6 ABS_WHEEL BTN_7, BTN_8 (for Intuos 4S and 12UX2) BTN_9 (for ?? and 12UX2) BTN_A, BTN_B, BTN_C, BTN_X, BTN_Y, BTN_Z, BTN_BASE, BTN_BASE2 (for 12UX2) ABS_RX ABS_RY BTN_TOOL_FINGER - 1/0 based on proximity - FIXME: Fix to 0xf0 to align with others ABS_MISC - PAD_DEVICE_ID/0 based on proximity MSC_SERIAL - 0xffffffff (-1) always TODO: PTU and PL do not use MSC_SERIAL at all so ignoring for now. That means implied serial # 1
------------------------------------------------------------------------------
_______________________________________________ Linuxwacom-devel mailing list Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
