Re: 2.4 - buttons, temperature, ictc

Re: 2.4 - buttons, temperature, ictc

[Iain Sandoe]

On Tue, Jul 17, 2001, Joseph P. Garcia wrote:
> On Tue, 17 Jul 2001 16:40:24 +0200 (CEST)
> Michael Schmitz <schmitz@opal.biophys.uni-duesseldorf.de> wrote:
>> Why pmud? For backlight I kind of see how you'd get that notion. But
>> volume?
> ...
>> handle all this. That way, users could even customize the thing to get
>> particular functions mapped to keys :-)
>
> I agree.  At least at the moment, there are measures to have volume
> controls in the new input layer.  Else, why would there be macros in
> input.h for them.  Assuming that this is generally preferred direction, it
> would require a shell- or X-based handler.  I'm sure that if keycodes are
> set up properly, you could have Sawfish or Enlightenment capture the key
> stroke and use it like macos with the volume bar appear at the bottom (if
> you want that sort of thing).  In console, it would be different.  But
> taken as stated, this starts to put bloat wherever it goes.  Having a
> window manager call aumix isn't very linux like, but I'd argue that its the
> kind of result you would get in a nice integrated environment like kde or
> gnome would like to attain.  if the user doesn't realize its part of the
> wm, and the code is clean, it should be tolerable.

How does the action end up getting routed to the sound driver?

We have some limitations owing to the OSS API:

(a) you can't open /dev/dsp more than once *well, you shouldn't be able to -
and I think I've fixed that - at least in Ben's tree*

(b) linking /dev/mixerXX with a particular piece of h/w can be quite tricky
(it might have to be a user selection - which mixer is controlled by the
keys).

(c) the OSS implementation *might* soon be sitting on top of an ALSA driver
talking to a non-onboard sound card (e.g. a pcmcia card) [although this is
not likely in the immediate future on PPC ... it is quite likely soon on x86
laptops]

(d) AFAICT there is no OSS "increment/decrement" volume function/ioctl().
You'd have to read the vol and then re-write it with an increment.  OSS
specifically says "you can't rely on the return value from the write vol.
ioctl()".

----

I'd definitely favour a daemon that didn't imply dependence on a particular
shell/window manager/gui-toolkit  (although I don't really think you are
suggesting that) ... there are endless toolkit debates on linux-audio-dev.

I've been toying with the idea of a PMac-specific GUI mixer for a while -
the PMac hardware doesn't map well onto OSS.

- that is, we have several capabilities (and growing with tumbler etc.) that
cannot be reached from the normal OSS interface.

Perhaps (at least the sound part) it could be integrated with eSound & aRts
so that coverage would come as part of a standard install?

ciao,
Iain.

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

Re: 2.4 - buttons, temperature, ictc

[Joseph P. Garcia]

On Wed, 18 Jul 2001 12:11:42 +0100
"Iain Sandoe" <iain@sandoe.co.uk> wrote:
> How does the action end up getting routed to the sound driver?

In the current set up, it is very similar to how the pmac backlight is.  The dmasound_awacs[module] registers a volume controller using a function defined in arch/ppc/kernel that simply stores a function pointer.  That function is called indirectly in the button handler code in adbhid.c.  The volume controller function in dmasound_awacs is a mix of calls awacs_volume_setter and direct calls to awacs_write.  The increment and such are all in that function.  I used this route, as opposed to something more direct, so dmasound could still be a module.  I should point out that this implementation can't control sound volume until something has used the sound card.  not sure why..

so this mostly ignores ioctls and mixers altogether.  I said it wasn't pretty.

This behavior is all bypassed if the user desires keycodes instead, in which case, if it worked, the adbhid code would send a keycode event rather than call the volume controller.  So adbhid.c's button handling code is where our kernel->userspace event should go, whatever we settle on.  if i understand my code correctly, the NIL support is always enabled, even if you don't enable the volume config option.  so this could mean anything encased in an ifdef CONFIG_PMAC_VOLUME would be the interlocking fragile code that should/will not make the trip into a public kernel.  but i'd have double check to make sure..

> ----
>
> I'd definitely favour a daemon that didn't imply dependence on a particular
[...]
> so that coverage would come as part of a standard install?

I'm not familiar with what kind of apis already exist, but your suggestion to make something like esound sounds good.  Given that these daemons try to allow for such things that we can provide in hardware (iirc), like multiple opens of /dev/dsp.  So would this be like taking most of the kernel's sound interface (like mixer too?) and bringing it into a userspace daemon?  You mention ALSA a bit.  Would this be a better fit than OSS, or are we better making our own?  but then again, I always lean a bit too much toward the generic all-purpose APIs created by Mr./Ms. Someone Else whenever userspace is involved.

And so with this, how much would stay kernel side?  is this a new api'ed kernel driver, or a userspace driver/daemon using a semi-generic ioctl interface for ppc sound hardware that also listens to other devices for control?  Can this be achieved in a kernel thread?  or would that still be considered kernel-bloat?  not to sure on userspace scheduling reliability.

(i talk alot when im trying to help)

--
Joseph P. Garcia
http://www.execpc.com/~jpgarcia

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

Re: 2.4 - buttons, temperature, ictc

[Bastien Nocera]

Hi,

Iain Sandoe wrote:

