Michael Lorenz wrote:
> Hello,
>
>
>
> >> wscons seems like the ideal place to handle this.
>
> Yeah, it's getting all the relevant input anyway.

Yes, please.

FWIW, I handle this in my *application* code, that gets wsmouse and
wskbd events.  I guess this is not unlike X in that regard.

>
> >> Low level hw drivers should be able to register callbacks for
> certain actions ("dim/standby/suspend display", etc).
>
> Agreed, so far pnozz and tctrl talk to each other in a not exactly
> generic way ( since tctrl controls the backlight but pnozz needs to
> support the ioctl for it ) Maybe something similar to powerhooks? Hmm,
> Cherry wanted to extend the powerhooks interface.

By the way, Radeon on some hardware (particularly Mac powerbook/ibook
and certain SPARC hardware) will have this same property -- i.e. they
will likely need to do something ugly possibly using some other driver -
likely i2c, but not necessarily -- to manage the backlight.)

On one system, the backlight is managed via an LPC chip that takes
commands over an embedded RS232 port.  NetBSD isn't likely to be ported 
to that system, but that system *is* likely to be used as a template for
new platforms to which a NetBSD port would be useful.

>
> >> Now, policy needs to be set in userland.
>
> Of course. But it shouldn't depend on something like X and it should
> probably work reasonably without userland intervention.

Hmmm.... mixed feelings here.  I like the powerd approach, where
scripts, etc. can be used.  But I think it is also useful for kernel
entities to be able to both register to receive events (e.g. flush data
to non-volatile storage, etc.), and to be able to inject or trigger events.

>
> >> Also, if you sleep, you want to notify powerd that you want to go
> to sleep so it can run its sleep scripts before powering off -- don't
> do this directly from the kernel.
>
> Of course. So we can power down / reconfigure / reconnect network
> interfaces and such.
>
> >> Also, x86 is interested in this for ACPI. I'd be willing to work
> with you on this.
>
> Yeah,  wants to know when we're going to sleep / wake up so it can do
> its voodoo with the graphics chip(s). I think something like that is
> in place already but probably linux-specific.

There's a bunch of Linux power management crapola in the video drivers. 
Sleep/wake is "especially" interesting, because some of these video
parts have unique initialization considerations.  When running Xwsfb on
non-PC hardware, we might need the underlying wsdisplay to do the
initialization.

>
> >>> So, before I'm wasting my time inventing the wheel the 5th time -
> do we have something like this somewhere in the kernel? Should it be
> integrated with powerd? What about powerd vs. apmd? Their scopes seem
> to overlap quite a bit.
> >> apmd is dead; the future is powerd.
>
> Ok, that's what my sparcbook is running.

Looking at powerd, it looks like the way to go.  But I cannot find any
really useful on kernel APIs.  The powerd manual page references ACPI
man pages.  (I guess there is the powerhook(9) man info...)

    -- Garrett
>
> -- 
> Garrett D'Amore, Principal Software Engineer
> Tadpole Computer / Computing Technologies Division,
> General Dynamics C4 Systems
> http://www.tadpolecomputer.com/
> Phone: 951 325-2134  Fax: 951 325-2191
>