Re: powermac (other ppc?) events

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

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]

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

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/