[PATCH libinput] Add our own version of linux/input.h
peter.hutterer at who-t.net
Tue Jun 3 02:32:06 PDT 2014
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
>>> 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
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.
More information about the wayland-devel