On Tue, 04 Jul 2006, Pavel Machek wrote:
> 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).
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.
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...))
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
:-)
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
