-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,

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

That's exactly how you control backlight on both the sparcbook and 
(most) Apple *books - you send commands to some sort of microcontroller 
over a serial interface ( tctrl on the sparcbook, PMU/Cuda on Macs )

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

I was thinking about timeouts here, not anything complex. I'm not 
proposing to implement sleep or anything like that without powerd. The 
kernel should just signal 'extended idle' and related events without 
anyone having to tell it so.

>> Yeah, X 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.

I'd feel a lot more comfortable with this stuff in the kernel. But this 
would require that the kernel knows what kind of video mode X 
programmed which isn't quite feasible right now, mainly because we 
don't have specific kernel drivers for all video chipsets, at least not 
on x86 and macppc. On the sparcbook it would be almost trivial though - 
all we need is a bunch of ioctl()s to program video modes.

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

Look at the stuff in dev/sysmon/ - so far you can register certain 
event sources with the events themselves ending up in powerd or if 
there's no powerd running it will attempt to Do The Right Thing on its 
own ( like initiating a shutdown when the power button is pressed )
This would need to be extended. In tctrl ( arch/sparc/dev/tctrl.c ) I'm 
sending events about the lid switch, the power button and the AC 
adaptor ( connected or not ).

Which reminds me - just to check if shutdown on low battery works 
properly I pulled the sparcbook's plug yesterday. It started bitching 
about low batter almost immediately ( the battery is old but some 
friend refreshed the cells a while ago ) - and continued doing so for 
almost an hour. Then it powered off. Apparently it shut down cleanly 
since filesystems didn't need checking. I wonder what triggers the low 
power event, maybe the microcontroller expects more than 12v from the 
battery pack.

So, should we emulate ACPI on non-x86 to make life easier? I had a 
short look at dev/acpi/ and I do't think I could provide all the data 
an ACPI battery would. The microcontroller only gives me a voltage, 
some estimated charge level and I can control wether to charge the 
battery or not.

have fun
Michael
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iQEVAwUBRF9w6spnzkX8Yg2nAQJ2AAf/Yl7azaNy1khcM/f2BK3ZLQvC6vRiR2qN
AHv+VaAv9eY03HkLxi7lKhQLngLRnqNQW+t/MDmKaEyX6RU1T9CW1CbxDSQ9nITZ
TV86hI3jNlv3tT+SSzdReZmNFr03SdGLA/qHrHEBWe5dU44EYevcx2NvIL85sjXV
w+1gM/XTMWiQ5lj1B58pz/BvgWf3/KV5NIanUVlGr+vvjcWqAyUh9nJScTehM0i6
/1QldMid4f+qn+3klvujA454PO7PLayqjgpoSBY14q+GGXnrU7WYZAWF43Zu7rvL
poNVLv0LfxZ7hsl38oHQ9QwZjLPK8Oo0GqTYtD+TCPWtqhl+cZQHeQ==
=TiZo
-----END PGP SIGNATURE-----