On Tue, 03 Jun 2014 00:06:40 -0700 Thiago Macieira <thi...@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.hutte...@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 _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel