Subject: Re: HEADS UP: ACPI-CA 20050408 imported to -current
To: Vincent <>
From: Quentin Garnier <>
List: current-users
Date: 05/09/2005 16:19:13
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=
> capable of changing dynamically processor performance (C states and=20
> throttling).
> >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.
> 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.

Quentin Garnier - -

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

Version: GnuPG v1.2.6 (NetBSD)