[PATCH libinput 0/24] Tablet support

[Benjamin Tissoires]

Hi Carlos,

[Adding a few people to the conversation]

I am working a little bit on the wacom.ko kernel driver and I can give
you some hints on the oddness around the events.

On Mon, Apr 21, 2014 at 1:11 PM, Carlos Garnacho <carlosg at gnome.org> wrote:
> Hey there!,
>
> Here's a few patches to have libinput handle events from tablets,
> these devices are basically pointer devices, with a varying range
> of extra buttons (either stylus or "pad" buttons), and extra ABS_*
> axes. These devices also often offer information about the stylus
> in use, and its BTN_TOOL_* codes.
>
> So I've gone for reusing and extending libinput_event_pointer, adding
> extra libinput_pointer_axis values, and adding an "axis_frame" event
> to mark the end of a set of simultaneous axis changes, and a "tool_update"
> event to mark tool changes (and delimit proximity). These features are
> only triggered if a new LIBINPUT_DEVICE_CAP_STYLUS capability is set.
>
> Caveats:
>
> * Many of these devices have also tactile strips or wheels, but these are
>   unhandled so far... On the devices I've got available for testing, current
>   kernel support seems varyingly inconsistent:
>
>   - One device has 2 strips, which report on ABS_RX/RY (radial??). Min/max

yep :(
I guess this was a bad attempt to reuse the existing definitions, and
now, you have the left strip with RX and the right with RY...

>     are 0..4096, but the reported values are 1,2,4,8,16... So effectively
>     a log2 scale, or more graphically a bit shifting over a bunch of 0s,
>     which is somewhat more resembling to the physical action on the strip.

That's how the device sends the data. Unfortunately, the kernel first
implemented this that way, and the xorg driver knows how to handle it.
And now, we are stuck because the kernel can not break user-space :(

>
>   - Another device has one wheel, reported through ABS_WHEEL. Even though
>     min/max are reported as [0..1023], on interaction it goes [0..71] (funky
>     range too)

The ring strips have a logical range of 0..71. But the ABS_WHEEL is
also shared by the wheel on the airsbrush pen, which can report either
1024 or 2048 values depending on the tablet generation. And since this
axis is shared by two different sources, only one range can be sent (I
am saying that on top of my head, I may be wrong, this seems a little
bit ugly).

>
>   We could just forward this as-is, but seems hindering enough to do anything
>   useful with those unless that behavior is corrected.

I somewhat managed to convince Wacom to clean up the kernel driver for Wayland.
So I would say that we should implement a proper thing in Wayland, or
at least discuss all together to redefine the kernel protocol used by
those tablets.

>
>   When supported, IMO it'd make sense to have those axes behave similar to
>   scroll axes, so the axis value increments or decrements depending on the
>   direction. I'm not sure if there would be cases where the absolute value
>   matters here?
>

I am sure there are. I remember an application which controlled the
transparency of a layer in the background depending on the position of
the finger on the strip. But believe me, this application used to do a
lot of things we do not commonly do in a Linux desktop. Still, we
should ask Wacom how their customers use the strips.

Cheers,
Benjamin


> * One thing worth noting is that axes are currently normalized, to [-1..1]
>   for stylus tilt, and [0..1] for everything else. I remember Peter's
>   tablet wayland protocol proposal basically forwarded input_absinfo, this
>   might not be fully compatible with that, although TBH I'm unsure
>   clamping/normalization should take place so high in the stack...
>
> * No filtering/hysteresis of coords is done yet.
>
> Cheers,
>   Carlos
>
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel