Message ID | 20150327001106.GA16588@jelly.bne.redhat.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
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 >
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> -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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.
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.
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(+)