[lm-sensors] Generic interface for accelerometers (AMS, HDAPS,

[vojtech@suse.cz (Vojtech Pavlik)]

On Wed, Jul 05, 2006 at 01:57:17AM +0200, Pavel Machek wrote:

> > Anyway, the input infrastructure is good to emulate a mouse/joystick, but we
> > probably want to support the following generic data channels:
> > 
> > 1. Absolute acceleration output stream (either in hardware units, or
> >    normalized to G or mG if at all possible) for X, Y, Z.  Does the input
> >    infrastructure work well for reporting absolute numbers in a reasonably
> >    constant rate?
> >    
> >    This is what HD head unload policy daemons want to know, and the stream
> >    usually needs to offer datapoints somewhere between 20Hz and 100Hz
> >    without excessive jitter to be useful for more advanced filtering (like
> >    masking-off periodic movement such as the one caused by train tracks).

Yes, this is what the input subsystem normally works with - 32-bit
absolute (and relative) numbers at rates around 100 Hz. It's how the
data from joysticks (and mice) look like.

> > 2. As easy-to-use as possible joystick and mouse emulation (for toys and 
> >    gaming), which probably means auto-calibrating ones when possible
> >    and thus making them unsuitable channels for (1) above.
> 
> Well, I'd just provide 1. Providing 2 seems like task for some
> userspace filtering library.

Assuming you use the ABS_X, ABS_Y, and ABS_Z for the acceleration (which
is not necessarily ideal), you'll get a joystick emulation automagically
through the input subsystem without any additional coding.

> > 3. Control of accelerometer parameters:
> >    3a. Report of accelerometer type (hdaps, ams, etc) and other metadata
> >        (name, location, what it is measuring (system accel, hd-bay 
> >        accel...))
> 
> Well, if your system is accelerating at different speed than hd-bay,
> then your machine is either _way_ too big, or you are in bad trouble.
> 
> Ask Dmitry or vojtech, I believe input can provide such metadata. (I
> left most of the quoted text so that vojtech can reply easily).

It currently doesn't. It reports the device ID as a couple of 16-bit
integers, and how the input subsystem sees it. There is currently no way
to get at device-specific data, although this could be reasonably easily
done through sysfs I believe.

> >    3b. Accelerometer polling frequency

Module parameter, changeable via sysfs?

> >    3c. Enable/disable joystick and mouse emulation control
> >    etc.
> > 
> > And, of course, userspace must be able to easily find the accelerometer
> > outputs and diferentiate them from other joystick/mouse interfaces.  This is
> > a task for udev, I suppose.

Yup.

> > It is also very helpful to be able to know when something is using any of
> > the accelerometer output channels, so as to shut it down (or stop talking to
> > it) when it is uneeded. 

This is done automatically by the input subsystem. When the last user
close()s any of the related devices, the driver gets notified that it
can stop the hardware.

> > I don't know about AMS, but talking to HDAPS when
> > you don't need to does waste enough system resources and power to actually
> > justify implementing this.

I'd doubt any of the accelerometer implementations would consume much
power or CPU.

> > If we cannot detect automatically when userspace is paying attention to the
> > accelerometer through the input layer, then that means we will need the
> > enable/disable functionality already provided by the device model through
> > sysfs.
> > 
> > > Only piece of puzzle missing is marking that input device as "this
> > > accelerometer actually watches the whole device".
> > 
> > Well, it is very important to be able to easily find all data and channels
> > pertaining for a given accelerometer, and the accelerometer metadata should
> > indeed give userspace an idea of WHAT it is measuring the acceleration of

-- 
Vojtech Pavlik
Director SuSE Labs