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

[Jonas Ådahl]

On Tue, Jun 03, 2014 at 10:21:07AM +0300, Pekka Paalanen wrote:
> 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?

Note that this header is put there to avoid having to add macros
identical to the ones in linux/input.h depending on what linux header
version is installed. The macros in question is only needed by evdev.c
to sort out button and key events.

> 
> 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, ...?

Yes, all keyboard and button events in wl_pointer and wl_keyboard values
from linux/input.h. Its probably the easiest to just continue that trend
with the other input interfaces as well.

> 
> 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?

If we want the Wayland input protocol to be the same across platforms,
then other platforms need to use the same values as evdev currently
does. It would probably be possible to use OS specific numbers there,
but that will just result in more porting work in the toolkits and
clients. How does it look there right now, regarding key codes, button
codes etc?

> 
> 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?

libinput is more or less as portable as libwayland-* as it is now. The
API is ment to use the same button/key identifiers as Wayland (i.e.
evdev as it is now), so I think libinput can just follow what Wayland
decides to do regarding those numbers. It should not be that much work
to add backends for other OSes to libinput as there is already a split
between the frontend and backends. Implement a separate libinput doesn't
sound like the better way to me.

The other part that would need bo be ported is, as with libwayland-*, to
replace the usage of epoll.

Jonas

> 
> 
> Thanks,
> pq
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel