Hovering distance not exposed to X11/XI2

[ChengduLittleA]

Hi developers!

I'm the developer of Our Paint. I'm looking to implement brush features based on pen hover distances, but this is not exposed as an valuator in XI2. The exposed ones are x,y,pressure,tiltx,tilty and rotation. And to get distance, it requires hover distance (ABS_DISTANCE) to be exposed to XI2 as well (I guess with valuator[6])

Hovering distance is readable as joystick axis ABS_DISTANCE from /dev/input/event* or /dev/input/by-id/usb-Wacom_Co._Ltd._Wacom_Cintiq_Pro_24_1CH00F1002467-event-mouse, but this requires sudo. It's best that the hovering distance is exposed via XI2 so that regular X11 application can access this value without needing permission to read raw inputs. It's always good to expose these values as the user could always take advantage of the data.

I have a cintiq pro 24, pro pen 2 and art pen. Both pen reports hovering distance correctly via /dev/input. (On windows wintab, this is easily available through pkt.pkZ).

Thanks!

[ChengduLittleA]

Looks like _WacomDeviceState already had distance and is correctly read from raw events. So just the matter of exposing it to an axis through XI2.

Basically the fix would be:

• Add a WACOM_AXIS_DISTANCE= (1 << 14), in WacomAxisType.
• Add a int distance to WacomAxisData.
• Add a WACOM_AXIS_DISTANCE entry to wcmInitAxis.
• Add corresponding entry in wcmInitAxes.
• May need to add an extra axis in wcmDevInit.
• Process distance with wcmAxisGet/wcmAxisSet in wcmSendNonPadEvents.

I believe this is it, not sure how to write and test this thing without a virtual machine...

Downside of this fix is that the distance axis is not on a fixed index. Depending on whether the stylus/pad (?) had smooth scrolling feature it may be pushed further than index 6. I believe styluses doesn't actually have more axis and those are from the pad/monitor controls so this should work :thinking:

[Pinglinux]

@ChengduLittleA The Xorg server is in maintenance mode (https://www.phoronix.com/news/X.Org-Maintenance-Mode-Quickly), which means no new features will be added to it. If you plan to support your app for future Linux users, please adapt to libinput and Wayland.

[ChengduLittleA]

Ah that's good to know...

I'd consider this as a bug tho, since the hover distance is read from the driver in xf86-input-wacom, and everything else beside this value is exposed as an valuator, so it makes sense that we can add this final one back into its place :sweat_smile:

[whot]

I believe styluses doesn't actually have more axis and those are from the pad/monitor controls so this should work 🤔

fwiw, of fe923e927a8ddf4d2e82ef4757c885b06d47fa03 pens have extra axes to provide for smooth pan scrolling. Pads don't because they only have an x/y axis for userstack to detect this as a tablet pad but there's no smooth scrolling (no hw really supports it anyway).

See 55a10e392f7337da0dfcc19a60f816aa7645f2df though for a side-effect if you expose more than 6 axes... :(

I believe this is it, not sure how to write and test this thing without a virtual machine...

Best option is to implement anything and test with -Dwacom-gobject=enabled which would allow you to implement the core driver bits and unittests for that. Only then do you need to implement the X driver bits so there's less crashing, ideally.

The traditional way is to have a second machine to ssh in to restart X if it crashes/hangs or for debugging.

Having said all that: unlikely to be merged as @Pinglinux already said above. And the hovering distance is extremely unreliable (several tablets will have nonzero distance when you're touching the screen) and it's not mapped to any physical distance anyway. So really it's only useful for relative interpretation (moving in/out) but very little more.

What are you trying to use this information for?