> On Tue, Jul 17, 2001, Joseph P. Garcia wrote:
>
>>On Tue, 17 Jul 2001 16:40:24 +0200 (CEST)
>>Michael Schmitz <schmitz@opal.biophys.uni-duesseldorf.de> wrote:
>>
>>>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.

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)
- backlight keypress event: change the backlight
- 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)
- eject keypress event: eject the damn CD !

>>...
>>
>>>handle all this. That way, users could even customize the thing to get
>>>particular functions mapped to keys :-)
>>>
>>I agree.  At least at the moment, there are measures to have volume
>>controls in the new input layer.  Else, why would there be macros in
>>input.h for them.  Assuming that this is generally preferred direction, it
>>would require a shell- or X-based handler.  I'm sure that if keycodes are
>>set up properly, you could have Sawfish or Enlightenment capture the key
>>stroke and use it like macos with the volume bar appear at the bottom (if
>>you want that sort of thing).  In console, it would be different.  But
>>taken as stated, this starts to put bloat wherever it goes.  Having a
>>window manager call aumix isn't very linux like, but I'd argue that its the
>>kind of result you would get in a nice integrated environment like kde or
>>gnome would like to attain.  if the user doesn't realize its part of the
>>wm, and the code is clean, it should be tolerable.
>>


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
keycode on my iMac's Apple Pro kbd), and then by XFree86 so that anybody
can start adding shortcuts for their preferred window manager/desktop
for these keys (that do also exist on x86, btw)


> How does the action end up getting routed to the sound driver?
>
> We have some limitations owing to the OSS API:
>
> (a) you can't open /dev/dsp more than once *well, you shouldn't be able to -
> and I think I've fixed that - at least in Ben's tree*
>
> (b) linking /dev/mixerXX with a particular piece of h/w can be quite tricky
> (it might have to be a user selection - which mixer is controlled by the
> keys).
>
> (c) the OSS implementation *might* soon be sitting on top of an ALSA driver
> talking to a non-onboard sound card (e.g. a pcmcia card) [although this is
> not likely in the immediate future on PPC ... it is quite likely soon on x86
> laptops]


A pcmcia sound card ?! didn't know that existed. Maybe USB speakers
would be a better example (like on the Cube).


> (d) AFAICT there is no OSS "increment/decrement" volume function/ioctl().
> You'd have to read the vol and then re-write it with an increment.  OSS
> specifically says "you can't rely on the return value from the write vol.
> ioctl()".
>
> ----
>
> I'd definitely favour a daemon that didn't imply dependence on a particular
> shell/window manager/gui-toolkit  (although I don't really think you are
> suggesting that) ... there are endless toolkit debates on linux-audio-dev.
>
> I've been toying with the idea of a PMac-specific GUI mixer for a while -
> the PMac hardware doesn't map well onto OSS.
>
> - that is, we have several capabilities (and growing with tumbler etc.) that
> cannot be reached from the normal OSS interface.


Can you explain ? OSS is indeed not very good for our mixers, maybe your
ideas could be integrated into ALSA before it reaches 1.0 or gets
included in the kernel.


> Perhaps (at least the sound part) it could be integrated with eSound & aRts
> so that coverage would come as part of a standard install?


esound is _dead_. On PPC, it's a piece of junk, and Gnome 2.0 will use
aRts through a C interface.

Cheers

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


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

Re: 2.4 - buttons, temperature, ictc

[Joseph P. Garcia]

On Wed, 18 Jul 2001 13:52:59 +0100
Bastien Nocera <hadess@hadess.net> wrote:
> Why would pmud make sense for the backlight ? because changing the
> backlight settings saves power ? ..Right.

I suppose if we wanted a userspace interface to the backlight, would ioctls on the /dev/fb# be an adequate solution.  Since the display probably doesn't have any more direct path than through the video driver its connected to.  Newworld seem to have the backlight control there anyway.  I'm not sure where I stand on this one.  The question - are the brightness buttons considered an extention of the monitor, or owned by the keyboard.  If it's the former, it sounds like as it is is best (kernelspace).  If its the latter, the keys are just keys, and thus a userspace solution to connect the keys to the [ioctls] would be proper.

I lean toward kernelspace myself, ie. the buttons are owned by the screen.  Basically, I'd expect there to be two sets of brightness buttons had I two LCDs.  Eject keys feel the same way, so I'd think kernel level is more proper.  But am I talking pcmcia eject keys or cdrom eject keys...  ouch.  How does MacOS arbitrate the keyboard's eject key to one's cdrom or zip?  Is it just like command-E?  (I'm oldworld.)

The fact these hardware quirks are showing up more and more in new desktops (Mac and PC) means some standard methods might need to be established..  one thing I hoped I never would need is a 'pmac-kbd' daemon... but...

--
Joseph P. Garcia
http://www.execpc.com/~jpgarcia

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

Re: 2.4 - buttons, temperature, ictc

[Michael Schmitz]

> Bastien Nocera <hadess@hadess.net> wrote:
> > Why would pmud make sense for the backlight ? because changing the
> > backlight settings saves power ? ..Right.
>
> I suppose if we wanted a userspace interface to the backlight, would
> ioctls on the /dev/fb# be an adequate solution.  Since the display

We already have (fbset).

	Michael


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

Re: 2.4 - buttons, temperature, ictc

[Michael Schmitz]

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

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

> - backlight keypress event: change the backlight

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

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

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

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

	Michael


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

Re: 2.4 - buttons, temperature, ictc

[Bastien Nocera]

Michael Schmitz wrote:

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

>>- backlight keypress event: change the backlight
>>
>
>Nope. Not power related. Not 'PMU'd.
>
Let's make "pmud" mean "PowerMac Uber Daemon" then...

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

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

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

Re: 2.4 - buttons, temperature, ictc

[Michael Schmitz]

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

This depends - does /proc/pmu allow me to poll for 'new' data, or will it
always return with the same data immediately? I'd rather use /dev/pmu and
rely on getting one reply every second.

> >Nope. Not power related. Not 'PMU'd.
> >
> Let's make "pmud" mean "PowerMac Uber Daemon" then...

Sigh. That's hard to understand, isn't it? Let's do pmud one job
(monitoring the battery status, plus the remotely related lid switch) and
do that well. Let's not make it do anything a Powerbook user might want
due to the special hardware features. How do you translate 'eierlegende
Wollmilchsau' in English?

But this is only my preference. If you want a Powermac bloat daemon, write
and maintain it. If users want the added features they'll use it.

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

For a different reason. I don't give a damn about how you implement volume
control but I don't want to bother pmud with it. Not its job.

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

Doing many unrelated things badly is the problem I see. But the general
purpose event handler might even run on x86. Thanks for supporting my
side of this argument :-)

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

Sure, but handling of these keys goes in user space. So far it's in the
kernel as well, and if I understand Franz right that's going to change
(because now there's a nice generic interface, no special ADB hacks). The
new input code is a chance to implement things in a generic, portable way,
let's do it right. Otherwise the whole thing wouldn't be worth the hassle
(and hassle we had plenty, with breaking interfaces in an incompatible
way in the stable kernel series)

	Michael


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

Re: 2.4 - buttons, temperature, ictc

[Bastien Nocera]

Michael Schmitz wrote:

>>>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).
>>
>
> This depends - does /proc/pmu allow me to poll for 'new' data, or will it
> always return with the same data immediately? I'd rather use /dev/pmu and
> rely on getting one reply every second.


It's possible to add an event so that /proc/pmu is only polled when
needed. If you rely on pmud to give you new data every second, I think
you're dreaming (or it would need to be async). Using pmud's socket to
get battery status is just very very slow and dodgy.


>>>Nope. Not power related. Not 'PMU'd.
>>>
>>>
>>Let's make "pmud" mean "PowerMac Uber Daemon" then...
>>
>
> Sigh. That's hard to understand, isn't it? Let's do pmud one job
> (monitoring the battery status, plus the remotely related lid switch) and
> do that well. Let's not make it do anything a Powerbook user might want
> due to the special hardware features. How do you translate 'eierlegende
> Wollmilchsau' in English?


Right, I'm pretty sure you can put power management, and some key event
handling in less than a 100k of sources.
I really don't see where the bloat is...


> But this is only my preference. If you want a Powermac bloat daemon, write
> and maintain it. If users want the added features they'll use it.
>
>
>>>>- 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 ?
>>
>
> For a different reason. I don't give a damn about how you implement volume
> control but I don't want to bother pmud with it. Not its job.


Yep.



>>>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.
>>
>
> Doing many unrelated things badly is the problem I see. But the general
> purpose event handler might even run on x86. Thanks for supporting my
> side of this argument :-)


Pmud is just *that*, an event handler. Read Joseph's mail.
In the end this code wouldn't be pmud anymore, so we wouldn't have the
problem of you saying that it doesn't fit into the "power management
unit" daemon ;P


>>>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.
>>
>
> Sure, but handling of these keys goes in user space. So far it's in the
> kernel as well, and if I understand Franz right that's going to change
> (because now there's a nice generic interface, no special ADB hacks). The
> new input code is a chance to implement things in a generic, portable way,
> let's do it right. Otherwise the whole thing wouldn't be worth the hassle
> (and hassle we had plenty, with breaking interfaces in an incompatible
> way in the stable kernel series)


I agree with that.

Cheers

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


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

Re: 2.4 - buttons, temperature, ictc

[Michael Schmitz]

> > This depends - does /proc/pmu allow me to poll for 'new' data, or will it
> > always return with the same data immediately? I'd rather use /dev/pmu and
> > rely on getting one reply every second.
>
>
> It's possible to add an event so that /proc/pmu is only polled when

Fine. How would I do that, with the current /proc/pmu interface?

> needed. If you rely on pmud to give you new data every second, I think
> you're dreaming (or it would need to be async). Using pmud's socket to

No, I said /dev/pmu gives me new data once a second, right now. Read my
lips: /dev/pmu (kernel interface to the PMU), _not_ the socket pmud offers
for other apps to read from.

> Right, I'm pretty sure you can put power management, and some key event
> handling in less than a 100k of sources.
> I really don't see where the bloat is...

Show me the source.

And let me rephrase my concern: it's less about code _size_ but code
_complexity_. We need one process to monitor power status and take
appropriate action. That's enough of a task for a single process. We
appear to need another to monitor keyboard events, and take appropriate
action. Power status and key events have absolutely nothing in common.
That's why I hold that there should be separate daemons.

> > Doing many unrelated things badly is the problem I see. But the general
> > purpose event handler might even run on x86. Thanks for supporting my
> > side of this argument :-)
>
>
> Pmud is just *that*, an event handler. Read Joseph's mail.

I disagree. It's a specialized handler, and it isn't even using the
'event' mechanism employed by the future input code. Joe outlined the
design principles of the _input_ event code, nothing more, nothing less.

By extension of your argument, we'd have to put a web server and a mail
server into pmud as well. After all, network packets are just other
events coming in.

> In the end this code wouldn't be pmud anymore, so we wouldn't have the
> problem of you saying that it doesn't fit into the "power management
> unit" daemon ;P

Sure, write another daemon that handles all sorts of events in a central
place. Keep adding tasks to it. In the end, it'll look like a hybrid
between MacOS and Windows I guess.

You will have noticed that I rather prefer the design guideline of 'keep
it stupid simple' here.

Anyway, as this is linuxppc-dev and not debian-powerpc I'll stop arguing
here. The author of pmud is Stephan Leemburg, direct feature requests
there. I just happen to maintain the corresponding Debian package.

	Michael


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

powermac (other ppc?) events

[Joseph P. Garcia]

Ok.  here's what I gather:

- Buttons exist for brightness, volume, and now eject on the normal powermac keyboard.
- we also have other events we may consider to add, such as headphone insert, lid close(polled?), power key, and pmu-change (interrupt on nw)
- popular opinion is that to reduce kernel bloat, assocated reactions should be handled outside of kernel space.
- to get them out of kernel space, we should use events. (polling sucks)
- we *can* extend the normal keyboard to generate some if not all of these events
- we can also create a new event device using the very same interface (afaik)
   - this route is only appealing if we dont want/like the preconceptions of using keyboard events.
- those handled as an actual key should be handled by user programs.  prehandling the keyboard in userspace is messy (extending shells, window managers, etc.  redundant code)
- those handled as an event device of our creation will need a userspace daemon.

These are what I percieve as the facts.  Corrections welcome.

Once those are clarified, we should choose which events should be keys and which should be a powermac-daemon (i dont know if that's a PC name) handled event.  I hate to start a debate, but it should also be decided what in this daemon should be static, and what should be user-configurable.  It might be nice to keep unique concepts to different daemons, but maybe it would be better to have our new event device have a set of feature bits, and the daemon can be kept clean so the unused features only makes things a little bigger, but not slower.  Open to some debate, but which is more bloated, many interfaces with many daemons, or one daemon with no redundant code?  if its a fast/clean ship...

Consider the fact that there are probably other archetectures which could use this, and it is highly likely that this implementation will be expanded as hardware gets even weirder.

I figured we need a plan at this, since as programmers, interfaces tend not to be our strong suit IMHO.

I'm willing to help with coding, since I kinda started this thread.  The occational punching bag if need be.

--
Joseph P. Garcia
http://www.execpc.com/~jpgarcia

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

Re: powermac (other ppc?) events

[Michael Schmitz]

> - we also have other events we may consider to add, such as headphone insert, lid close(polled?), power key, and pmu-change (interrupt on nw)

These are not currently handled by the input driver, and not being inputs
(in the sense 'the user just pressed a key, moved a pointing device or
thought real hard about something and our telekinetic sensor picked it
up' per se I'd suggest to leave them out.

> - we *can* extend the normal keyboard to generate some if not all of these events

We need to, in order to have additional keys feed their events into the
input stream.

> - those handled as an actual key should be handled by user programs.  prehandling the keyboard in userspace is messy (extending shells, window managers, etc.  redundant code)
> - those handled as an event device of our creation will need a userspace daemon.

Pass that by me once again. If we merge any special key events with the
regular keys we'd need to read the whole key event stream and wait for a
particular one to show up, or can we specifically wait for a particular
key event?

If we decide on separate event devices, can we configure at run time
(ioctl) which event device a particular event is routed to?

> Once those are clarified, we should choose which events should be keys
> and which should be a powermac-daemon (i dont know if that's a PC

No, it's a PPC name :-) More Power to us.

Reiterating my previous position: we have a working solution for power
management, leave it out of such a powermac-daemon. In what way pmud picks
up power related 'events' is another issue (I'd opt for a dedicated event
device here). Currently these events aren't, there's a constant stream of
power status messages from /dev/pmu. Older Powerbooks don't even support
generation of events on power status changes, you'd have to run a state
machine in the PMU driver that keeps track of past state. At least that's
how I understand the current (hardware) situation.

For other events caused by the special keys on a Powerbook keyboard: it
doesn't matter much (to me) whether we pick a powerbook event daemon, or
have a sound event daemon plus a backlight control daemon plus some more
key gizmo daemons instead (if that's indeed possible, i.e. if all these
gizmo daemons can share a single event stream). They all live off keyboard
events some way or other anyway.

In order to keep the daemons simple they should be separate, maybe
(especially if you want code plugged in that would pop up a little on
screen display for brightness or sound). Start only those you feel you
need.

> name) handled event.  I hate to start a debate, but it should also be
> decided what in this daemon should be static, and what should be
> user-configurable.  It might be nice to keep unique concepts to

Brightness and volume I'd say hardwired, additional feature keys user
configurable.

> Consider the fact that there are probably other archetectures which
> could use this, and it is highly likely that this implementation will
> be expanded as hardware gets even weirder.

On these architectures, sound and brightness control keys would need to be
user configurable. Taken together with above, defaults for volume and
brightness on PowerPC but leaving these open for configuration.

	Michael


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

Re: powermac (other ppc?) events

[Joseph P. Garcia]

On Thu, 19 Jul 2001 13:20:28 +0200 (CEST)
Michael Schmitz <schmitz@mail.biophys.uni-duesseldorf.de> wrote:

> > - we *can* extend the normal keyboard to generate some if not all of these events
[snip]
> Pass that by me once again. If we merge any special key events with the
[snip]
> (ioctl) which event device a particular event is routed to?

This is where a decision appears.  Any action that is handled as a custom event, we have every freedom to sit and watch our new device with a daemon.  But we decide an event is a key, it becomes part of the keyboard.  The stream of keyboard events IMO should pass right from kernel space into whatever program the user is running.  ie, we do not have the same freedom to sit and watch it.  Am I correct in this?

This is less a problem if the keyboard's events can be filtered. (tell the kernel we are only waiting for a specific keys)  I can't remember if NIL supports that on a per-client basis.  If it can, then i guess its fine to doggy-watch the keyboard...

Looking at this now, it would seem my preconception of keyboard preconceptions are less of a problem if that one feature exists on the keyboard...

> Reiterating my previous position: we have a working solution for power
[snip]
> how I understand the current (hardware) situation.

kinda sorta a kpmud, with the userspace pmud do nothing but sleep; kinda as the kernel space's bottom half to pmu events.  how long before pmud's socket is phased out?  (i should update gkrellm-pmu... if anyone uses it over apm)

> For other events caused by the special keys on a Powerbook keyboard: it
[snip]
> screen display for brightness or sound). Start only those you feel you
> need.

I'm still not a fan of a nursery of little daemons...  But with properly blocking io, they're sleeping most of the time, so my objection is more about memory space and redundancy of code.

> Brightness and volume I'd say hardwired, additional feature keys user
> configurable.
[snip]
> On these architectures, sound and brightness control keys would need to be
> user configurable. Taken together with above, defaults for volume and
> brightness on PowerPC but leaving these open for configuration.

Ok.  sounds good.  Now, with the dual-out volume on most systems, the sound-out plug event would be nice to have here...  But that's in dmasound, isn't it.. ergh.  Since we dont want to force a linkage there, does this mean macos-like handling in kernelspace that can be disabled, thus appending a SPKR mixer control?  Would this work, Iain?

moreover, do we want to address a better sound interface now, or should I just get to actual coding?

--
Joseph P. Garcia
http://www.execpc.com/~jpgarcia

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

Re: powermac (other ppc?) events

[Michael Schmitz]

> > > - we *can* extend the normal keyboard to generate some if not all of these events
> [snip]
> > Pass that by me once again. If we merge any special key events with the
> [snip]
> > (ioctl) which event device a particular event is routed to?
>
> This is where a decision appears.  Any action that is handled as a
> custom event, we have every freedom to sit and watch our new device
> with a daemon.  But we decide an event is a key, it becomes part of
> the keyboard.  The stream of keyboard events IMO should pass right
> from kernel space into whatever program the user is running.  ie, we
> do not have the same freedom to sit and watch it.  Am I correct in
> this?

You tell me, please. I was wondering about this all the time. OTOH having
the whole keyboard input exposed to a zoo of daemons might be a Bad Thing
anyway.

> kinda sorta a kpmud, with the userspace pmud do nothing but sleep;
> kinda as the kernel space's bottom half to pmu events.  how long
> before pmud's socket is phased out?  (i should update gkrellm-pmu...
> if anyone uses it over apm)

pmud's socket is not related to the way pmud receives power status
information (event based or otherwise). And I don't think keeping it
around for the forseeable future is bad (2.2 kernels, anyone?).

There's not much in the way of a kpmud now, nor is there any need that I
can see. Blocking pmud in a special purpose syscall isn't any better or
worse than polling /dev/pmu.

> I'm still not a fan of a nursery of little daemons...  But with
> properly blocking io, they're sleeping most of the time, so my
> objection is more about memory space and redundancy of code.

The 'nursery of little daemons' was an extreme, much the same as the
'monolithic bloat daemon' is. With 2.2 kernels still in use for a while,
and the event interface for power or special button events still undefined
I'd rather implement the new features in a new (set of) daemon(s) and not
break pmud's backwards compatibility. The new event daemon(s) need not be
concerned about compatibility, making them cleaner to code.

> moreover, do we want to address a better sound interface now, or
> should I just get to actual coding?

We can address it now but the sound interface is unrelated to our event
processing, except for it eventually being called from some event daemon.
Let's treat them as separate issues. The sound interface need not
know any details of the event interface that's used to control it. Again,
hopefully cleaner code.

Does this make sense? Am I preaching to the choir? Without a CS degree I
fail to see the benefits of directly intermingling the various parts
involved here ...

	Michael

(trimming the CC list as all parties concerned are subscribed anyway)


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

Re: powermac (other ppc?) events

[Joseph P. Garcia]

> You tell me, please. I was wondering about this all the time. OTOH having
> the whole keyboard input exposed to a zoo of daemons might be a Bad Thing
> anyway.

If the keyboard can block our daemon until we get a key we care about, it should be ok.  The daemon would be a potential target for a trojan, but so are most daemons.  I think were just talking volume controls for keys anyway, so only one at this point.  And as keys, it would also fall through to the user so DEs like gnome could pop up a volume bar.  If we want backlight too, we'll need to add two new keys to the barrage.  If anyone has other opinions to a limited listen in on the keyboard, speak up.  If we shouldn't dare, the other approach is to ignore keys and use events, or let the user handle the volume keys him/herself.

