--2JFBq9zoW8cOFH7v
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, May 09, 2005 at 12:21:37PM +0200, Vincent wrote:
> Thanks Quentin for summarizing all this. I've been pretty busy=20
> elsewhere, so there is a while I havn't put my nose into acpi stuff.=20
> Yet, on my behalf, my basic need would be to access a userland variable=
=20
> capable of changing dynamically processor performance (C states and=20
> throttling).
>=20
> >Ultimately this calls for an interface design, because there
> >is much more than what the processor object provides.  Support for
> >_PSV in the thermal zone objects needs some kind of a bus in order
> >to control the processor, for example.
>=20
> Question : the ACPI tree is already written in hardware. What you=20
> suggest is, according to what I see, like rebuilding the same tree at=20
> another level. Is that really efficient?

Maybe the TZ <-> Processor example wasn't good enough.

I'll take the one of the output display switching feature on my laptop.
The DSDT has all the necessary methods, but they're useless actually.  I
don't really understand how what _DSS does is relevant to output
switching.  The actual functions that do that are linked to a special
object that is Asus's and certainly not standardised.

In the end I have to set output display through that ATK0100 device,
and nowhere else.  That's why I'd like a mostly standard-following
userland interface (in means of what it can control and how), but also
a way for the ATK0100 device driver to tell the (what I call) acpivga(4)
driver "it's ok, guy, I'm taking over the display switching operation".

Such a way of re-linking together the devices would allow us to actually
provide a unified userland interface.

--=20
Quentin Garnier - cube@cubidou.net - cube@NetBSD.org
"When I find the controls, I'll go where I like, I'll know where I want
to be, but maybe for now I'll stay right here on a silent sea."
KT Tunstall, Silent Sea, Eye to the Telescope, 2004.

--2JFBq9zoW8cOFH7v
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (NetBSD)

iQEVAwUBQn9xYdgoQloHrPnoAQLk/wgAvv6vynbgALq8yYsZAtkAUGHJuKiefwM/
PHtvXXpBdkZYBtuHYZKiUe/WBvibOZqAyj8xfslzT2eAqicSc8HmGTB0zq7NPjSY
dFRQGaskUUcqw70MsT5bOBk3E1vN7v+IAuzgxlQaBGWV0Ny1vMSpKV2+CQIVe1FO
r7w185fk6oxqLBv/wQebqDP90X37cTsKOpn0R58CHR4SdUDivpKGFaF3BK0hPwCb
x42Ho+ax71sdbP0a7uzMRHBuECKHvm692zzx619JY8yGv50H1dNDQyr9BbAm0Hlg
Sf6SxsiUqc0NI9FDm17CyM0ExZnwb7pGO/iyJ85tRRrTcxueGC/IBA==
=M2aw
-----END PGP SIGNATURE-----

--2JFBq9zoW8cOFH7v--