Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!ames!hc!beta!hp
From: hp@beta.UUCP (Akkana)
Newsgroups: comp.unix.questions
Subject: Re: Let the Sun-3 beep! How???
Message-ID: <4911@beta.UUCP>
Date: Thu, 30-Apr-87 16:14:44 EDT
Article-I.D.: beta.4911
Posted: Thu Apr 30 16:14:44 1987
Date-Received: Sat, 2-May-87 10:58:21 EDT
References: <1415@ames.UUCP>
Organization: Los Alamos Natl Lab, Los Alamos, N.M.
Lines: 71
Keywords: ^G
Summary: the ioctl doesn't solve the problem


I'm new to this newsgroup, so I may have missed a posting, but ...

I know about KBD_CMD_BELL and all that -- found it in the manual
and wrote a quickie beep routine for the Sun console -- but am I
the only one in the world bothered by the fact that ^G doesn't beep
a Sun console the way it does (practically) ever other terminal
ever made?  I've complained to Sun numerous times about how my
3/160 console doesn't beep when I print a ^G -- which means that
programs like talk and vi can't notify me, because THEY don't do
the kbd ioctl, and also that I won't be notified if I'm rlogged in
from another Sun, because if I try to do the ioctl it will come
out on the wrong screen.  Finally, it means that in all my programs
I have to do something like
#ifdef sun
#include <sundev/kbd.h>
#include <sundev/kbio.h>
#endif
.
.
#ifdev KBD_CMD_BELL	/* if we're on a Sun3, or at least 3.x */
if (on_console)		/* Need to check at beginning of program
			 * to make sure we're on the console so
			 * we don't beep it if someone else is on it
			 */
	ioctl( ...etc )
else
#else
	putchar('\07');
#endif

I mean, it wasn't that hard to figure out, but it's a little
inelegant to have to put that into every single program,
and Sun didn't do it when they wrote talk and vi.

After six months of hearing me talk about it, the local Sun reps
finally told me that there was an ECO which would fix the problem,
and came out to install a new CPU board (note that I had to be on
hardware maintenance to get this fixed).  A week and two CPU
boards later (the first one they sent out didn't work, and it
took several hours to get the second one working, for some reason)
I finally had a machine which supposedly beeped -- and guess what?
It's still barely audible -- too short and too quiet to be heard
when I'm standing across the room (i.e. talk still can't notify
me when someone's trying to talk to me).  And echoing several ^G's
is even less audible than echoing just one.

The Sun2/170 (2.2) I used to use had a wonderful ^G -- it was nice
and loud without being too obnoxious, and if I wanted something
really obnoxious I could always say "echo ^G^G^G^G^G^G^G^G^G^G^G^G^G^G"
and get a long, continuous bell which I couldn't fail to hear.
I'd like to be able to do that on my Sun3 without having to write
a C program (and compile it into all the system programs and PD
programs off the net and so forth) to do it.  Isn't anyone else
bothered by it?  I'm sure it's an easy fix -- I've asked Sun several
times why it isn't possible simply to take the source for the console
driver, find the part where it interprets a ^G, lengthen the time
before the KBD_CMD_NOBELL ioctl, and recompile; Sun is convinced
that it's a hardware problem and changing software won't help it.
Has anybody with source tried it?  (We're in the process of trying
to get source, but it hasn't happened yet.)  Is there something
wrong with my reasoning?  Is it really a hardware problem?  Do
other 3.x Sun3's beep loudly, and mine just happens to have a
strange problem?

..
	...Akkana         Center for Nonlinear Studies, LANL
	akkana%cnls@lanl.arpa   hp@lanl.arpa   ihnp4!lanl!hp

"I think I'll take a walk.  Hmm, wonder where this wire goes?"
			-- Max Headroom