lkml.org 
[lkml]   [2006]   [Jul]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Generic interface for accelerometers (AMS, HDAPS, ...)
    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
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2006-07-04 18:26    [W:2.412 / U:0.060 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site