The "pad" device on Wacom's MobileStudio Pro is ignored by libinput due to it being tagged as an accelerometer in udev. This tag is correct, but prevents e.g. libinput-debug-events from displaying touchring data. ~~~ # libinput-debug-events --device /dev/input/event20 --verbose WARNING: This compatibility wrapper will be removed in the future. Please run 'libinput debug-events' instead event20 - Wacom MobileStudio Pro 16 Pad: is tagged by udev as: Tablet Accelerometer TabletPad event20 - Wacom MobileStudio Pro 16 Pad: device is an accelerometer, ignoring event20 - not using input device '/dev/input/event20'. Failed to initialized device /dev/input/event20 ~~~ ~~~ # EVEMU 1.3 # Kernel: 4.12.3-1-ARCH # DMI: dmi:bvnDellInc.:bvrA07:bd01/21/2011:svnDellInc.:pnOptiPlex980:pvr:rvnDellInc.:rn0D441T:rvrA03:cvnDellInc.:ct3:cvr: # Input device name: "Wacom MobileStudio Pro 16 Pad" # Input device ID: bus 0x03 vendor 0x56a product 0x34e version 0x110 # Supported events: # Event type 0 (EV_SYN) # Event code 0 (SYN_REPORT) # Event code 1 (SYN_CONFIG) # Event code 2 (SYN_MT_REPORT) # Event code 3 (SYN_DROPPED) # Event code 4 ((null)) # Event code 5 ((null)) # Event code 6 ((null)) # Event code 7 ((null)) # Event code 8 ((null)) # Event code 9 ((null)) # Event code 10 ((null)) # Event code 11 ((null)) # Event code 12 ((null)) # Event code 13 ((null)) # Event code 14 ((null)) # Event code 15 (SYN_MAX) # Event type 1 (EV_KEY) # Event code 256 (BTN_0) # Event code 257 (BTN_1) # Event code 258 (BTN_2) # Event code 259 (BTN_3) # Event code 260 (BTN_4) # Event code 261 (BTN_5) # Event code 262 (BTN_6) # Event code 263 (BTN_7) # Event code 264 (BTN_8) # Event code 265 (BTN_9) # Event code 304 (BTN_SOUTH) # Event code 305 (BTN_EAST) # Event code 306 (BTN_C) # Event code 331 (BTN_STYLUS) # Event type 3 (EV_ABS) # Event code 0 (ABS_X) # Value -15 # Min -2048 # Max 2048 # Fuzz 0 # Flat 0 # Resolution 0 # Event code 1 (ABS_Y) # Value -15 # Min -2048 # Max 2048 # Fuzz 0 # Flat 0 # Resolution 0 # Event code 2 (ABS_Z) # Value -1014 # Min -2048 # Max 2048 # Fuzz 0 # Flat 0 # Resolution 0 # Event code 8 (ABS_WHEEL) # Value 0 # Min 0 # Max 1 # Fuzz 0 # Flat 0 # Resolution 0 # Event code 40 (ABS_MISC) # Value 0 # Min 0 # Max 0 # Fuzz 0 # Flat 0 # Resolution 0 # Properties: # Property type 6 (INPUT_PROP_ACCELEROMETER) N: Wacom MobileStudio Pro 16 Pad I: 0003 056a 034e 0110 P: 40 00 00 00 00 00 00 00 B: 00 0b 00 00 00 00 00 00 00 B: 01 00 00 00 00 00 00 00 00 B: 01 00 00 00 00 00 00 00 00 B: 01 00 00 00 00 00 00 00 00 B: 01 00 00 00 00 00 00 00 00 B: 01 ff 03 00 00 00 00 07 00 B: 01 00 08 00 00 00 00 00 00 B: 01 00 00 00 00 00 00 00 00 B: 01 00 00 00 00 00 00 00 00 B: 01 00 00 00 00 00 00 00 00 B: 01 00 00 00 00 00 00 00 00 B: 01 00 00 00 00 00 00 00 00 B: 01 00 00 00 00 00 00 00 00 B: 02 00 00 00 00 00 00 00 00 B: 03 07 01 00 00 00 01 00 00 B: 04 00 00 00 00 00 00 00 00 B: 05 00 00 00 00 00 00 00 00 B: 11 00 00 00 00 00 00 00 00 B: 12 00 00 00 00 00 00 00 00 B: 14 00 00 00 00 00 00 00 00 B: 15 00 00 00 00 00 00 00 00 B: 15 00 00 00 00 00 00 00 00 A: 00 -2048 2048 0 0 0 A: 01 -2048 2048 0 0 0 A: 02 -2048 2048 0 0 0 A: 08 0 1 0 0 0 A: 28 0 0 0 0 0 ################################ # Waiting for events # ################################ ~~~
doh. didn't we at some point have an agreement that accelerometers are special and always on their own kernel device? Looks like some extra special casing is needed here, we still want to ignore the x/y axes.
IIRC, the accelerometer discussions came about in response to the 27QHD which was the first Wacom device to have one. Ping introduced INPUT_PROP_ACCELEROMETER [1] for it and you later [2] documented the meaning of the property: > Directional axes on this device (absolute and/or relative x, y, z) represent > accelerometer data. All other axes retain their meaning. A device must not mix > regular directional axes and accelerometer axes on the same event node. I imagine this issue wasn't noticed with the 27QHD because it only has the soft KEY_* buttons (which aren't yet handled in userspace) -- no ExpressKeys, rings, or other controls. ... Unless I'm forgetting a more recent discussion of accelerometer data? [1]: https://patchwork.kernel.org/patch/5720721/ [2]: https://patchwork.kernel.org/patch/6102851/
Oops, hit the submit button too quickly. Also wanted to add that in [2] above, you specifically mention in the commit comment "This allows an accelerometer device to e.g. have an ABS_WHEEL" which is exactly the case here.
(In reply to Jason Gerecke from comment #0) > # Event code 8 (ABS_WHEEL) > # Value 0 > # Min 0 > # Max 1 ^ is this really correct? seems like less of a wheel and more like a button :) as for the rest - yeah, I remember again now, thanks. Should be an easy fix once you confirm the wheel range.
(In reply to Peter Hutterer from comment #4) > (In reply to Jason Gerecke from comment #0) > > # Event code 8 (ABS_WHEEL) > > # Value 0 > > # Min 0 > > # Max 1 > > ^ is this really correct? seems like less of a wheel and more like a button > :) > > as for the rest - yeah, I remember again now, thanks. Should be an easy fix > once you confirm the wheel range. Yeah, noticed that as well. Recently fixed in xf86-input-wacom: https://github.com/linuxwacom/xf86-input-wacom/commit/1a2a23c2df0ec0fd0bf46432db58f32914a6a09f https://github.com/linuxwacom/xf86-input-wacom/commit/b30e2d27fdb30ff4b425fc62432cab636fe163b9
that looks like a different issue, what I'm referring to here is that the *range* of the wheel is 0 to 1 - that's not a wheel? or am I missing something here?
The xf86-input-wacom driver isn't so good at using the kernel for feature/range detection. The first patch I linked ensures the "WCM_RING" flag is set for this device. Without that flag, the ring valuator is created with a range of [0, 1] like seen here (I assume as a placeholder for obscure backwards-compat reasons) rather than the correct kernel-described range. Applying the patch does fix the range, but there's definitely a deeper more systemic issue too.
but the evemu record above shows the kernel device - and that's 0-1. So regardless what xf86-input-wacom does, this looks like a kernel bug?
Ah, indeed. I'd recently fixed the X issue and for some reason was thinking about it instead of the similar kernel issue. The fix for the kernel bug was accepted by Jiri it into his "for-4.13/upstream-fixes" branch as 8d411cbf46 ("HID: wacom: Do not completely map WACOM_HID_WD_TOUCHRINGSTATUS usage"). I CCd stable as well.
what's the new range? that commit doesn't give me any info here - still 0..71?
https://lists.freedesktop.org/archives/wayland-devel/2017-August/034850.html
(In reply to Peter Hutterer from comment #10) > what's the new range? that commit doesn't give me any info here - still > 0..71? Range is 0..71 for the 2nd-gen Intuos Pro and 0..35 for the MobileStudio Pro. libinput seems to correctly rescale the different ranges for both devices to 0..359 degrees.
commit 7d97bb008789448cdd80eceac0d4072ce05e4006 Author: Peter Hutterer <peter.hutterer@who-t.net> Date: Fri Aug 18 05:32:02 2017 +1000 evdev: accept accelerometers if they are tagged as other devices too
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.