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

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

 



Shem Multinymous wrote:
On 8/29/07, Henrique de Moraes Holschuh <[email protected]> wrote:
On Wed, 29 Aug 2007, Yan Burman wrote:

HDAPS with input device support is quite new.  hdapsd was patched to talk to
it, too.  I suppose we should port the input device support to the driver
in-tree just so that we get it in tree as well.  Sounds like an useful
reason to bother with in-tree hdaps.  Not that it will save much power with
the in-tree driver, but at least it will be widely available from there.

In case they'll be of help for such porting, the relevant hdaps
patches from my tp_smapi patch series are attached.


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.


What's wrong with the stuff I did in mdps? a misc character device that acts like /dev/rtc. Why does it have to be input device oriented?
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?


and an optional one with the raw accelerometer data.

Before or after axis inversion/swapping? The tp_smapi hdaps driver
(losslessly) inverts the raw data too, to avoid duplication of
model-specific orientation logic.


unless someone wants to implement their own free-fall algorithms instead of
using whatever is in the firmware).

The term "free-fall" is dangerously misleading, for the reasons
explained in the IBM APS whitepaper.

  Shem

I also looked at what you did in the patches as well as the modified hdapsd. I'm doing the raw input device right now in the mdps, but I have a suggestion. It seems to me that right now there are at least 3 drivers that provide the same functionality - hdaps, ams and mdps. Why not create the input device that exports raw accelerometer data with a name that is generic - something like accel/input or something along those lines. This way hdapsd could work with any driver that provides the functionality without being hdaps specific.

Yan
-
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]
  Powered by Linux