[RFC v2 libinput 0/2] Buttonset interface - numbered axes

[David Herrmann]

Hi

On Wed, Mar 18, 2015 at 7:58 AM, Peter Hutterer
<peter.hutterer at who-t.net> wrote:
>
> This is a re-vamped version of the buttonset interface. Still WIP but I'd
> like to get some comments on the API.
>
> Changes to the last version:
> This version now uses numbered axes instead of typed axes. Previously the
> interface used a unique axis type to deal with axes (e.g.
> LIBINPUT_BUTTONSET_AXIS_RING_LEFT). This approach was ditched, instead a
> device has a number of axes, each with a type. A caller can check how many
> axes are there and the type for each axis. In the event interface, the axis
> number is used, not the type.
>
> A whole bunch of axes have been added too though the wacom pad interface
> doesn't expose them, only wheel and ring.
>
> Branch is available here:
> https://github.com/whot/libinput/tree/wip/buttonbox-interface
>
> It's still missing a couple of details, tests, checks, etc. but it should
> show the interface well enough.

Awesome! Really appreciated!

Few assorted comments:

1) You introduce an enum for axis-types, instead of using the ABS_*
and REL_* values. On purpose? What's the reason? You don't do this for
buttons. I can come up with several reasons, but a clear statement
would be nice:
 - you want to merge ABS_* and REL_* into a single namespace
 - you want to get rid of the ABS_X/Y/Z and ABS_HAT* misuse for
anything that doesn't have its own ABS_* type
 - ABS2_* still didn't land upstream, so there's no way to introduce
new ABS_* values, but we really need them (yeah, my bad, I know!)
 - the kernel ABS_* values just never made any sense

2) Mapping from ABS_*/REL_* to axis-types is static? That is, we do
this based on the devices we know, instead of a magic translation
table for all types. I really like this, as we can get rid of the
crappy mappings we used to have for gamepads and so on. I just wonder
why this isn't done for buttons. Yeah, the namespace is bigger for
buttons and it used to have less bad mappings, but they still exist.

3) What is an axis-source? I don't get it. What else should I use to
control an axis, but my finger? My tongue? :) Ok, seriously, the
description is a bit short. Is this meant to distinguish between
touch-based input and other input? So you get release-events for the
'finger'-based input?

4) Why hard-code 'relative' in the axis-name, instead of making it a
property? AXIS_X/Y/Z and ROTATION_X/Y/Z already are two examples that
can be absolute _and_ relative. Wouldn't it make sense to make
'relative' a boolean attribute of an axis on a device? I don't know
what RING and STRIP is, so cannot comment on that.
A lot of other axes have this implicit (accelerometer/gyro/compass are
always absolute, for instance), so not sure it's a good idea. Just
wanted to bring it up and see whether you have any input on it.

5) If a device has multiple axes of the same type, is the order
supposed to be ABI? Example: gamepads tend to have two analog-sticks.
How do applications reliably find the left and right stick?

6) *_get_*_transformed() is linear? Can you mention that in the
description? It's not clear just from the name 'transform' and a
min/max range.

7) libinput_event_buttonset_get_axis_delta_transformed()?
What is that thing doing? libinput_event_buttonset_get_axis_delta()
returns data for relative axes, but the *_transformed() version says
it always returns 0 for relative axes? There's a big FIXME, but the
function description doesn't make sense to me. Can you elaborate?

8) What is libinput_event_buttonset_get_seat_button_count() good for?
Not that I care much, but it made me curious :)

9) There's only libinput_device_buttonset_has_button(), but no way to
get a list of buttons enabled on that device. Do you expect
applications to iterate all 2^32 buttons or are applications not
supposed to retrieve the set of buttons on a device?

Last point: Will there be some generic type for libinput-devices so
applications can select them? For instance: "this is a
wacom-tablet-style-thing" or "this is a gamepad", .. etc. Or are
applications supposed to look exactly at the capabilities of a device
and say "Hey, this has two analog-sticks, a dpad, 4 action-buttons and
a bit more; lets use it as gamepad input"? I like the latter, but
wanna be sure what the plans are.

Again, much appreciated! If this lands upstream, it'd be definitely
worth a look to add gamepad/etc. support.

Thanks
David