[ltp] Re: tp_smapi 0.34 and hdaps

Henrique de Moraes Holschuh linux-thinkpad@linux-thinkpad.org
Mon, 21 Jan 2008 00:00:38 -0200


On Sun, 20 Jan 2008, Shem Multinymous wrote:
> I don't think we need to be overly conservative here; all evidence so
> far shows that the accelerometer-related EC functions are pretty
> resilient (hell, they've been taking the crap that vanilla hdaps
> throws at them). Since so far we've seen just two valid 4-byte

Heh.  Don't forget I managed to hardlock the EC a few times by banging it
much too fast a few thousand times, when I was trying to help you by testing
the new EC code in tp_smapi :-)

But that wasn't what I was talking about, really.  I am far more afraid of
talking *right* to the EC (which is something mainline HDAPS has no clue how
to do, but tp_smapi hdaps seems to be doing extremely well at), but asking
it for a function that changed semanthics after the firmware warned us it
was not the firmware we are used to talk to...

> responses to the EC check function, just accepting both seems
> reasonably safe and much easier for everyone.

Oh, I certainly agree that accepting *both* is probably safe enough. I
dislike a lot the idea of accepting *everything* in unknown models, only.

That said, I'd be best if someone did put HDAPS through *all* of its paces
in a T61, which means testing the enable/disable function, the
auto-increment mode, the running-average filter and its depth, the
oversampling, and everything else (instead of just looking at the position
output).  IMHO, until someone tests it throughoutly, we cannot be really
sure it is *completely* safe.

It would be nice to check if the T61 uses the same accelerometer chip as the
T43 and T60, too.  Not that it matters much since the firmware hides it from
hdaps, but it would help to explain the difference in the firmware response.

> > It is fine to add a module parameter to force detection of HDAPS
> 
> Actually, I prefer to get the bug reports so we can gather the new
> data and fix it for everyone (and it's easy enough to patch the
> sourcecode if one really needs to).

That's your call, and I certainly know what you mean.  That said, the
parameter *would* be quite helpful to distros that decide to ship kernels
with tp_smapi patched in.

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