Thread (1 message) 1 message, 1 author, 2015-09-12

Re: [PATCH 2/4] devicetree: bindings: Add header file with evdev type and abs/rel code defines

From: Dmitry Torokhov <hidden>
Date: 2015-09-12 18:04:18
Also in: linux-arm-kernel, linux-devicetree

Possibly related (same subject, not in this thread)

On Thu, Sep 10, 2015 at 3:48 PM, Rob Herring [off-list ref] wrote:
+Ian

On 09/10/2015 01:50 PM, Hans de Goede wrote:
quoted
Hi,

On 10-09-15 20:42, Dmitry Torokhov wrote:
quoted
On Thu, Sep 10, 2015 at 11:40 AM, Hans de Goede [off-list ref]
wrote:
quoted
Hi,


On 10-09-15 20:34, Dmitry Torokhov wrote:
quoted
On Thu, Sep 10, 2015 at 10:25 AM, Rob Herring [off-list ref] wrote:
quoted
On 09/09/2015 04:11 AM, Hans de Goede wrote:
quoted
This header provides evdev constants for linux,code, and
linux,input-*
properties.

Signed-off-by: Hans de Goede <redacted>
---
   include/dt-bindings/input/evdev.h | 76
+++++++++++++++++++++++++++++++++++++++

This looks fine, but please just add to input/input.h.
[...]
quoted
quoted
quoted
quoted
Actually I'd rather we removed include/dt-bindings/input/input.h and
instead used the header file from uapi. As it is now we already
duplicating definitions and the copy in dt-bindings is missing several
key codes. Until we split DT bindings form the kernel code I'd rather
have definitions in one place.
We do already have split binding tree. It is generated from the kernel
tree ATM.
But the data in the kernel is the "source of truth" for now since the
other tree is simply generated.
Adding Ian for any comments.
quoted
quoted
quoted
AFAIK we cannot do that as the uapi header also contains things like:

struct input_event {
         struct timeval time;
         __u16 type;
         __u16 code;
         __s32 value;
};

Which is not valid device tree syntax.

If you want this we need to split the uapi headers in one with only
defines and one with all the rest.
That would be fine by me. event-codes.h?
Since this will live in the generic include/linux namespace (for userspace)
maybe input-event-codes ?

Rob are you ok with including uapi headers from dts files if those uapi
headers are guaranteed to have only #define-s in them?
No. If you can do it as a symlink or some limited way, I'd be fine with
that. I don't want to see wholesale addition of uapi headers though.
Umm, not sure if I like symlink, it makes hard to see what includes
what. The individual DTSes will continue including
dt-bindings/input/input.h and only input.h will include uapi header
(so use of uapi is internal detail). Would that still be a problem?

Thanks.

-- 
Dmitry
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help