Description of problem: Running 'aumix' under 'screen' causes aumix to immediately exit back to the unix prompt after drawing the controls. No input or changes is possible. No error message is given but the return code is 141. This bug happens both on the most recent version of aumix (aumix-2.8-13.fc6) and at least the previous version. However, several months ago, it all worked fine. I am currently using screen-4.0.3-2.fc6. The weird thing is that I have gone back and tried to use the old binaries for both screen and aumix from December/January (when aumix still worked properly under screen) and it no longer works, so it seems that something else changed outside of the screen and aumix programs that now makes aumix no longer work under screen. I'm stumped...
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.