XkbBell still beeps with 'xset -b'

[dcarter@…]

The xset utility is unable to change the bell setting in local xterms. If I open a local xterm and run: "xset b off" is has no effect, the bell still sounds. If open a remote xterm on a different host (Linux), and run: "xset b off" it turns off the bell for all xterms, except local xterms.

I installed Xquartz 2.5.0_rc1 from the dmg image.

[dcarter@…]

Replying to dcarter@…:

The xset utility is unable to change the bell setting in local xterms. If I open a local xterm and run: "xset b off" is has no effect, the bell still sounds. If open a remote xterm on a different host (Linux), and run: "xset b off" it turns off the bell for all xterms, except local xterms. I installed Xquartz 2.5.0_rc1 from the dmg image.

A little more info, in case it's useful...

If I go to a different machine (MacBook) running 2.4.0, and remotely start an xterm from the 2.5.0 machine, the "xset b" command (in the new xterm) has no effect at all. (It cannot disable or enable the bell, regardless of current state)

[jeremyhu@…]

I sent email to xorg-devel for more info about how this is supposed to be handled:

 http://lists.x.org/archives/xorg-devel/2010-March/006265.html

[jeremyhu@…]

Actually, it seems to be behaving per the spec. 'xset -b' does not turn the bell off. It sets the base volume to 0. XBell() can then increase the volume it it desires.

My guess is that the remote xterms are using XBell(0) whereas the local xterms are using a positive argument to XBell() ...

How are you triggering the bell in xterm?

[dcarter@…]

Well technically speaking, setting the volume to 0 is the same thing as "off", I just don't want to hear it.

It gets triggered mostly during tab-completion on the command line and/or any event that would trigger the bell, like hitting backspace when the cursor is at an empty prompt and, countless keystroke events in vi.

I guess I'm not clear on where this setting resides. I thought it was in the server. Until now, I could issue one "xset -b" and all xterms would be effected. I don't understand how the server would know the difference between a local and remote xterm. Isn't this the same as a setting a font path?

Until now, the config I've been using for years (on *nix and mac) is a "xset" -b in my ~/.xinitrc file.

Is there something I'm missing?

[jeremyhu@…]

Replying to dcarter@…:

Well technically speaking, setting the volume to 0 is the same thing as "off", I just don't want to hear it.

Hey, I'm on your side here. I think it's quite odd. Feel free to chime in on xorg-devel ... here's my follow-up (to which nobody has responded yet):

 http://lists.x.org/archives/xorg-devel/2010-March/006267.html

It gets triggered mostly during tab-completion on the command line and/or any event that would trigger the bell, like hitting backspace when the cursor is at an empty prompt and, countless keystroke events in vi.

As a side note, I can't reproduce this with urxvt on the same server, but it does happen with xterm. It looks to be an xterm issue.

I guess I'm not clear on where this setting resides. I thought it was in the server. Until now, I could issue one "xset -b" and all xterms would be effected. I don't understand how the server would know the difference between a local and remote xterm. Isn't this the same as a setting a font path?

No. I think this is a bug in xterm, and the remote xterm is just a version prior to when the bug was introduced. Run this on both machines:

xterm -version

Until now, the config I've been using for years (on *nix and mac) is a "xset" -b in my ~/.xinitrc file.

I'm guessing that should work. I'm reporting this issue to the xterm developer for input. PS, don't use ~/.xinitrc. I recommend you use a ~/.xinitrc.d directory instead.

Is there something I'm missing?

[jeremyhu@…]

Upstream bug report opened:

 https://bugs.freedesktop.org/show_bug.cgi?id=27118

This behavior is consistent with the rest of the server (so it will effect your linux box once it gets up-to-date with Xorg).

[jeremyhu@…]

Resolving as "duplicate" as this is an issue not unique to the XQuartz DDX, and I've filed an upstream bug.