[PATCH libinput] Add our own version of linux/input.h

[Pekka Paalanen]

On Tue, 03 Jun 2014 00:06:40 -0700
Thiago Macieira <thiago at kde.org> wrote:

> Em ter 03 jun 2014, às 16:56:35, Peter Hutterer escreveu:
> > On Mon, Jun 02, 2014 at 10:01:20PM -0700, Thiago Macieira wrote:
> > > Em ter 03 jun 2014, às 08:08:15, Peter Hutterer escreveu:
> > > > Avoids having to #define any values we're trying to use.
> > > > 
> > > > Header file is from Linux 3.15-rc8.
> > > > 
> > > > Signed-off-by: Peter Hutterer <peter.hutterer at who-t.net>
> > > 
> > > Wouldn't this be time as well to start using a different include than
> > > <linux/input.h>?
> > 
> > does it matter much? #include <linux/input.h> makes it clear which header it
> > is, that we ship our own doesn't really change that.
> 
> I think we should start moving away from a linux/ header. If Wayland gets run 
> on other OS, this header would mean "it happens to be the same values, but 
> it's not really a Linux header".

Should you also not be installing this header? Aren't these values used
in the libinput public API towards the compositor?

More importantly, aren't we using these values in the Wayland protocol
already for wl_pointer buttons and wl_keyboard keycodes (which are
usually just fed into libxkbcommon, true), and in the future for any
other new device classes like gamepads, joysticks, tablets, ...?

My real question is, what should other OSs use as the codes in the
above cases? Is it ok to have the Wayland input protocol or libinput API
OS-specific?

The current situation is vague, and this patch probably is not intended
to fix that at all, but is there a plan? Or is it expected that other
OSs implement their own libinput or something?


Thanks,
pq