[PATCH libinput 0/24] Tablet support

[Carlos Garnacho]

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

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

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

  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?

* 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