Hi!
> > 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
accelerometers...
> 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).
Pavel
> 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
> :-)
>
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[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]
