Messages in this thread | | | Subject | RE: [RFC] Staging:IIO: New ABI | Date | Tue, 26 Jan 2010 10:25:25 +0000 | From | "Hennerich, Michael" <> |
| |
>From: Dmitry Torokhov [mailto:dmitry.torokhov@gmail.com] >On Tue, Jan 26, 2010 at 09:55:45AM +0000, Hennerich, Michael wrote: >> >> >> >From: Dmitry Torokhov [mailto:dmitry.torokhov@gmail.com] >> > >> >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.
Acceleration in X,Y,Z translates pretty well in what joysticks deliver.
> >> 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?
Well - it depends. Some applications for Accelerometers also include: Personal navigation devices Hard disk drive (HDD) protection Safety
I agree with you that for these three mentioned above - Input is the wrong place.
>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
| |