I never got back about whether I was using kbd or evdev: I'm using kbd. I'm not using gnome or pulseaudio or any of that crap, and all parameters (vol, pitch, and dur) are recorded by xset and are returned by xset q. But are ignored by the bell rung by xterm and emacs, and both code paths in the example code attached to this bug report: https://bugs.freedesktop.org/show_bug.cgi?id=27118 - I just get the default beep
Additionally, supplying the volume parameter to that code also is ignored in favour of the default beep. Note that the bug as originally reported doesn't care about what sound card is attached. As long as the beep can ring on the console, and is played through the internal beeper speaker (or soundcard equivalent with the snd-hda-intel driver on my laptop - whatever beep mechanism is sounded from the console), then X always has been able to for the past decades, adjust the pitch and duration (not the volume in my case, but I didn't care about that, because it could be adjusted in the alsa mixer). That's all I ask. No, the kernel hasn't removed my ability to change such parameters: '/usr/bin/beep -f 200' emits a 200Hz beep through the beeper speaker. No, it does not suffice for my purposes to always run /usr/bin/beep instead of ringing XBell() - XBell() works over the DISPLAY and is network transparent. /usr/bin/bell isn't. No, I can't mute the HDA driver beep as per https://bugzilla.redhat.com/show_bug.cgi?id=526751, because on laptops, the HDA driver beep is the beeper speaker. That *is* what is rung from the console and what used to be rung from XBell(). (to those people complaining that the bell rings at all: then why don't you just blacklist the pcspkr module?) -- TimC "Perhaps the truth is less interesting than the facts?" -- Amy Weiss, RIAA's Senior Vice President of Propaganda^WCommunications -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org