[PATCH libinput 0/24] Tablet support

[Ping Cheng]

On Mon, Apr 21, 2014 at 4:40 PM, Benjamin Tissoires
<benjamin.tissoires at gmail.com> wrote:
> 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 :(

We can change the implementation if it makes sense for future. But,
please keep in mind that adding new definitions to kernel takes time.

>>   - 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).

Airbrush wheel is always 0 to 1024. Touch ring on tablet is 0 to 71.
Both are in absolute values.

Maybe we can add ABS_WHEEL2 for touch ring. Then we'll at least need
ABS_WHEEL3 for Cintiq 24HD since it has two touch rings....

>>   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.

Yes, we are willing to work on a clean solution for Wayland.

>>
>>   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.

Benjamin is right. Those are absolute values. Most Linux applications
do not use those extra values. But, there are in-house applications
need those values. I'll have to ask around to give you some use cases
if you are interested.

Ping

>
> 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