Bug 232828

I'm using screen-4.0.3-2.fc6 and aumix-2.8-11.fc6, in an xterm. For me, aumix
freezes solid and has to be be explicitly killed from a different shell before
it would go away.
I'm wondering if it's some interaction between ncurses and screen. Other programs
based on curses seem fine (e.g., mutt). However, aumix is linked against
libcurses.so.5, whereas mutt uses libcursesw.so.5.

I need to figure out what that means, and whether it explains the problems we see.

I'll get back to you once I know more...

ok, ncurses vs. ncursesw is not it. Rather, it dies when calling StartMouse()
from main(). I'm trying to track down exactly why, and see if there's some
easy fix. Be back when I know more...

Not sure this is helpful to your debugging, but I now recall that I too
sometimes get the 'frozen' screen rather than exit to screen prompt. Haven't
really found a pattern to it.

Here's what I found out: StartMouse() calls mousemask() to request that
clicks be picked up by wgetch(stdscr). When your term is "screen", wgetch
goes nutters and returns -1 in a very tight loop, ignoring any keys or
clicks from the user. It seems fine when we're either not using screen, or
when we're not calling mousemask().

So, I call termname() to find out whether we're running from screen, and skip
over the mousemask() call if that is the case. Now it works within screen, but
with no mouse clicks while inside screen (no other program I tried actually
receives mouse clicks while inside screen, not sure if that's by design or a
bug in screen)

In the process of debugging this and writing a patch, I also threw out a bunch
of cruft (the console/sysmouse code, and the gtk code which we don't build for
Fedora anyway) just to make things more readable. This thing was orphaned from
Core a while back for good reason :) it's just that I like its graphical layout
too much to let go of it, which is why I put it back in Extras :)

My long-term plan is to write a modified version of alsamixer which looks like
aumix instead of alsamixer, and ditch aumix when that's done... That would have
the added advantage of not going through the oss compatibility layer...

Anyway, for now, plese give this a try:

http://www.contrib.andrew.cmu.edu/~somlo/aumix-2.8-14.i386.rpm

and let me know if it fixes your problem. If yes, I'll commit it to
CVS and request a build for it.

Thanks for continuing to maintain 'aumix'.
For day-to-day use of just adjusting volume from an xterm, I much prefer its
clean simplicity to the in-your-face color and graphics of alsamixer.

Most of the time I access my linux box from my windoze laptop via PuTtY -- so I
really appreciate cgi or simple ncurses graphic programs like aumix.

So please do continue to maintain this as a simple alternative to either
alsamixer or whatever the bloated gnome/kde widget-du-jour is (because if I
wanted an eye-candy, dumbed-down, slow-as-molasses, point-and-click interface I
would just use windoze...)

new version seems to work for me!

Thanks!

There's probably more I need to learn about ncurses, e.g. if cbreak + timeout
does the same thing as halfdelay would, and why we still need to set an alarm
to wake us up periodically if wgetch will only block for the duration of the
set timeout, etc.

Once I figure that out, maybe I won't need to special-case TERM="screen" anymore.

However, in the interim, I've submitted rel. 14 to the build system, and it should
be available in the repos within a day or two.