> Date: Fri, 13 May 2016 10:43:43 +0200
> From: Matthieu Herrb <[email protected]>
>
> On Fri, May 13, 2016 at 12:56:52AM -0400, Ted Unangst wrote:
> > 1. I have wsconsctl keyboard.bell.volume=0 because I don't like things
> > beeping
> > at me. This recently stopped working in xterm, where I now get a loud beep.
> > Related to loss of pcvt?
> >
> > I'm not sure where the failure is, but my expectation is that if I say the
> > glass console doesn't beep, then I don't want it beeping. Somehow the beeps
> > are getting routed into the audio device before wscons fixes them.
> >
> > 2. Even with mixerctl inputs.mix_beep=0 I still here beeps. They are softer,
> > but they are not gone. My expectation is that if I set something to 0, it
> > should disappear.
>
> As I wrote a few weeks ago, an hint to figure out the origin of the
> problem is that when swicthing X to use native wscons(4) interfaces,
> the X bell code was changed.
>
> In /usr/xenocara/xserver/hw/xfree86/os-support/bsd/bsd_bell.c
> the code switched from the #if defined(PCVT_SUPPORT) to the code in
> the #if defined(WSCONS_SUPPORT) chunk.
>
> The old code goes through /sys/dev/wscons/wsdisplay_compat_usl.c to
> handle the KDMKTOME ioctl() while the "new" one directly calls
> WSKBDIO_COMPLEXBELL in /sys/dev/wscons/wskbd.c
>
> I have not tried to understand the difference yet.
Well, it is easy. WSKBDIO_COMPLEXBELL allows the caller to specify
pitch, voltume and duration of the beep. The WSCONS_SUPPORT code in X
uses this to actually implement the full X keyboard bell interface.
So now it actually uses the volume configured with xset (or whatever
graphical tool your desktop environment provides). And the default
X server keyboard bell volume simply isn't 0.
I personally think the wsconsctl settings should be respected by X.
The way the X code is structured, it is difficult to make xset(1)
control the keyboard.bell settings directly. A possible way to
achieve some sort of coordination is to scale the volume indicated in
the WSKBDIO_COMPLEXBELL with the current wscons volume level. So
something like the (untested) diff below.
But perhaps we should have a more fundamental discussion about things
first about how X should interact with wscons. There is a more
fundamental problem here where X assumes it has full control over the
hardware. There still is the volume key issue and there are problems
with tying the new keyboard backlight support into all of this as
well, since X puts the keyboard in "raw" mode which bypasses all the
normal wscons command processing. I think we need to move away from
this and have X use "event" mode.
Index: wskbd.c
===================================================================
RCS file: /cvs/src/sys/dev/wscons/wskbd.c,v
retrieving revision 1.83
diff -u -p -r1.83 wskbd.c
--- wskbd.c 12 Dec 2015 12:30:18 -0000 1.83
+++ wskbd.c 13 May 2016 09:20:05 -0000
@@ -1037,6 +1037,7 @@ wskbd_displayioctl(struct device *dev, u
case WSKBDIO_COMPLEXBELL:
ubdp = (struct wskbd_bell_data *)data;
SETBELL(ubdp, ubdp, &sc->sc_bell_data);
+ ubp->volume = (ubp->volume * sc->sc_bell_data->volume) / 100;
return ((*sc->sc_accessops->ioctl)(sc->sc_accesscookie,
WSKBDIO_COMPLEXBELL, (caddr_t)ubdp, flag, p));
