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

[Peter Hutterer]

On Tue, Jun 03, 2014 at 11:23:07AM -0400, Jasper St. Pierre wrote:
> Just have people shoot an email saying "hey, we'd like to add a constant
> for this". Talking to each other is really all we need to do, no need to
> make it any more formal.

indeed. and there's a high chance that if another OS needs a new code,
the Linux kernel will need that code too.

There's always the option of having vendor-defined codes starting from e.g.
0xFF000000 but I'd really really like to avoid going there until there is no
other option.

Cheers,
   Peter

> On Tue, Jun 3, 2014 at 11:17 AM, Thiago Macieira <thiago at kde.org> wrote:
> 
> > Em ter 03 jun 2014, às 19:32:06, Peter Hutterer escreveu:
> > > > 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?
> > >
> > > No, other OS can use libinput, they just need to get evdev into the
> > > kernel  BSD is already working on this, there's probably options for
> > > having a shim between the kernel and userspace but at that point you're
> > > probably better off doing it in the kernel directly.
> >
> > Let me extend the question: what happens if one such OS decides to add
> > another
> > constant for something that Linux doesn't have yet. Who decides the value?
> >
> > Should we have H. Peter Anvin resurrect the LANANA so we can have a central
> > registry of codes? Should BSD kernel developers submit Linux kernel
> > patches?
> > Should it be first come, first serve?
> >
> > --
> > Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> >    Software Architect - Intel Open Source Technology Center
> >       PGP/GPG: 0x6EF45358; fingerprint:
> >       E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
> >