ABS_MAX incrementation?

ABS_MAX incrementation?

[Daniel Mack]

Hi,

I'm planning to write a driver for a device with a number of absolute
axis and 16 pressure-sensitive trigger pads. Alltogether, it will have
more absoulte axis informations than the API in include/input.h is able
to represent. More than that, the definitions I'm referring to won't
describe the actual information in a sane way. I'm uncertain whether
this list can be extended by something like the patch below. Or is this
a nonono as it breaks existing user space applications? Any other idea
of how to solve this?

Thanks,
Daniel


>From ad95178134ab4cf9dd1b32daf3fff14d3c7d1e17 Mon Sep 17 00:00:00 2001
From: Daniel Mack <daniel@caiaq.de>
Date: Mon, 19 Apr 2010 19:08:14 +0200
Subject: [PATCH] input: add definitions for 16 trigger pads

Signed-off-by: Daniel Mack <daniel@caiaq.de>
---
 include/linux/input.h |   19 ++++++++++++++++++-
 1 files changed, 18 insertions(+), 1 deletions(-)

diff --git a/include/linux/input.h b/include/linux/input.h
index 7ed2251..39efad4 100644
--- a/include/linux/input.h
+++ b/include/linux/input.h
@@ -706,7 +706,24 @@ struct input_absinfo {
 #define ABS_MT_TRACKING_ID	0x39	/* Unique ID of initiated contact */
 #define ABS_MT_PRESSURE		0x3a	/* Pressure on contact area */
 
-#define ABS_MAX			0x3f
+#define ABS_PAD1		0x40
+#define ABS_PAD2		0x41
+#define ABS_PAD3		0x42
+#define ABS_PAD4		0x43
+#define ABS_PAD5		0x44
+#define ABS_PAD6		0x45
+#define ABS_PAD7		0x46
+#define ABS_PAD8		0x47
+#define ABS_PAD9		0x48
+#define ABS_PAD10		0x49
+#define ABS_PAD11		0x4a
+#define ABS_PAD12		0x4b
+#define ABS_PAD13		0x4c
+#define ABS_PAD14		0x4d
+#define ABS_PAD15		0x4e
+#define ABS_PAD16		0x4f
+
+#define ABS_MAX			0x4f
 #define ABS_CNT			(ABS_MAX+1)
 
 /*
-- 
1.7.0.3

Re: ABS_MAX incrementation?

[Dmitry Torokhov]

Hi Daniel,

On Mon, Apr 19, 2010 at 07:14:12PM +0200, Daniel Mack wrote:
> Hi,
> 
> I'm planning to write a driver for a device with a number of absolute
> axis and 16 pressure-sensitive trigger pads. Alltogether, it will have
> more absoulte axis informations than the API in include/input.h is able
> to represent. More than that, the definitions I'm referring to won't
> describe the actual information in a sane way. I'm uncertain whether
> this list can be extended by something like the patch below. Or is this
> a nonono as it breaks existing user space applications? Any other idea
> of how to solve this?
>

Extending the number of axes should be possible (we have done that for
number of keys/buttons not that long ago) and yes, userspace breakages
are possible but are most likely userspace fault.

The fact that data is purely device specific is a bit disconcerning, but
I understand that not every device uses commonly defined events. It _is_
an input device though, right?

I wonder if ofr this kinde of "flex" pads we could move into 2-event
notification so as not to expand the number of "axes" forever - use
ABS_PAD to transmit pad number and ABS_MISC to transmit actual value.
Such scheme will not allow comminucate min and max values for dpads
though, so not very good...

Another issue is that ABS data is pretty large, it would be nice if we
moved from this data being always present ininput device structure to
having drivers allocate it when needed.

Thanks.

-- 
Dmitry

Re: ABS_MAX incrementation?

[Daniel Mack]

Hi Dmitry,

On Mon, Apr 19, 2010 at 10:49:25AM -0700, Dmitry Torokhov wrote:
> On Mon, Apr 19, 2010 at 07:14:12PM +0200, Daniel Mack wrote:
> > Hi,
> > 
> > I'm planning to write a driver for a device with a number of absolute
> > axis and 16 pressure-sensitive trigger pads. Alltogether, it will have
> > more absoulte axis informations than the API in include/input.h is able
> > to represent. More than that, the definitions I'm referring to won't
> > describe the actual information in a sane way. I'm uncertain whether
> > this list can be extended by something like the patch below. Or is this
> > a nonono as it breaks existing user space applications? Any other idea
> > of how to solve this?
> >
> 
> Extending the number of axes should be possible (we have done that for
> number of keys/buttons not that long ago) and yes, userspace breakages
> are possible but are most likely userspace fault.

In worst case, they'll drop the events due to sanity check constraints,
right?

> The fact that data is purely device specific is a bit disconcerning, but
> I understand that not every device uses commonly defined events. It _is_
> an input device though, right?

It is a mixed MIDI/input device, yes. As it will most likely be used
for music production, I could also consider using MIDI for transport.
However, other devices supported by this driver (sound/usb/caiaq) use
the input subsystem for passing values up to the userspace.

> I wonder if ofr this kinde of "flex" pads we could move into 2-event
> notification so as not to expand the number of "axes" forever - use
> ABS_PAD to transmit pad number and ABS_MISC to transmit actual value.
> Such scheme will not allow comminucate min and max values for dpads
> though, so not very good...

Events from these pads will also occur quite frequently as the
resoultion is 12 bits. There will be quite some noise which should be
filtered by the user space application. So I believe the 2-event
approach would add quite some overhead as it doubles the amount of
messages being passed.

As we're on it - I'm quite unhappy with the allocation of the buttons
in the snd-usb-caiaq driver. I merely abuse valid values from enums
that are defined in input.h and leave it to the userspace to map things
back to their original meaning. Is there any change to introduce a more
dynamic model which describes buttons by given strings rather than
enums? Such an interface could also well be be used for ABS entities,
and that would also solve the problem I currently have. Userspace should
then have a way to query an entity's name for these special cases.

> Another issue is that ABS data is pretty large, it would be nice if we
> moved from this data being always present ininput device structure to
> having drivers allocate it when needed.

Ah, the struct has ABS_MAX as length for a fix-sized array, I see. Hmm.
Then we shouldn't make that bigger for such reasons, I agree.

Thanks,
Daniel

Re: ABS_MAX incrementation?

[Dmitry Torokhov]

On Mon, Apr 19, 2010 at 08:06:06PM +0200, Daniel Mack wrote:
> Hi Dmitry,
> 
> On Mon, Apr 19, 2010 at 10:49:25AM -0700, Dmitry Torokhov wrote:
> > On Mon, Apr 19, 2010 at 07:14:12PM +0200, Daniel Mack wrote:
> > > Hi,
> > > 
> > > I'm planning to write a driver for a device with a number of absolute
> > > axis and 16 pressure-sensitive trigger pads. Alltogether, it will have
> > > more absoulte axis informations than the API in include/input.h is able
> > > to represent. More than that, the definitions I'm referring to won't
> > > describe the actual information in a sane way. I'm uncertain whether
> > > this list can be extended by something like the patch below. Or is this
> > > a nonono as it breaks existing user space applications? Any other idea
> > > of how to solve this?
> > >
> > 
> > Extending the number of axes should be possible (we have done that for
> > number of keys/buttons not that long ago) and yes, userspace breakages
> > are possible but are most likely userspace fault.
> 
> In worst case, they'll drop the events due to sanity check constraints,
> right?

Synaptics driver did crash (dies to stack smashing) so potential effects
are more sinister. Still, if we need to extend it we shoudl to it and
either update userspace or add workarounds in the kernel.

> 
> > The fact that data is purely device specific is a bit disconcerning, but
> > I understand that not every device uses commonly defined events. It _is_
> > an input device though, right?
> 
> It is a mixed MIDI/input device, yes. As it will most likely be used
> for music production, I could also consider using MIDI for transport.
> However, other devices supported by this driver (sound/usb/caiaq) use
> the input subsystem for passing values up to the userspace.


I see.

> 
> > I wonder if ofr this kinde of "flex" pads we could move into 2-event
> > notification so as not to expand the number of "axes" forever - use
> > ABS_PAD to transmit pad number and ABS_MISC to transmit actual value.
> > Such scheme will not allow comminucate min and max values for dpads
> > though, so not very good...
> 
> Events from these pads will also occur quite frequently as the
> resoultion is 12 bits. There will be quite some noise which should be
> filtered by the user space application. So I believe the 2-event
> approach would add quite some overhead as it doubles the amount of
> messages being passed.

Theoretically you could "defuzz" in driver limiting data rate still.

> 
> As we're on it - I'm quite unhappy with the allocation of the buttons
> in the snd-usb-caiaq driver. I merely abuse valid values from enums
> that are defined in input.h and leave it to the userspace to map things
> back to their original meaning. Is there any change to introduce a more
> dynamic model which describes buttons by given strings rather than
> enums? Such an interface could also well be be used for ABS entities,
> and that would also solve the problem I currently have. Userspace should
> then have a way to query an entity's name for these special cases.

Unfortunately input layer is not well-suited for device-specific data. I
understand that some devices are pretty domain-specific and do not fit
into standard model of event describing intended useage for everyone. I
am open to sugggestions/RFC-style patches.

> 
> > Another issue is that ABS data is pretty large, it would be nice if we
> > moved from this data being always present ininput device structure to
> > having drivers allocate it when needed.
> 
> Ah, the struct has ABS_MAX as length for a fix-sized array, I see. Hmm.
> Then we shouldn't make that bigger for such reasons, I agree.
>

Alocating data dynamically was on my todo list forever. Maybe someone
will beat me to it *wink, wink*

-- 
Dmitry

Re: ABS_MAX incrementation?

[Daniel Mack]

Hi Dmitry,

On Tue, Apr 20, 2010 at 11:29:29PM -0700, Dmitry Torokhov wrote:
> On Mon, Apr 19, 2010 at 08:06:06PM +0200, Daniel Mack wrote:

...

> > As we're on it - I'm quite unhappy with the allocation of the buttons
> > in the snd-usb-caiaq driver. I merely abuse valid values from enums
> > that are defined in input.h and leave it to the userspace to map things
> > back to their original meaning. Is there any change to introduce a more
> > dynamic model which describes buttons by given strings rather than
> > enums? Such an interface could also well be be used for ABS entities,
> > and that would also solve the problem I currently have. Userspace should
> > then have a way to query an entity's name for these special cases.
> 
> Unfortunately input layer is not well-suited for device-specific data. I
> understand that some devices are pretty domain-specific and do not fit
> into standard model of event describing intended useage for everyone. I
> am open to sugggestions/RFC-style patches.

Well, I can live with the fact that enum members are abused so that
their name doesn't have to do much with the actual meaning, even though
that's not optimal. However, in this specific case, the problem is
that I have more axis than available element types, so I'm stuck. But
instead of heacking my way around it using other transport methods down
to userspace, we might also clean up legacy-style limitations once for
good.

> > > Another issue is that ABS data is pretty large, it would be nice if we
> > > moved from this data being always present ininput device structure to
> > > having drivers allocate it when needed.
> > 
> > Ah, the struct has ABS_MAX as length for a fix-sized array, I see. Hmm.
> > Then we shouldn't make that bigger for such reasons, I agree.
> >
> 
> Alocating data dynamically was on my todo list forever. Maybe someone
> will beat me to it *wink, wink*

Hmm, maybe I could also help with that. Could you outline where this
should go? I guess a linked list is not very suitable as it doesn't
allow instant access of specific members. So we need a fixed-size bitmap
to indicate active members at least?

Would that also make sense for all other information than ABS?

Daniel

Re: ABS_MAX incrementation?

[Dmitry Torokhov]

On Sun, May 02, 2010 at 02:13:31PM +0200, Daniel Mack wrote:
> Hi Dmitry,
> 
> On Tue, Apr 20, 2010 at 11:29:29PM -0700, Dmitry Torokhov wrote:
> > On Mon, Apr 19, 2010 at 08:06:06PM +0200, Daniel Mack wrote:
> 
> ...
> 
> > > As we're on it - I'm quite unhappy with the allocation of the buttons
> > > in the snd-usb-caiaq driver. I merely abuse valid values from enums
> > > that are defined in input.h and leave it to the userspace to map things
> > > back to their original meaning. Is there any change to introduce a more
> > > dynamic model which describes buttons by given strings rather than
> > > enums? Such an interface could also well be be used for ABS entities,
> > > and that would also solve the problem I currently have. Userspace should
> > > then have a way to query an entity's name for these special cases.
> > 
> > Unfortunately input layer is not well-suited for device-specific data. I
> > understand that some devices are pretty domain-specific and do not fit
> > into standard model of event describing intended useage for everyone. I
> > am open to sugggestions/RFC-style patches.
> 
> Well, I can live with the fact that enum members are abused so that
> their name doesn't have to do much with the actual meaning, even though
> that's not optimal. However, in this specific case, the problem is
> that I have more axis than available element types, so I'm stuck. But
> instead of heacking my way around it using other transport methods down
> to userspace, we might also clean up legacy-style limitations once for
> good.
> 
> > > > Another issue is that ABS data is pretty large, it would be nice if we
> > > > moved from this data being always present ininput device structure to
> > > > having drivers allocate it when needed.
> > > 
> > > Ah, the struct has ABS_MAX as length for a fix-sized array, I see. Hmm.
> > > Then we shouldn't make that bigger for such reasons, I agree.
> > >
> > 
> > Alocating data dynamically was on my todo list forever. Maybe someone
> > will beat me to it *wink, wink*
> 
> Hmm, maybe I could also help with that. Could you outline where this
> should go? I guess a linked list is not very suitable as it doesn't
> allow instant access of specific members. So we need a fixed-size bitmap
> to indicate active members at least?

I was just thinking about having drivers taht emit absolute events
allocate abs data (value, min, max, resolution) separately from
allocating a device (or maybe have additional input_abs_device_alloc
helper). Someting very simple.

> 
> Would that also make sense for all other information than ABS?
> 

The rest are much smaller so I am not that worried, at least for now.

-- 
Dmitry

Re: ABS_MAX incrementation?

[Daniel Mack]

Hi Dmitry,

On Mon, May 03, 2010 at 11:58:32PM -0700, Dmitry Torokhov wrote:
> On Sun, May 02, 2010 at 02:13:31PM +0200, Daniel Mack wrote:
> > Hmm, maybe I could also help with that. Could you outline where this
> > should go? I guess a linked list is not very suitable as it doesn't
> > allow instant access of specific members. So we need a fixed-size bitmap
> > to indicate active members at least?
> 
> I was just thinking about having drivers taht emit absolute events
> allocate abs data (value, min, max, resolution) separately from
> allocating a device (or maybe have additional input_abs_device_alloc
> helper). Someting very simple.

So that would buy us less memory footprint by saving 4 integers for 1
pointer. However, we would still need to store an array of pointers
which has ABS_MAX entries.

I'm hessitating as I would like to see ABS_MAX being quite large.
I'm planning to write a driver with > 100 absolute axis soon.

Also, that approach wouldn't be able to be descriptive about what the
axis in fact represent, and especially for such a high number, that
would be more than just a nice-to-have :)

As I say, I'd be willing to help with this hack up a clean solution
which also teaches the user space interface new fancy features. I would
just need some idea what's a proper way to go.

Thanks,
Daniel