I suspect it may simply be a configuration problem, but as it didn't need any special setting before, I'm not sure where to look. After I upgraded from xorg-server 1.6.3 to 1.7.0 for some reason keyboard bell stopped working, meaning I can no longer hear it. Driver used: xf86-input-evdev. xkeyboard-config 1.6
I have a similar problem, after upgrading from 1.5.3 (fedora 10) to 1.7.1 (fedora 12) the BELL (ascii 7, e.g. executing echo -e "\a") stopped working on /dev/pts/X. However, if I attach to the same X session/display via VNC, the BELL works!? Shouldn't it be reversed, the remote (VNC) should not be able to trigger local beep and the local should.
Created attachment 31942 [details] testcase This test program is enough to trigger the problem: for some reason XBell doesn't work. However, XkbBell does.
Rafał, can you vnc to the display from the outside and check if the XBell() suddenly works? I find it weird that it works under vnc on my side.
Well, my bell works in GViM/Firefox, but not in xterm. However, the bell parameters can not be changed with xset. Also, xkbbell -force does produce a beep. I use ArchLinux with xorg-server 1.7.3.
(In reply to comment #4) > Also, xkbbell -force does produce a > beep. I already said that - xkbbell uses XkbBell, while i.e. rxvt-unicode (probably xterm too) uses XBell.
are you using the kbd driver or evdev only? evdev doesn't seem to set up the BellProc so I'm not sure how that test program could work (didn't work on my evdev-only box). The difference between XBell and XkbBell makes sense, that's fixable though.
I'm using evdev only. Well, that could explain the difference with vnc - IIRC, it's lacking a certain X extension, so it can't use evdev properly and falls back to the old driver.
(In reply to comment #7) > I'm using evdev only. > > Well, that could explain the difference with vnc > - IIRC, it's lacking a certain X extension, > so it can't use evdev properly and falls back to the old driver. Xvnc doesn't use any keyboard driver since it doesn't talk to the local keyboard. It's keyboard input all comes over the RFB protocol from the vncviewer client.
I've had a play at trying to add keyboard bell support to evdev but failed. The code, though similar to what the ioctl does in the keyboard driver doesn't seem to make a sound. Any help there would be appreciated (especially a test program that rings the bell on an evdev kernel device). Meanwhile, reducing priority a bit, without your help I won't be able to spend much time on this.
So, why does XkbBell still work ? Is that implemented in the server ?
On Thu, Dec 17, 2009 at 03:06:57AM -0800, bugzilla-daemon@freedesktop.org wrote: > --- Comment #10 from Rafał Mużyło <galtgendo@o2.pl> 2009-12-17 03:06:56 PST --- > So, why does XkbBell still work ? > Is that implemented in the server ? tbh, I don't know but when I ran the test program neither triggered the bell (probably some local setting, I've never had a need for the keyboard bell)
In that case, 'xset q' reports: bell percent: 50 bell pitch: 400 bell duration: 100 Not sure if it matters, but for the moment can't think about a different setting. Do you have pc speaker among your kernel input devices ? If you don't, perhaps that's a reason for the missing bell in XkbBell case.
i ran modprobe pcspkr and managed to make the terminal beep somehow, but not the test program.
Just so we're on the same page - that test program doesn't beep with XBell, but if you switch comments, it does with XkbBell.
well, that's the theory. in practice, neither is ringing anything :)
Note that some desktops will intercept XkbBell() calls to play sounds themselves (I've seen this in GNOME 2.28 with gnome sound themes for instance).
Perhaps it's a matter of a mainboard/soundcard. All I've got is intel8x0 - it needs nothing but pcspkr (INPUT_PCSPKR). For HDA there's a SND_HDA_INPUT_BEEP_MODE kernel setting, that *may* affect this problem (OK, so I'm grasping at straws).
(In reply to comment #17) > Perhaps it's a matter of a mainboard/soundcard. > All I've got is intel8x0 - it needs nothing but pcspkr (INPUT_PCSPKR). > For HDA there's a SND_HDA_INPUT_BEEP_MODE kernel setting, > that *may* affect this problem (OK, so I'm grasping at straws). > Are you sure it's SND_HDA_INPUT_BEEP_MODE? Because I have only CONFIG_SND_HDA_INPUT_BEEP=y in /proc/config.gz. Anyway, disabling it does nothing on my IHC5 intel card. Also, I don't understand why xset does not work? (In reply to comment #5) >I already said that - xkbbell uses XkbBell, >while i.e. rxvt-unicode (probably xterm too) uses XBell. I was just confirming ;)
Created attachment 32540 [details] Rings the bell on an evdev kernel device. (In reply to comment #9) > I've had a play at trying to add keyboard bell support to evdev but failed. The > code, though similar to what the ioctl does in the keyboard driver doesn't seem > to make a sound. Any help there would be appreciated (especially a test program > that rings the bell on an evdev kernel device). > > Meanwhile, reducing priority a bit, without your help I won't be able to spend > much time on this. I hope this helps you.
For me, this code works only on pcspkr, not keyboard. But if the settings are the same as 'xset q' reports (f=400), sound is correct (root only, as root owns those devices).
To add to confusion: even in X, "printf '\a' > /dev/tty0" does generate a beep.
Created attachment 32581 [details] [review] 0001-Implement-support-for-keyboard-bells.patch something like this should work then. note that this patch is completely untested, it only compiles. we should also set a timer for when the duration exceeds certain values, but that's a bit more complicated and I'd rather check back first whether this approach works.
Well, the bell's there (at least with xorg-server default settings).
If EvdevBellProc is passed to InitKeyboardDeviceStruct, bell rings. However, it seems that EvdevBellProc is not called. Even if EvdevBellProc is empty, bell rings.
I think it may somehow be related to ProcBell in dix/devices returning Success without actually doing anything if BellProc is NULL Do you want to say even a BellProc like 'static foo(int percent, DeviceIntPtr dev, pointer ctrl, int class) {}' works ?
> I think it may somehow be related to > ProcBell in dix/devices returning Success > without actually doing anything if BellProc is NULL > > Do you want to say even a BellProc like > 'static foo(int percent, DeviceIntPtr dev, pointer ctrl, int class) {}' works ? The protocol only allows for a BadValue error in case the value range is outside [-100,100]. There is nothing in the protocol to accommodate for a nonexisting bell, so we must return Success in this case.
Anyway, just as comment 24 says, an empty EvdevBellProc is enough to make bell work.
> --- Comment #27 from Rafał Mużyło <galtgendo@o2.pl> 2010-01-29 17:54:27 PST --- > Anyway, just as comment 24 says, an empty EvdevBellProc > is enough to make bell work. heh. funny. care to submit a patch?
(In reply to comment #28) > > heh. funny. care to submit a patch? > Not sure, what did you meant by that. I simply tried your patch with an empty EvdevBellProc (perhaps it can be simplified even a bit more, can't really tell). AFAICT, if that function is not NULL, default server bell is called, that simply writes \07 to console fd - that's enough for me.
On Mon, Feb 01, 2010 at 05:45:53AM -0800, bugzilla-daemon@freedesktop.org wrote: > Not sure, what did you meant by that. > I simply tried your patch with an empty EvdevBellProc > (perhaps it can be simplified even a bit more, can't really tell). That's enough then, if that works for you submit this as a patch please. I don't have a lot of time to test and since you already got it working on your box, that's enough for me.
(In reply to comment #30) > On Mon, Feb 01, 2010 at 05:45:53AM -0800, bugzilla-daemon@freedesktop.org > wrote: > > That's enough then, if that works for you submit this as a patch please. I > don't have a lot of time to test and since you already got it working on > your box, that's enough for me. > But aren't you one of the people with write access to evdev git ? After all, it's your patch, with just a one block removed (and I'm still not sure if more trimming can be done - I know very little about xorg-server internals).
Alright, I think I found why. The core keyboard is set up with a bell proc initially but that gets overwritten once you hit a key. The idea here is that the device copies the bell proc into the master device so if a client rings the bell it rings it on the last device used. If that device doesn't have a bell proc, the function exits early. If that device does have a bell proc, then that function is called (noop in this case) but the function is also called for all other devices that are attached to this device. One of these devices is the XTEST keyboard that has the bell proc set and eventually calls through to xf86OSRingBell which I guess is what produces the sound. That also explains why XkbBell works but XBell doesn't - XkbBell always loops through all devices.
Created attachment 33303 [details] [review] 0001-dix-try-to-ring-the-bell-even-if-the-current-device-.patch x server patch to replicate the XKB behaviour.
ping? any testing successes so far?
Sorry, I thought it's a patch that already went into master. Yes, this solution works too. On a not really related note: how far you, people, still care about 32bit ? Cause warnings like "warning: cast from pointer to integer of different size" (xorg-server 1.7.5) start to make me worried. Perhaps those particular ones are harmless, but still give a bit sloppy feeling.
> Yes, this solution works too. thanks for testing! > On a not really related note: > how far you, people, still care about 32bit ? > Cause warnings like "warning: cast from pointer to integer of different size" > (xorg-server 1.7.5) start to make me worried. > Perhaps those particular ones are harmless, but still > give a bit sloppy feeling. where is this? I'm on 32 bit most of the time, so usually I try to catch those but some slip through. These warnings should be fixed but please send me a private email on this (or to xorg-devel) to avoid flooding the bugreport with unrelated info.
Fixed, thanks to all for your help with this bug. commit 758f6971750ed507e64eee817d720a77181439f2 Author: Peter Hutterer <peter.hutterer@who-t.net> Date: Mon Feb 15 16:32:16 2010 +1000 dix: try to ring the bell even if the current device doesn't have one. (#24503)
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.