Re: [RFC] Staging:IIO: New ABI

[Dmitry Torokhov]

On Tue, Jan 26, 2010 at 09:55:45AM +0000, Hennerich, Michael wrote:
> 
> 
> >From: Dmitry Torokhov [mailto:dmitry.torokhov@xxxxxxxxx]
> >
> >On Fri, Jan 22, 2010 at 04:31:12PM -0800, Greg KH wrote:
> >> On Fri, Jan 22, 2010 at 04:14:15PM -0800, Dmitry Torokhov wrote:
> >> > On Fri, Jan 22, 2010 at 12:47:18PM -0800, Greg KH wrote:
> >> > > On Wed, Jan 20, 2010 at 04:53:21PM +0000, Jonathan Cameron wrote:
> >> > > > I am not aware of these. Could you direct me to the current api? Also note that these
> >> > > > aren't the actual alarms, merely a means of enabling the relevant event on the related
> >> > > > event character device.
> >> > >
> >> > > Hm, I thought we had an accelerator interface somewhere...
> >> > >
> >> >
> >> > Nope. And I am also interested in this since I am sittign on a bunch of
> >> > accelerometers, magnetometers, etc drivers that are trying to plug into
> >> > input sysbsystem and quite unsure what to do with them.
> >> >
> >> > It was OK whch HDAPS and friends when they were using input for
> >> > secondary, toyish purposes, but these new drivers trying to use input
> >> > devnts as primary API and I am unsure if it is the best solution.
> >> > Accelerometer might be used as an input device but not always an input
> >> > device.
> >>
> >> Yeah, I see it using a joystick interface, which might be acceptable for
> >> "toy" devices like you say.
> >>
> >> But for "real" ones, we should do something else.
> >>
> >> Maybe, for devices that are going to be used by x.org, like the "toy"
> >> ones, we stick with the current input interface, but for others, we use
> >> a "real" interface, probably through hwmon, so that users can get the
> >> real data out in a consistant manner.
> >>
> >
> >I'd rather have all of them use real interface and then have a bridge
> >to input module to enable toyish mode (unless the device in question
> >is really truly an input device).
> >
> >--
> >Dmitry
> 

> I really don't see that hwmon provides facilities like input/evdev
> does.  Queuing of events with time stamping and multiple reader
> support.

I understand that using evdev might be very convenient but I still
believe that input should be used for human interfaces, not for generic
data acquisition. The idea is that userpsace consumers should be able to
query device's capabilities and based on those capabilities be able to
classify and properly handle the device. Now it all breaks when we get
random hardware using EV_ABS/ABS_* for delivering some datastream that
has nothing to do with coordinates.

>  The adxl34x accelerometer driver for example is really
> intended to be a input device.  Send EV_KEY for x,y,z_TAP detections,
> send EV_KEY for 3D orientation sensing, and EV_ABS for acceleration.
> With very minor platform data customization you can use this device
> for game controls or GUI interaction.  A few examples include digital
> picture frames, ebook readers, etc.
> 

I see. However, can it be reasonably used for other purposes? If yes
than maybe input is not the best primary subsystem the driver should
belong to. Having said that I need to look at the driver again...

-- 
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/