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

[Peter Hutterer]

On 3/06/2014 17:21 , 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?

no, and yes. I'd rather not install a header that really belongs to some 
other project. IMO if a compositor on e.g. BSD wants to use this, they 
can include linux/input.h as well and decide how, when, etc to install it.

to give you a bad analogy: if we return M_PI we don't provide and 
install math.h ourselves either.

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

If we want to *look* OS-independent we could just do this:
    #define LIBINPUT_KEY_A KEY_A
and then export the LIBINPUT* constants. this is obviously just 
pretending to be non-OS-specific so we might as well cut out the middle 
man and say: buttons/keys use linux/input.h constants.

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

Cheers,
   Peter