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]

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

[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

[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

[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

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

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

[Iain Sandoe]

On Wed, Jul 18, 2001, Joseph P. Garcia wrote:
>[snip]
> - we also have other events we may consider to add, such as headphone
> insert,

this *should properly* be handled by the dmasound driver - it needs to
understand the sound hardware (and on some models shares interrupts with
other sound stuff)

- I just didn't get round to implementing it yet :-(

---

apart from that - as far as sound-related stuff is concerned (e.g. volume
key-presses) - my only care is that controls appear to dmasound through the
ioctl() interface already defined ... to avoid a maintenance nightmare. ...

ciao,
Iain.

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

Re: powermac (other ppc?) events

[Joseph P. Garcia]

Greetings.

Oops.  forgot to post to the list.

On Thu, 19 Jul 2001 00:01:03 +0100
"Iain Sandoe" <iain@sandoe.co.uk> wrote:
> >> this *should properly* be handled by the dmasound driver - it needs to
> >> understand the sound hardware (and on some models shares interrupts with
> >> other sound stuff)
> >
> > I had this implemented in a patch posted long long ago (mac-like sound
> > controls iirc).  Mostly met with 'I like dual volume controls'.  Given
> > that, it should be runtime disable-able.  so that would mean either another
> > event for our daemon, a proc interface, or an ioctl.  Preference?
>
> well, it's not possible on all models to have the twin volume controls - it
> works on the G3/Beige - which I'm sitting at - and, I think, on some of my
> other machines ... but the headphone level is not independently split out
> (IIRC) on, say, the iMac - (correct me if wrong - I haven't got round to
> looking at it yet)...

Here's where the original post was.  thread easily followable from there.

http://lists.linuxppc.org/listarcs/linuxppc-dev/199909/msg00288.html

I recall my implementation was a little flaky in the sleep department, but the core interupt and register handling is in there.  under AUDIO_SWITCHING defines.  its interwoven into an earlier version of the volume controls that someone else
provided.  And this was written for 2.2.

It's a start, but not at all useful as is.

Hope this helps.

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

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/

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: powermac (other ppc?) events

[Iain Sandoe]

> work as well.  As is, volume keys seem to rank low in the priority queue.
> something to get practice on.

Look, I don't have a proper opinion on how the keys are achieved ...

---

all I want is that the sound driver is:

1/ called through the standard ioctl() for volume - however many "volumes"
you want to adjust.

This is so that *your* interface will work with *any* dmasound-supported
hardware (without hacking dmasound for each chipset).

We currently support 3 1/2 chipsets - with two more in the pipeline + Apple
is releasing sound hardware variants faster than we can keep up with the
driver already ;-))

also think about how it might interact with USB audio ...

you ***really*** ***don't*** want to go down the road of hacking every sound
driver for volume keys.


2/ Let dmasound handle the headphone insertion - it is already dealing with
the hardware and the appropriate interrupts.

By all means - if there is a consensus that we *need* User Control over
whether headphone insertion disables the internal speaker (or not) - then I
am happy to use one of the OSS "special purpose" ioctl() values to control
this as a PMac-specific feature - which will work properly via the proper
ioctl().

just my 0.02 euro ...

but I am (at least unofficially) maintaining the driver at the moment.

ciao,
Iain.

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

Re: powermac (other ppc?) events

[Michael Schmitz]

> Look, I don't have a proper opinion on how the keys are achieved ...
>
> ---
>
> all I want is that the sound driver is:
>
> 1/ called through the standard ioctl() for volume - however many "volumes"
> you want to adjust.
>
> This is so that *your* interface will work with *any* dmasound-supported
> hardware (without hacking dmasound for each chipset).

That was my idea in this - have some sound event daemon watch for events
and call the proper ioctl. What was with the sound driver only permitting
a single open() at a time? Would aumix running block the sound
event daemon's ioctl?

	Michael


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

Re: powermac (other ppc?) events

[Iain Sandoe]

>> Look, I don't have a proper opinion on how the keys are achieved ...
>>
>> ---
>>
>> all I want is that the sound driver is:
>>
>> 1/ called through the standard ioctl() for volume - however many "volumes"
>> you want to adjust.
>>
>> This is so that *your* interface will work with *any* dmasound-supported
>> hardware (without hacking dmasound for each chipset).
>
> That was my idea in this - have some sound event daemon watch for events
> and call the proper ioctl. What was with the sound driver only permitting
> a single open() at a time? Would aumix running block the sound
> event daemon's ioctl?

The single open() rule is for /dev/dsp ... it is part of the OSS spec.
Actually, it is the opposite of what you've suggested - the OSS rule says
that open() shall *not* block - waiting for the device - but return straight
away with EBUSY.  (we *were* blocking on a sleep queue).

Up until my latest set of patches we were breaking this rule.  As of today
those patches are in Ben's tree but not BK (although they are in my ftp
space on penguinppc.org as well).

/dev/mixerXX can be opened multiple times - so this doesn't affect aumix et.
al.

However, one of the really nasty things about OSS is that you can't
guarantee that /dev/mixer0 belongs to /dev/dsp0  (cute eh?).  So, if you
have a sound dev open and want to be sure that you are sending volume
controls to the same device you have to send the mixer commands to /dev/dsp.

It's, perhaps, a moot point since "mixers" are really User Interface devices
- and there is an identification of which mixer you are talking to supplied
by one of the ioctls() - so, for example, with the latest (patch, benh)
dmasound_pmac - you will see the dmasound mixer identified as "Power Mac
Built-In Sound" on a kmixer tab.

If your GUI/Command Line mixer-of-choice doesn't identify the actual device
- it needs modifying - because otherwise it stores up trouble for the user
where there are multiple devices in the system...

as I have (perhaps wryly) noted ... most of the OSS mixer authors don't seem
to have RTF(OSS)M ;-)))

ciao,
Iain.

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

Re: powermac (other ppc?) events

[Michael Schmitz]

> > That was my idea in this - have some sound event daemon watch for events
> > and call the proper ioctl. What was with the sound driver only permitting
> > a single open() at a time? Would aumix running block the sound
> > event daemon's ioctl?
>
> The single open() rule is for /dev/dsp ... it is part of the OSS spec.

OK, I assumed it applied for all interfaces.

> Up until my latest set of patches we were breaking this rule.  As of today
> those patches are in Ben's tree but not BK (although they are in my ftp
> space on penguinppc.org as well).

I recalled you mentioned this lately, so I asked :-)

> /dev/mixerXX can be opened multiple times - so this doesn't affect aumix et.
> al.

Fine then. We just need to figure what's the default mixer to use, then.

	Michael


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