Comment 12 for bug 144022

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.