Michael Schmitz wrote:

quoted

quoted

quoted

quoted

Why pmud? For backlight I kind of see how you'd get that notion. But
volume?

Why would pmud make sense for the backlight ? because changing the
backlight settings saves power ? ..Right.

Sort of.

quoted

With Ben's latest changes (the /proc/pmu/* for example), pmud should
only be a daemon waiting for events, ie:
- sleep event: execute a bunch of shell commands (the pwrctl script
should really be split into foo.d directories)

Yep. Plus any other power status change events. /proc/pmu has got nothing
to do with it, neither has /proc/apm.

I mean that we could strip the code of pmu by half, using /proc/pmu
instead of poking /dev/pmu directly (which is broken).
The OS is supposed to give applications an abstraction layer on top of
the hardware. pmud attacking the hardware directly is broken (and the
amount of code needed to do this in the kernel is minimum).

quoted

- backlight keypress event: change the backlight

Nope. Not power related. Not 'PMU'd.

Let's make "pmud" mean "PowerMac Uber Daemon" then...

quoted

- volume keypress event would be a bad idea to implement inside pmud
because that's the kind of thing you want visual feedback for, and there
are a lot of different sound implementations that this could be built on
top of. (aRts/alsa/oss)

Nope. See above.

Huh, are you agreeing with me there ?

quoted

- eject keypress event: eject the damn CD !

Neither. Again, see above. Write a general purpose all powerful event
daemon for this. Don't bloat pmud because of some unspecific desire for
feeping creaturitis. This is Linux (Unix), not MockOS.

I don't see the problem there... Bloat of pmud ? hmm, maybe a more
general-purpose daemon would be interesting, even for x86'ers.

quoted

Better yet for handling the volume would be to get all these keys
recognized by the Linux kernel (these keys don't produce any recognized

Nope, not longer an option (kernel bloat, even worse than app bloat).

Hahaha, this was a good one. If the kernel doesn't recognize the key
(ie. it doesn't generate a keycode), we can't make anything out of it.
We *have* to have these keys in the usb and adb keycodes translation tables.

Cheers

---
/Bastien Nocera
http://hadess.net


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/