Re: patches: MacOS-like Wallstreet sound in/out controls

Re: patches: MacOS-like Wallstreet sound in/out controls

[Benjamin Herrenschmidt]

On Sun, Sep 19, 1999, Dan Malek <dmalek@jlc.net> wrote:

>Since I was the last one to check in changes to the driver, I have kind of
>been nominated to do this again.  I have patches from several people for some
>functional updates on new hardware.  I can add these in/out controls if
>people really want them.
>
>
>While I understand the convenience of these in/out controls, I personally
>don't
>like them.  I run a variety of programs that perform these operations for me.
>Sometimes I want to run both line out and speakers at the same time, or
select
>the microphone without having to unplug line in.  I guess the in/out doesn't
>prevent
>me from doing this, just that a change (plug in or out) will cause a
>configuration
>change without my mixer knowing.  If people generally want these, I'll put
>them
>in along with the other changes I am making.


A better solution would  be to make the appropriate infos available to
userland (eventually via a private ioctl of the sound driver). Then, we
could have an optional damon handling all this automatically that can be
unplugged for people who like controlling everything manually. If no-one
have time to write this, then you may include the patches anyway but
wrapped in a compile option. (I'd like the volume button patch anyway).

On a similar way, I'm wondering what is the best way for the eth driver
to tell userland about it's link status. I'd like to add to Paul's pmud a
way to have scripts run when the link goes down and up. (basically, this
would ifdown eth0 completely to remove it from the router, change my
default route to the one I need for PPP, etc...)


-- 
           E-Mail: <mailto:bh40@calva.net>
BenH.      Web   : <http://calvaweb.calvacom.fr/bh40/>


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

Re: patches: MacOS-like Wallstreet sound in/out controls

[Joseph Garcia]

Benjamin Herrenschmidt wrote:
> A better solution would  be to make the appropriate infos available to
> userland (eventually via a private ioctl of the sound driver). Then, we
> could have an optional damon handling all this automatically that can be
> unplugged for people who like controlling everything manually. If no-one
> have time to write this, then you may include the patches anyway but
> wrapped in a compile option. (I'd like the volume button patch anyway).
> 
> On a similar way, I'm wondering what is the best way for the eth driver
> to tell userland about it's link status. I'd like to add to Paul's pmud a
> way to have scripts run when the link goes down and up. (basically, this
> would ifdown eth0 completely to remove it from the router, change my
> default route to the one I need for PPP, etc...)

since we aren't psychics, the daemon should have a configuration and script
place in /etc (/etc/pmu?).  the config would allow the user to control some
standard responses on how it acts internally. (like volume control, switching,
etc)  then the option to do additional things in scripts.  Given the potential
flexibility people may want, does this mean C is too static, and thus perl or
another more script-friendly language should be used?

If all goes well, we may eventually have a "apmd" for ppc.  any reason we
shouldn't try to use apmd as a framework?  have a so-called "apmd-compatibility"
mode where we can use the standard PC apmd as our frontend?  or does it not have
features like eth detect, so its not worth the bother?  (never had a pc laptop)

a few ideas from a peanut.

-- 
Joseph P. Garcia      jpgarcia@execpc.com      jpgarcia@lidar.ssec.wisc.edu
CS Undergraduate                      Student Employee - Systems Programmer
University of Wisconsin - Madison                            UW Lidar Group

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

Re: patches: MacOS-like Wallstreet sound in/out controls

[Shaw Terwilliger]

Joseph Garcia wrote:
> since we aren't psychics, the daemon should have a configuration and script
> place in /etc (/etc/pmu?).  the config would allow the user to control some
> standard responses on how it acts internally. (like volume control, switching,
> etc)  then the option to do additional things in scripts.  Given the potential
> flexibility people may want, does this mean C is too static, and thus perl or
> another more script-friendly language should be used?

ALSA takes a reasonable approach to this problem; there's a user-space
utility called alsactl that can read a simple configuration file and
apply those values to the hardware or read the settings from the hardware
and write them to a file.  Normally this program is used during startup
and shutdown, to keep mixer settings between them.  A daemon would be
more appropriate for sleep or other PMU events.

Also, does anyone have a solution to my Lombard audio problem?
After a snooze, it comes back up and my audio is gone.  The kernel
driver seems to be there (mixers remember all previous levels and
can set new ones), and user-space access to /dev/dsp and /dev/audio
works, but nothing comes out of the speakers.

-- 
Shaw Terwilliger (sterwill@io.nu)

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

Re: sound sleep

[Joseph Garcia]

Shaw Terwilliger wrote:
> Also, does anyone have a solution to my Lombard audio problem?
> After a snooze, it comes back up and my audio is gone.  The kernel
> driver seems to be there (mixers remember all previous levels and
> can set new ones), and user-space access to /dev/dsp and /dev/audio
> works, but nothing comes out of the speakers.

i have this problem ony my wallstreet/300 also.  I don't know of a fix yet.  A
temporary way around it would be to make a module of dmasound, and rmmod it
before sleeping, and insmodding it after, however it seems that this code is
also broken.  interrupt allocation.  will panic upon a 3rd insmod, or a cat of
/proc/interrupts while it is not installed.  If this were fixed, i'd think the
sleeping issue would be a snap.

-- 
Joseph P. Garcia      jpgarcia@execpc.com      jpgarcia@lidar.ssec.wisc.edu
CS Undergraduate                      Student Employee - Systems Programmer
University of Wisconsin - Madison                            UW Lidar Group

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

Re: sound sleep (more)

[Joseph Garcia]

i forgot to add that i wrote the i/o interrupt handler code as a side thing
while trying to debug the sound not waking up.  The thing it helped me determine
is that the interrupts are still produced after sound disappears.  so the system
is still there.  sound is produced after a sleep if the module is
removed/slept/isntalled, but not if it is installed while sleeping.   so is the
sound system handled by the PMU always or just when powered up?  is it powered
up only when the module is installed?  If the PMU always handles sound upon
sleeping, why does it work when the module isn't installed at sleep?  any way to
check this further?

more questions i cant answer.

-- 
Joseph P. Garcia      jpgarcia@execpc.com      jpgarcia@lidar.ssec.wisc.edu
CS Undergraduate                      Student Employee - Systems Programmer
University of Wisconsin - Madison                            UW Lidar Group

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

Re: sound sleep

[Takashi Oe]

On Sun, 19 Sep 1999, Joseph Garcia wrote:

> i have this problem ony my wallstreet/300 also.  I don't know of a fix yet.  A
> temporary way around it would be to make a module of dmasound, and rmmod it
> before sleeping, and insmodding it after, however it seems that this code is
> also broken.  interrupt allocation.  will panic upon a 3rd insmod, or a cat of
> /proc/interrupts while it is not installed.  If this were fixed, i'd think the
> sleeping issue would be a snap.

Try changing the last argument of request_irq() in PMacIrqInit() and
free_irq() in PMacIrqCleanup().  For example, change
	request_irq(awacs_irq, pmac_awacs_intr, 0, "AWACS", 0)
and
	free_irq(awacs_irq, pmac_awacs_intr)
to
	request_irq(awacs_irq, pmac_awacs_intr, 0, "AWACS", (void *)awacs)
and
	free_irq(awacs_irq, (void *)awacs).
I think that's what I did in order to get rid of the panic.

For the wake up problem, does it help if you put the code similar to the
following in awacx_sleep_notify()?

before enable_irq()'s:

	o

Re: sound sleep

[Joseph Garcia]

Takashi Oe wrote:
> Try changing the last argument of request_irq() in PMacIrqInit() and
> free_irq() in PMacIrqCleanup().  For example, change
>         request_irq(awacs_irq, pmac_awacs_intr, 0, "AWACS", 0)
> and
>         free_irq(awacs_irq, pmac_awacs_intr)
> to
>         request_irq(awacs_irq, pmac_awacs_intr, 0, "AWACS", (void *)awacs)
> and
>         free_irq(awacs_irq, (void *)awacs).
> I think that's what I did in order to get rid of the panic.

Wonderful!  it now works.  this fix should go into the kernel.

I would also like to note that with this now working,  with the sound as a
module, while sound still breaks when put to sleep on a wallstreet, it is
revived upon removing and reinstalling the module.  People may want to see if
this happens on a lombard as well.

-- 
Joseph P. Garcia      jpgarcia@execpc.com      jpgarcia@lidar.ssec.wisc.edu
CS Undergraduate                      Student Employee - Systems Programmer
University of Wisconsin - Madison                            UW Lidar Group

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