[ACPI] The damn LID (Toshiba Satellite P10-792)

[Jaco K. <ja...@kr...>]

Right, I've tired of this piece of crap.  I've been staring at the dsdt
for hours now, made a large number of mods, did some weird debugging and
I'm still stuck.

This is what I can figure out so far, if _OSI is disabled, and os_name is
set to "Microsoft Windows NT" you get events upon both opening and closin=
g
the lid.  Anything else and you only get events upon close.

I'm not sure as to the exact functioning of the hardware but it seems it
acts different for different versions of Windows as it's writing out a
single byte to memory (with a single bit set) (0x04 for NT, always one of
the lower-order 4-bits for non _OSI and one of the upper bits for _OSI, 0
in case where it can't find a match for anything - Linux).

Right, now there is an event handler in \_GPE, _L07 which gets called
every time the lid closes (as well as when the lid opens for MS Win NT).=20
For MS Win NT the function flips a bit called LPOL (Lid Polarity?) and fo=
r
everything else it calls a function PHSS which writes the passed value ot=
u
to memory after locking a Mutex and first, and sends a fixed value before
and after sending the argument - I suspect this merely makes the BIOS bee=
p
the pcspkr or something as I only get beeps on close when I'm not using
Win NT), and then inverts the LIDS bit.

Now the weird thing, I would have thought that the output of the LIDS bit
is purely dependand on the hardware (ie, some switch that is connected to
the LID that determines whether the value is 0 or 1).

Flipping the LPOL bit seems to allow me to get open events as well.

In neither case does the LIDS bit seem to function, it's _always_ 0 when
read from the LID._LID function and it seems to be always one in the
\_GPE._L07 handler.

Both the LPOL and LIDS bits is accessed via the same IndexField.  I still
wonder whether sleeping between sending the index value and reading the
data value might help?  My counter argument to this is that the LPOL bit
seems to always be valid.  This will have to be done in the executer
(kernel) though - or is this already done (I can't make head or tail of
the executer/ code).    The alignment of the LIDS and LPOL bits within
their individual bytes is identical though and access it ByteAcc.

Since the LPOL bit seems to reflect the correct state with regards to
open/close (albeit inverted) I reckon it's possible to hack the DSDT to
read the LPOL in _LID instead of LIDS, invert it and return that instead.=
=20
Whilst this would most probably work I don't think it's the right thing t=
o
do.

What other options are available?

Thanks for any and all help.

Jaco

PS:  My DSDT is available at
http://www.kroon.co.za/downloads/toshiba_p10-792/

--=20
There are 10 kinds of people in the world, those who understand binary,
and those who don't.



--=20
There are 10 kinds of people in the world, those who understand binary,
and those who don't.