Re: [Hdaps-devel] [PATCH 2.6.23-rc2] hwmon: HP Mobile Data Protection System 3D ACPI driver (resend)

[Henrique de Moraes Holschuh <hmh@hmh.eng.br>]

On Wed, 29 Aug 2007, Shem Multinymous wrote:
> > > I agree that the sys interface is probably not the best choice, but the
> > > accelerometer data should provide not only position, but also generate
> > > an event when it detects
> > > that it's falling. From what I understood hdaps does not have that info,
> >
> > You can generate events on input devices, but I am not sure that's the best
> > way to go about it for this.  Things that block on read until an interrupt
> > happens might work better.
> 
> You can do the latter via another (4th) input device.

We have the events that can be sent over all devices, actually (we can use
button events for this).  But blocking on read might indeed require a
separate input device... or a file, or something like that.  And we
*definately* should implement something like proper select() and poll()
support for the position sysfs attribute.

HDAPS has also some other crap that needs to go over the input device (mouse
activity, keyboard activity flags).  ams and hpmdp have the "possible shock
imminent" events, etc.  The goal is to kill all need for userspace to keep
pestering the accelerometer driver with open/read/close on sysfs attributes
constantly.

> > I'd suggest an accelerometer sysfs interface, that we implement in hdaps
> > (in and out-of-tree), ams and hpmdp.  One input device for joystick
> > emulation (optional), one input device with accelerometer data in mg or ug,
> 
> Is any of the accelerometer drivers currently capable of computing the
> physical acceleration? Also, is there an issue of linear vs. angular
> acceleration?

HDAPS is, if we add the code to calculate it.  I suppose the others can,
too, if they get the datasheets for the acceleration sensors.  However, if
it proves too difficult to calculate these values, we will have to do away
with it, and instead find a way to export what data we know about the
accelerometers (orientation, type of mesaurement, scales of measurement,
etc).

As for linear vs angular, we will have to find a way to report either: it
will depend on the accelerometer sensor.  HDAPS uses only linear, on two
axes (bad! ams and hpmdp can do it for three axes).  I know of sensors for
three axis (also linear), but it is not difficult to imagine people using
angular acceleration sensors.  Maybe we could export the type of
acceleration per-axis or somesuch using sysfs?

> Before or after axis inversion/swapping? The tp_smapi hdaps driver

After inversion.  The goal is to have something applications can use
transparently, so all input devices have to use the same orientation in all
platforms. We will have to set those in some arbitrary way, and the drivers
will have to do axis inversion when needed.

While one doesn't need (or care) about axis orientation for sudden movement
detection (where the really interesting use is :-) ) (it is enough to know
the axis are orthogonal to each other), it does matter for toys.

-- 
  "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/