> pmud's socket is not related to the way pmud receives power status
[snip]
> concerned about compatibility, making them cleaner to code.

Point taken.  I apologize.

So its best to consider this a 2.4 thing, and not break 2.2 in the process.  Need to get started before can really evaluate how redundant or bloated either approach is.  Backport consideration pending, but most newworlders may want to use 2.4 anyway.  a kpmud kinda sounds extreme at this point anyway.

Don't worry about degrees.  I'm still an undergrad.  Discussion is good, and if anyone objected to anything, they'd speak up.  Else linux wouldn't work as well.  As is, volume keys seem to rank low in the priority queue.  something to get practice on.

For now, when I find time, I'll check on the watchability of the keyboard, unless someone else can fill us in on NIL's keyboard, and then dive in.

Any particular reason that the comma key is delete in X using linux keys?  or am I dumb?

--
Joseph P. Garcia
http://www.execpc.com/~jpgarcia

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

Re: 2.4 - buttons, temperature, ictc

[Bastien Nocera]

Hi,

I reckoned that some people would like to see this. I didn't look into
this much yet, but would like to hear if somebody plans to work on it
(and if not, I like to take a look at it this week-end).

This is an edit I did for myself of a conversation I had on IRC with
Franz Sirlz... I'm the one asking the stupid questions ;)
Oh, and you have to use the linux_keycodes, not the adb conversion layer

<hadess> franzo: hmm, any code on using the new input layer, or anything ?
<franzo> you mean the event devices? just look into the  sample codes in
the linuxconsole-dev cvs on sourceforge
        http://linuxconsole.sourceforge.net/
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/linuxconsole/ruby/

<hadess> franzo: what is the output of evtest supposed to be when tested
on a keyboard ?
<franzo> Event: time 994192244.334929, type 1 (Key), code 28 (Enter),
value 0
<franzo>  Event: time 994192246.286645, type 1 (Key), code 57 (Space),
value 1

<franzo> hadess, so  no key works with evtest?
<franzo> hadess, iif the keys don't show up, they are probably missing
in the  USB  table in the kernel
<hadess> franzo: the "volume" and eject keys don't show up in any of the
kbd event devices
<hadess> franzo: how could i add these keys then ?
<franzo> hadess, add more known keys to static unsigned char
hid_keyboard[256] in usb/hid.c, that iis the  USBB-to-linux keycode mapping
<hadess> franzo: hehe, how do i get the usb keycodes ?
* hadess annoys franzo
<franzo> hadess, any kernel messages in /var/log/messages?
<hadess> franzo: not if i load the evdev
<hadess> franzo: it showed some unknow keycodes before, yes

Cheers

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


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

Re: 2.4 - buttons, temperature, ictc

[Iain Sandoe]

On   Wed, Jul 18, 2001,  Bastien Nocera wrote:
> Iain Sandoe wrote:
>> On Tue, Jul 17, 2001, Joseph P. Garcia wrote:
[snip]
>>>I agree.  At least at the moment, there are measures to have volume
>>>controls in the new input layer.  Else, why would there be macros in
>>>input.h for them.  [...]
>>>wm, and the code is clean, it should be tolerable.
>
> 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
> keycode on my iMac's Apple Pro kbd), and then by XFree86 so that anybody
> can start adding shortcuts for their preferred window manager/desktop
> for these keys (that do also exist on x86, btw)

I'd guess that Franz has the ideas of how this will work ... this side is
out of my parish ...

>> How does the action end up getting routed to the sound driver?
>>[...]
>> (c) the OSS implementation *might* soon be sitting on top of an ALSA driver
>> talking to a non-onboard sound card (e.g. a pcmcia card) [although this is
>> not likely in the immediate future on PPC ... it is quite likely soon on x86
>> laptops]
>
> A pcmcia sound card ?! didn't know that existed.

Yep. there are some "on the stocks" - pro-audio stuff really tho' rather
than SBLive-type things (although those may exist too).

> Maybe USB speakers would be a better example (like on the Cube).

yeah. USB audio integration is a headache right now ...

>>[...]
>> I've been toying with the idea of a PMac-specific GUI mixer for a while -
>> the PMac hardware doesn't map well onto OSS.
>>
>> - that is, we have several capabilities (and growing with tumbler etc.) that
>> cannot be reached from the normal OSS interface.
> Can you explain ? OSS is indeed not very good for our mixers, maybe your
> ideas could be integrated into ALSA before it reaches 1.0 or gets
> included in the kernel.

I don't think there's any need to worry about this in ASLA - it already has
the ethic of describing the underlying hardware - no more no less.

The problem is with OSS - where the API embeds an idea of what the hardware
should look like - and that idea is *way* different from how PMac built-in
sound is configured.

I planned on using the OSS "special purpose uncommitted" ioctl() values to
access the PMac-specific stuff and (perhaps) making a GUI mixer that
followed the Apple-type sound manager interface (i.e. reflecting
mutually-exclusive inputs etc. etc.).

This would make dmasound continue to work with the "standard" mixers -
whilst allowing people who wanted a more closely matched interface to use
that.

>> Perhaps (at least the sound part) it could be integrated with eSound & aRts
>> so that coverage would come as part of a standard install?
> esound is _dead_. On PPC, it's a piece of junk, and Gnome 2.0 will use
> aRts through a C interface.

