[PATCH] Documentation: input - define INPUT_PROP_ACCELEROMETER behavior

[PATCH] Documentation: input - define INPUT_PROP_ACCELEROMETER behavior

[Peter Hutterer]

Spell out what this property means to userspace. If the property is set, all
directional axes must be accelerometer axes, any other axes are left as-is.
This allows an accelerometer device to e.g. have an ABS_WHEEL.

It is not permitted to mix normal directional axes and accelerometer axes on
the same device node.

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
---
I think this is the most sensible definition of what to expect when this
property is set on a device.

 Documentation/input/event-codes.txt | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/Documentation/input/event-codes.txt b/Documentation/input/event-codes.txt
index 9d13600..1756b97 100644
--- a/Documentation/input/event-codes.txt
+++ b/Documentation/input/event-codes.txt
@@ -294,6 +294,12 @@ accordingly. This property does not affect kernel behavior.
 The kernel does not provide button emulation for such devices but treats
 them as any other INPUT_PROP_BUTTONPAD device.
 
+INPUT_PROP_ACCELEROMETER
+-------------------------
+Directional axes on this device (absolute and/or relative x, y, z) represent
+accelerometer data. All other axes retain their meaning. A device must not mix
+regular directional axes and accelerometer axes on the same event node.
+
 Guidelines:
 ==========
 The guidelines below ensure proper single-touch and multi-finger functionality.
-- 
2.3.3

Re: [PATCH] Documentation: input - define INPUT_PROP_ACCELEROMETER behavior

[Jiri Kosina]

On Fri, 27 Mar 2015, Peter Hutterer wrote:

> Spell out what this property means to userspace. If the property is set, all
> directional axes must be accelerometer axes, any other axes are left as-is.
> This allows an accelerometer device to e.g. have an ABS_WHEEL.
> 
> It is not permitted to mix normal directional axes and accelerometer axes on
> the same device node.
> 
> Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
> ---
> I think this is the most sensible definition of what to expect when this
> property is set on a device.

First, I am quilty here. I've let INPUT_PROP_ACCELEROMETER slip through my 
tree without Dmitry's Ack, which is what I normally require for everything 
touching input.h. Mea culpa maxima, I missed it, sorry for that.

This makes sense to me though. So

	Acked-by: Jiri Kosina <jkosina@suse.cz>

but let's see what Dmitry has to say. 

Good thing is that this went only into 4.0-rc1, so if the whole 
INPUT_PROP_ACCELEROMETER turns out to be absolute no-go for some reason, 
we can still revert it.

Thanks, and sorry again.

>  Documentation/input/event-codes.txt | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/Documentation/input/event-codes.txt b/Documentation/input/event-codes.txt
> index 9d13600..1756b97 100644
> --- a/Documentation/input/event-codes.txt
> +++ b/Documentation/input/event-codes.txt
> @@ -294,6 +294,12 @@ accordingly. This property does not affect kernel behavior.
>  The kernel does not provide button emulation for such devices but treats
>  them as any other INPUT_PROP_BUTTONPAD device.
>  
> +INPUT_PROP_ACCELEROMETER
> +-------------------------
> +Directional axes on this device (absolute and/or relative x, y, z) represent
> +accelerometer data. All other axes retain their meaning. A device must not mix
> +regular directional axes and accelerometer axes on the same event node.
> +
>  Guidelines:
>  ==========
>  The guidelines below ensure proper single-touch and multi-finger functionality.
> -- 
> 2.3.3
> 

-- 
Jiri Kosina
SUSE Labs

Re: [PATCH] Documentation: input - define INPUT_PROP_ACCELEROMETER behavior

[Dmitry Torokhov]

On Fri, Mar 27, 2015 at 01:17:20AM +0100, Jiri Kosina wrote:
> On Fri, 27 Mar 2015, Peter Hutterer wrote:
> 
> > Spell out what this property means to userspace. If the property is set, all
> > directional axes must be accelerometer axes, any other axes are left as-is.
> > This allows an accelerometer device to e.g. have an ABS_WHEEL.
> > 
> > It is not permitted to mix normal directional axes and accelerometer axes on
> > the same device node.
> > 
> > Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
> > ---
> > I think this is the most sensible definition of what to expect when this
> > property is set on a device.
> 
> First, I am quilty here. I've let INPUT_PROP_ACCELEROMETER slip through my 
> tree without Dmitry's Ack, which is what I normally require for everything 
> touching input.h. Mea culpa maxima, I missed it, sorry for that.
> 
> This makes sense to me though. So
> 
> 	Acked-by: Jiri Kosina <jkosina@suse.cz>
> 
> but let's see what Dmitry has to say. 
> 
> Good thing is that this went only into 4.0-rc1, so if the whole 
> INPUT_PROP_ACCELEROMETER turns out to be absolute no-go for some reason, 
> we can still revert it.

No, I think that's fine. In the past I was hesitant of defining device
types, but at least for accelerometers, given that we state that we will
not be mixing them with regular directional axes, that should be fine.

I will apply this.

Thanks.

-- 
Dmitry

Re: [PATCH] Documentation: input - define INPUT_PROP_ACCELEROMETER behavior

[Bastien Nocera]

On Fri, 2015-03-27 at 10:11 +1000, Peter Hutterer wrote:
> Spell out what this property means to userspace. If the property is 
> set, all
> directional axes must be accelerometer axes, any other axes are left 
> as-is.
> This allows an accelerometer device to e.g. have an ABS_WHEEL.
> 
> It is not permitted to mix normal directional axes and accelerometer 
> axes on
> the same device node.
> 
> Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

Looks good.

Reviewed-by: Bastien Nocera <hadess@hadess.net>