[PATCH libinput 0/24] Tablet support

[Benjamin Tissoires]

On Thu, May 22, 2014 at 1:17 AM, Chandler Paul <thatslyude at gmail.com> wrote:
> Hi! Sorry this took so long to write, I've been spending a lot of my
> time recently trying to understand the libinput code and all of that
> good stuff, and I wanted to make sure I had a decent understanding of it
> before I actually wrote up a response.
>
> On Mon, 2014-04-21 at 19:11 +0200, Carlos Garnacho 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.
> I'm with Peter on splitting these up. It seems kind of inconsistent with
> the rest of libinput (with what I've gathered, anyway). A
> tablet-specific event sounds interesting too, but I feel like
> compressing all of the axis changes into. For now I'm going to work on
> having all the axis changes reported as separate POINTER_AXIS events.
>
>>
>> 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
>>     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.
> Since I'm on a deadline for this and making changes to this in the
> kernel would take too long, I don't think I'm going to advocate for
> changing this behavior right now. Although I do agree that eventually it

We already agree with Wacom that it's the proper time to change stuffs
in the kernel. I am currently working on it when I find some time, and
I would appreciate any inputs on how things should be done.

For example, the more I think of it, the more I think the tool ID does
not make sense in the wacom kernel driver. This is used to multiplex
the different stylus, mice, pads, through one only device, but it
introduces a lot of problems. Not speaking that later on, Xorg splits
those in physical devices. I know we are talking about Wayland, but
given that we are building the protocol here, I think we should also
think at what could be done in the kernel.

Anyway, I was thinking at reporting several input devices for one
Wacom (per stylus/eraser/mouse/pad - still not sure if I have to split
the different stylus) so that there is no more multiplexing of the
events and no difficult states to keep track to.

Basically Lyude, just tell me your dreams (or keep track of them while
writing the Wayland part) and we can start implementing them :)

Cheers,
Benjamin