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
> [email protected]
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
signature.asc
Description: This is a digitally signed message part
_______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
