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

2014-06-03 Thread Peter Hutterer
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.

Cheers,
   Peter
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel


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

2014-06-03 Thread Thiago Macieira
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.
-- 
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

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel


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

2014-06-03 Thread Pekka Paalanen
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


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

2014-06-03 Thread 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 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?

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@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/wayland-devel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel


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

2014-06-03 Thread Peter Hutterer

On 3/06/2014 17:21 , Pekka Paalanen wrote:

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?


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

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel


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

2014-06-03 Thread Peter Hutterer

On 3/06/2014 17:06 , Thiago Macieira 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.


what's the technical benefit of that though?

Cheers,
  Peter
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel


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

2014-06-03 Thread Jasper St. Pierre
I think it should be #include linux/input.h at the very least.
a_header_file.h has always meant system library to me.


On Tue, Jun 3, 2014 at 5:34 AM, Peter Hutterer peter.hutte...@who-t.net
wrote:

 On 3/06/2014 17:06 , Thiago Macieira 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.


 what's the technical benefit of that though?

 Cheers,
   Peter

 ___
 wayland-devel mailing list
 wayland-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/wayland-devel




-- 
  Jasper
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel


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

2014-06-03 Thread Thiago Macieira
Em ter 03 jun 2014, às 08:54:38, Jasper St. Pierre escreveu:
 I think it should be #include linux/input.h at the very least.
 a_header_file.h has always meant system library to me.

That distinction is blurred when you have third-party libraries.

 is actually meant for headers in my project because it starts the search 
from $PWD, whereas  starts in the system dirs, if no -I flag is passed. If 
they are, things change.

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

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel


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

2014-06-03 Thread Thiago Macieira
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

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel


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

2014-06-03 Thread Jasper St. Pierre
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.


On Tue, Jun 3, 2014 at 11:17 AM, Thiago Macieira thi...@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

 ___
 wayland-devel mailing list
 wayland-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/wayland-devel




-- 
  Jasper
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel


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

2014-06-03 Thread Peter Hutterer
On Tue, Jun 03, 2014 at 08:54:38AM -0400, Jasper St. Pierre wrote:
 I think it should be #include linux/input.h at the very least.
 a_header_file.h has always meant system library to me.

amended locally, thanks.

Cheers,
   Peter

 On Tue, Jun 3, 2014 at 5:34 AM, Peter Hutterer peter.hutte...@who-t.net
 wrote:
 
  On 3/06/2014 17:06 , Thiago Macieira 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.
 
 
  what's the technical benefit of that though?
 
  Cheers,
Peter
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel


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

2014-06-03 Thread 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.
0xFF00 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 thi...@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
 
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel


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

2014-06-02 Thread Thiago Macieira
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?

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

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel