[RFC] libinputmapper: Input device configuration for graphic-servers

[Peter Hutterer]

On Wed, May 22, 2013 at 12:25:19AM -0400, Rick Yorgason wrote:
> On 2013-05-20 23:56, Peter Hutterer wrote:
> >what I am wondering is whether that difference matters to the outside
> >observer (i.e. the compositor). a gamepad and a joystick are both gaming
> >devices and with the exception of the odd need to control the pointer it
> >doesn't matter much which type they are.
> >
> >as for a game that would access the device - does it matter if the device is
> >labelled gamepad or joystick? if it's a gaming device you have to look at
> >the pysical properties anyway and decide which you use in what matter.
> 
> That would seem to unnecessarily complicate things. Let's say you
> want to do something simple, like display a list of the devices
> plugged into the computer, with a graphic showing the device type.
>
> If you don't have separate gamepad and joystick types, you would
> need to use some heuristic to decide whether to show the gamepad or
> joystick graphic. Really, the device driver should be able to tell
> us what kind of device it considers itself.

you don't need to differ between gamepad and joystick for that. to take the
wacom example (again), we want those devices to show themselves with the
right graphics for the tablet series* - they're still all tablets as far as
compositors and clients are concerned.

so the driver that handles the device can provide the graphics. 
you could subgroup categories, or have a tag hierarchy to categorise
appropriately.  in any case,this is conflating the concept of a library to
map drivers to devices with a library to tag devices in a client-visible
way.

Cheers,
   Peter

* the OS X driver does that, and libwacom + latest GNOME too

> Granted, we can't do that right now, because the kernel doesn't
> expose device types, which is something that should probably be
> resolved regardless of what happens with libinputmapper.
> 
> In the meantime, we can put the heuristic in libinputmapper, and if
> the kernel ever grows the ability to expose device types, we can
> remove the heuristic all together (or maybe demote it to a backup
> strategy).