OK ... I don't (under any circumstances) want to start a desktop/toolkit war
- that was part of my point in making the suggestion.

ciao,
iain.

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

Re: 2.4 - buttons, temperature, ictc

[Iain Sandoe]

On  Wed, Jul 18, 2001, Joseph P. Garcia wrote:
> On Wed, 18 Jul 2001 12:11:42 +0100
> "Iain Sandoe" <iain@sandoe.co.uk> wrote:
>> How does the action end up getting routed to the sound driver?
>
> In the current set up, [...]
> code that should/will not make the trip into a public kernel.  but i'd have
> double check to make sure..

well, I understood that from the original patch (and the objection I had was
just as you say)... I don't fancy trying to maintain that cross-linkage in
dmasound.

>> I'd definitely favour a daemon that didn't imply dependence on a particular
> [...]
>> so that coverage would come as part of a standard install?
>
> I'm not familiar with what kind of apis already exist, but your suggestion
> to make something like esound sounds good.

Apart from Bastien's comment in another follow-up..

> Given that these daemons try to
> allow for such things that we can provide in hardware (iirc), like multiple
> opens of /dev/dsp.  So would this be like taking most of the kernel's sound
> interface (like mixer too?) and bringing it into a userspace daemon?

as I understand it, yes... although I tend to concentrate on the raw driver
and haven't done much with esound/arts...

>  You mention ALSA a bit.
> Would this be a better fit than OSS, or are we better making our own?

I doubt (seriously) that another audio API would stand *any* chance of
making it into official linux ... it's still debatable whether ALSA will...

> but then again, I always lean a bit too much toward the
> generic all-purpose APIs created by Mr./Ms. Someone Else whenever userspace
> is involved.

ALSA is *much* cleaner - in principle - all the bloat is taken out of the
kernel drivers into user-land.   However, it's much more complex to set up
at the moment - IMHO probably hasn't really reached 'end user' status yet.

There are starter PPC drivers - based on dmasound.  However, much is still
to be done and ASLA hasn't reached 1.0 yet.  (This is why I'm still working
on adding other Apple chip-sets into dmasound).

> And so with this, how much would stay kernel side?  is this a new api'ed
> kernel driver, or a userspace driver/daemon using a semi-generic ioctl
> interface for ppc sound hardware that also listens to other devices for
> control?  Can this be achieved in a kernel thread?  or would that still be
> considered kernel-bloat?  not to sure on userspace scheduling reliability.

Well pre-ALSA (which is where we are at) ... the role of user-space
abstraction of the OSS devices is handled by aRts et. al.  So I guess taking
a look at how you might feed stuff to that is a start.

Otherwise, you could take the Apple HIG ethic of letting the user select
things... it works quite well (if you don't have a religious problem with
how they do things ;-)))

> (i talk alot when im trying to help)

s'ok - better to get a solution that will be acceptable from the start.
ciao,
Iain.

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

Re: 2.4 - buttons, temperature, ictc

[Iain Sandoe]

not sure how the volume controller can work in the general case.

I think this needs to be a user-space action (somehow) through the standard
OSS calls - because there are now quite a few PMac sound implementations
(although not all working fully yet)...

doing it this way is going to horribly link the adb and dmasound drivers
together...

ciao,
Iain

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

2.4 - buttons, temperature, ictc

[Joseph P. Garcia]

[-- Attachment #1: Type: text/plain, Size: 1172 bytes --]

mostly a rehash of patches from the past, and mostly not mine originally, attached is a patch.gz against the latest BenH 2.4 kernel.  It adds support for:
- repeating brightness buttons
- volume buttons (using kernel space volume control interface)  supported sound cards only (screamer, burgundy?)
- temperature support for my wallstreet 750CX, which doesn't use TAU. (not sure what CPUs support this coding.  no checks yet)
- ICTC proc support  (I still have this in my kernel.  might use it one day)
- small ATY resource tweak in pmac_pci.c (I like it at 0x830--.  not sure if 0x800-- is best or not.  ignore if you like.)

I'm willing to help see some of these get into a public tree.  BenH showed interest in the repeating and volume buttons, but with the noted exception of providing user space an interface to use them.  This coding has a broken new input layer volume key support, which if completed, and supported by a daemon, could lighten the code bulk extensively. (links between adbhid - pmacfeatures - dmasound[module] aren't pretty)

figured now was a good time to remind people these things still exist.

--
Joseph P. Garcia
http://www.execpc.com/~jpgarcia

