Re: Generic interface for accelerometers (AMS, HDAPS, ...)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



> > Just use input infrastructure and be done with that? You can do
> > parking from userspace.
> The command to execute the freeze (and for how long) can certaily come from
> userspace, and the logic behind that command can be an userspace
> high-priority task, yes (that's how it is done in HDAPS anyway).  However,
> to implement the disk head unload you need kernel code (you need to freeze
> the IO queues for a while too, not just unload the heads).

Okay, yes, this part is needed. It is useful for more than

> 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).
> 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.

> 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).


>    3b. Accelerometer polling frequency
>    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.
> 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.  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.
> 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
> :-)

(cesky, pictures)
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at
Please read the FAQ at

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux