registry team mailing list archive

["Daniel Richard G." <skunk@xxxxxxxxxx>]

Hi Gerfried,

Regarding something you had said earlier:

> Maybe switching from probing /dev/input/event0 to /dev/input/by-path
/platform-pcspkr-event-spkr might be someting to think about, though
that would limit its usage to udev using systems, which I would like to
avoid.and would propably turn into a regression.

The program already does a two-step fallback in a normal invocation
(/dev/tty0, then /dev/vc/0, the latter of which doesn't even exist on my
system); it seems like a three-step fallback with the udev path tried
first would make sound more probable, without bloating the program or
making it break in certain system configurations.

As it is, the documentation doesn't explain what an "event device" is,
and only gives the examples of /dev/tty0 and /dev/vc/0, which at best
gives the hint that "event device == terminal device". Anything under
/dev/input/* is going to seem like a non-sequitur to all but the most
technical users. Requiring the user to specify -e with an appropriate
device is a fairly tall hurdle for a program whose sole purpose is to
make a beep.

Moreover, given that the program is meant to be used in scripts and
such, requiring -e becomes a bit cumbersome---if you don't want to give
it literally with every invocation, you have to stick it into a
variable, or wrap up the invocation in a function/subroutine, etc. And
then if you want the same script to work on different systems....

Perhaps the best point in favor, however, has to do with the strange
situation currently surrounding the pcspkr module in Ubuntu. In a stock
install, the module is blacklisted, because many users hate the old-
school beeps. If you comment out the blacklist entry, the module is
loaded, but you still don't get ordinary terminal beeps---you have to
unload and reload the module a second time in order to get the classic
behavior (see bug #398161). The reason for this is still unknown, and
there's obviously not a whole lot of interest in getting an answer.

What's interesting here, however, is that on a system with pcspkr
loaded, but nonfunctional terminal beeps, "beep -e /dev/input/..."
works. ("beep" by itself does not.) Having the program try the udev path
first would be advantageous in that the program's success then depends
only on whether the pcspkr module is loaded, and not on whatever weird
issue is affecting terminal beeps. Their problem is no longer your
problem.

-- 
The command 'beep' does not produce a sound
https://bugs.launchpad.net/bugs/144022
You received this bug notification because you are a member of Registry
Administrators, which is the registrant for Debian.