--g4MvFqI7wmANiPDo
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, May 04, 2005 at 12:31:05AM +0900, Takayoshi Kochi wrote:
> From: Vincent <10.50@free.fr>
> Subject: Re: HEADS UP: ACPI-CA 20050408 imported to -current
> Date: Mon, 02 May 2005 21:30:02 +0200
>=20
> > > I have just finished importing ACPI-CA 20050408 to -current.
> > > The last import was 20040211, so there are big changes.
> >=20
> > Great !
> >=20
> > Anything about a =AB processor =BB object, or is it still to be done ?
>=20
> 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)
object(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
or 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.

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?

--=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.

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

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

iQEVAwUBQnesP9goQloHrPnoAQIB1wf8DDIAGo37ADPaXzEJrMsFCs8QByNijmH2
FcCxhC7fTHRNXl5XLy7P+t84xkcRvRnyWHgnrhMkqaqkr4Hr72nKqq2jUKbXWWeG
5xGAzLigU60vM4Q5ePXT72MJHKRus3E/ne9IMMQRwIqRt0WeaE5QRhRzUPOKsS47
Y/3vTDlOF+Efi2f1P+Q95WbOKebck4Xm1v0ZNQYipGSSLjaPtMgQgnnHcV6VVECP
LzkCIXuz9Ohbzb6K4/qZi23FUjzSq1Wx39s8mpHuFeExIp/wzPv1Lv1A3Uf60AWZ
cflPqCygnIWlNBqVEBg5phlocsKmifD2E9hsbdb5nJILlFPcgyTntw==
=gHew
-----END PGP SIGNATURE-----

--g4MvFqI7wmANiPDo--