Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.

Bug 232828

Summary: aumix doesn't work with '/usr/bin/screen' program
Product: [Fedora] Fedora Reporter: Need Real Name <bugzilla>
Component: aumixAssignee: Gabriel Somlo <somlo>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: 6   
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-03-21 15:14:39 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Need Real Name 2007-03-18 14:41:50 UTC
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...

Comment 1 Gabriel Somlo 2007-03-19 17:12:11 UTC
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, whereas mutt uses

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

Comment 2 Gabriel Somlo 2007-03-20 15:23:51 UTC
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...

Comment 3 Need Real Name 2007-03-20 15:31:02 UTC
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.

Comment 4 Gabriel Somlo 2007-03-20 22:01:55 UTC
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:

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

Comment 5 Need Real Name 2007-03-20 22:57:09 UTC
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...)

Comment 6 Need Real Name 2007-03-20 22:59:38 UTC
new version seems to work for me!


Comment 7 Gabriel Somlo 2007-03-21 15:14:39 UTC
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.