[PATCH libinput 0/24] Tablet support

[Chandler Paul]

Hi! I've been busy at work fixing up the set of patches that carlos sent
and I've finally got some commits up. This is rebased from the original
branch that I linked to (carlos_cleanup) to work with the latest
upstream master. You can find it here:

	https://github.com/Lyude1337/libinput/tree/carlos_patches

Normalization is pretty much going with what I suggested before for the
time being, but this very well might be changed later on. I just needed
to have something working for the time being so I could finally submit
this.
Events for tablets have also been split into their own type of event.

Feel free to make any comments or suggestions!

Cheers,
	Lyude

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.
> 
> 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
> 
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20140530/7feeef50/attachment-0001.sig>