[-- Attachment #2: voltemic.patch.gz --]
[-- Type: application/octet-stream, Size: 7085 bytes --]

Re: 2.4 - buttons, temperature, ictc

[Geert Uytterhoeven]

On Tue, 17 Jul 2001, Joseph P. Garcia wrote:
> - small ATY resource tweak in pmac_pci.c (I like it at 0x830--.  not sure if 0x800-- is best or not.  ignore if you like.)

Why is it necessary to hardcode this address? It may clash with another device.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


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

Re: 2.4 - buttons, temperature, ictc

[Joseph P. Garcia]

On Tue, 17 Jul 2001 09:18:53 +0200 (CEST)
Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> On Tue, 17 Jul 2001, Joseph P. Garcia wrote:
> > - small ATY resource tweak in pmac_pci.c (I like it at 0x830--.  not sure if 0x800-- is best or not.  ignore if you like.)
>
> Why is it necessary to hardcode this address? It may clash with another device.

Truth told, it isn't necessary anymore.  All this does is put the video control memory on wallstreets (it checks) at 0x830-- rather than 0x800--, which is where the current kernel puts it iirc.  A leftover from the days of the OF-caused ATY memory overlap.  Now, this mostly just makes /proc/iomem look cleaner.  nothing more.

That segment (the whole pmac_pci.c section of the patch) does only that, and can be ignored.  Don't know why i posted that part to tell the truth.

--
Joseph P. Garcia
http://www.execpc.com/~jpgarcia

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

Re: 2.4 - buttons, temperature, ictc

[Franz Sirl]

At 07:45 17.07.2001, Joseph P. Garcia wrote:
>mostly a rehash of patches from the past, and mostly not mine originally,
>attached is a patch.gz against the latest BenH 2.4 kernel.  It adds
>support for:
>- repeating brightness buttons
>- volume buttons (using kernel space volume control interface)  supported
>sound cards only (screamer, burgundy?)
>- temperature support for my wallstreet 750CX, which doesn't use TAU. (not
>sure what CPUs support this coding.  no checks yet)
>- ICTC proc support  (I still have this in my kernel.  might use it one day)
>- small ATY resource tweak in pmac_pci.c (I like it at 0x830--.  not sure
>if 0x800-- is best or not.  ignore if you like.)
>
>I'm willing to help see some of these get into a public tree.  BenH showed
>interest in the repeating and volume buttons, but with the noted exception
>of providing user space an interface to use them.  This coding has a
>broken new input layer volume key support, which if completed, and
>supported by a daemon, could lighten the code bulk extensively. (links
>between adbhid - pmacfeatures - dmasound[module] aren't pretty)
>
>figured now was a good time to remind people these things still exist.

I object to putting anything you marked with CONFIG_PMAC_VOLUME into the
kernel, it's worse enough we have CONFIG_PMAC_BACKLIGHT in there. I'll
merge your "input_report_key" into my 2.5 adbhid.c source though, thx.

With 2.5 even CONFIG_PMAC_BACKLIGHT in adbhid.c will go away and you _have_
to use the event devices then, so you better start using them _now_. Taking
kernel bloating shortcuts is not the way to go IMHO.

Franz.


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

Re: 2.4 - buttons, temperature, ictc

[Benjamin Herrenschmidt]

>I object to putting anything you marked with CONFIG_PMAC_VOLUME into the
>kernel, it's worse enough we have CONFIG_PMAC_BACKLIGHT in there. I'll
>merge your "input_report_key" into my 2.5 adbhid.c source though, thx.
>
>With 2.5 even CONFIG_PMAC_BACKLIGHT in adbhid.c will go away and you _have_
>to use the event devices then, so you better start using them _now_. Taking
>kernel bloating shortcuts is not the way to go IMHO.

Right, all this belongs to userland. I might include part of this
patch in 2.4 so we have the feature working now, but for 2.5, I'd
rather use the event devices for both backlight and volume, and
have pmud handle them.

Ben.


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

Re: 2.4 - buttons, temperature, ictc

[Michael Schmitz]

> >With 2.5 even CONFIG_PMAC_BACKLIGHT in adbhid.c will go away and you _have_
> >to use the event devices then, so you better start using them _now_. Taking
> >kernel bloating shortcuts is not the way to go IMHO.
>
> Right, all this belongs to userland. I might include part of this
> patch in 2.4 so we have the feature working now, but for 2.5, I'd
> rather use the event devices for both backlight and volume, and
> have pmud handle them.

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

I admit to zero knowledge about the event device stuff but if it's
anything like register_event(fd, handler, event_code) or select instead of
having a hander registered I'd rather have some sort of event daemon
handle all this. That way, users could even customize the thing to get
particular functions mapped to keys :-)

	Michael


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

Re: 2.4 - buttons, temperature, ictc

[Joseph P. Garcia]

On Tue, 17 Jul 2001 16:40:24 +0200 (CEST)
Michael Schmitz <schmitz@opal.biophys.uni-duesseldorf.de> wrote:
> Why pmud? For backlight I kind of see how you'd get that notion. But
> volume?
...
> handle all this. That way, users could even customize the thing to get
> particular functions mapped to keys :-)

I agree.  At least at the moment, there are measures to have volume controls in the new input layer.  Else, why would there be macros in input.h for them.  Assuming that this is generally preferred direction, it would require a shell- or X-based handler.  I'm sure that if keycodes are set up properly, you could have Sawfish or Enlightenment capture the key stroke and use it like macos with the volume bar appear at the bottom (if you want that sort of thing).  In console, it would be different.  But taken as stated, this starts to put bloat wherever it goes.  Having a window manager call aumix isn't very linux like, but I'd argue that its the kind of result you would get in a nice integrated environment like kde or gnome would like to attain.  if the user doesn't realize its part of the wm, and the code is clean, it should be tolerable.

So the question is, should I pursue a NIL approach and maybe others with similar keys will follow, or come up with another api using events (and basically deprecate three of many of the unused NIL keys for our own purpose).  I'd prefer following the NIL approach, but coming up with a good method to handle these without bloating, say,  bash and sawfish at the same time.

Suggestions on non-cascading methods of NIL support?  are mingetty and X the best places to aim for without changing everything, or is there better?  are these even supposed to know what the NIL is?  Or is a daemon really the way to go?

--
Joseph P. Garcia
http://www.execpc.com/~jpgarcia

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