Subject: Re: HEADS UP: ACPI-CA 20050408 imported to -current
To: Takayoshi Kochi <kochi@NetBSD.org>
From: Quentin Garnier <email@example.com>
Date: 05/03/2005 18:52:15
Content-Type: text/plain; charset=iso-8859-1
On Wed, May 04, 2005 at 12:31:05AM +0900, Takayoshi Kochi wrote:
> From: Vincent <firstname.lastname@example.org>
> Subject: Re: HEADS UP: ACPI-CA 20050408 imported to -current
> Date: Mon, 02 May 2005 21:30:02 +0200
> > > I have just finished importing ACPI-CA 20050408 to -current.
> > > The last import was 20040211, so there are big changes.
> > Great !
> > Anything about a =AB processor =BB object, or is it still to be done ?
> Nothing yet.
> What do you want specifically for processor object driver?
I've experienced with a few things there. There are a few power-
management feature that you can access through the processor(s)
Supposedly it lists available C-states (which we'd better start
supporting to increase battery life on laptops), and also gives
access to various processor features, such as frequency scaling
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.
While experimenting with the display-switching capable devices,
I'm having various success with the quality of the implementation
of that piece of the ACPI spec on my laptop, and to make things
work better I would need some kind of a bus across all the ACPI
devices on which objects would register their capabilities so that
a different device could fire events on another. One example of
that is a driver for a "hotkey" device (such as the ATK0100 found
on Asus and other laptops) which receive a "display switch" event,
but has to know how to switch display on the system (and of course,
whether to actually do that according to the user's configuration).
I'd see that as the video device register the, say, CAN_DISPLAY_SWITCH
capability, and the hotkey device later firing the DISPLAY_SWITCH
event. The video device would be configured by the user through a
acpivgactl application, and so on.
It's almost the same for the thermal zone and the processor, except
the TZ has direct reference to the processor object (from _PSL), but
that would only change a, say, get_devices(CAN_DISPLAY_SWITCH) to a
get_device("\_PR.CPU1"), the rest of the framework would be the same.
Am I making sense?
Even a little?
Quentin Garnier - email@example.com - 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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (NetBSD)
-----END PGP SIGNATURE-----