Description of problem: When running XFCE or KDE desktop, the bell/beep is silent. At least, I cannot find a way to un-mute it. This works without any effort when running the GNOME desktop environment. Version-Release number of selected component (if applicable): Fedora 11, 12, and 13 How reproducible: Always. Steps to Reproduce: 1. Install xterm 2. Start xterm 3. 'echo ^G' 4. Or, install xorg-x11-xkb-exxtras and run 'xkbbell', or run xbiff, irssi, any program that makes a bell/beep. Actual results: Silence. Expected results: An audible alert of some kind in keeping with the sound chosen sound scheme should result. Additional info: I have tested this in F11 F12 and F13 recently. All exhibit the same behavior for XFCE & KDE, but that's not the case for Ubuntu and was not the case before F11.
Wow. You want that horrible beep? :) Anyhow, what does the following output: xset -q and lsmod | grep pcspkr In both the gnome and non gnome cases?
Ah, sorry, I mean to explain that. This is *not* a duplicate of Bug 520137 (https://bugzilla.redhat.com/show_bug.cgi?id=520137). I'm not talking about the PC Speaker beep. xset is correctly set to typical defaults. > xset q ... bell percent: 50 bell pitch: 400 bell duration: 100 Pointer Control: acceleration: 2/1 threshold: 4 I really don't care what noise I get. Yes, I'd be happy with the PC Speaker beep *or* the currently configured alert bell sound, but *neither* occurs. Silence. The sound subsystem works, otherwise. I can play music, select a sound scheme, even hear the alert noise when I select it. But no sound is produced when the bell event occurs. Plus, xterm is clearly receiving the bell event from the application, since visual bell, pop (up) on bell, and bell urgency all work as expected. Either something is catching the bell event passed to it by xterm and deliberately ignoring it, or the mechanism that catches the bell event from xterm is broken. I which I knew what software was involved with that so I could investigate, but I don't know how this is supposed to work.
Ah sorry, that wasn't bug I was thinking of, but I did want to mention it. There have been other complaints about missing PC Speaker noise, but that's not this bug, either.
This looks like it might just be bug 520137 which you have commented on? ie, XBell not working?
Nope, definitely not. As I explained, I have the patched version of xorg and the problem is still present. Besides, that but affects Gnome, too; this doesn't.
I've tested LXDE, Openbox, and Hackedbox, now, also. Same issue. Some kind of glue is missing for all these window managers. Does anyone know what it is?
Do any other terminal programs show the same behavior? (Terminal in Xfce disabled audible bell by default, but you can change that with a hidden option, see: /usr/share/doc/Terminal/C/advanced.html). roxterm has a pref, etc. Do some of those work? Or none? I'm at a loss to what gnome would be doing any differently here...
I'm not sure if this is related, but I'll mention it here. I upgraded a working F12 system to F13, and found that with Gnome/sawfish I didn't hear any sound when xterm, gnome-terminal, emacs, etc., rang the bell. I tried replacing sawfish with metacity, and at this point ringing the bell caused a sound to be played through my sound card. So far so good. Then something unexpected happened. I quit metacity, and found that ringing the bell now causes a sound to be produced by the PC speaker, exactly as it did for me in F12. This has persisted across a reboot.
re: other terminal emulators: Yes. I've tried LXTerm and XTerminal. They show the same behavior: bell produces no sound. And, it's not just terminal emulators. xbiff is affected. I think gvim is affected. I'm certain it's all bell events, not just some apps. The only programs I can get to make any sound use the sound interfaces directly or indirectly. 'play' works and the programs that call 'play' work (like orage). Rythmbox works, etc. The bell/beep messaging is disrupted, but all the components required to make it work are functional. re: metacity That is very interesting. Hmm. That's really weird that your PC speaker behavior has persisted across reboots. I don't get that. Metacity changed a setting that didn't affect just metacity. Well, I guess that could happen. But, when I login to Gnome, logout, and then login w/ Xfce, I still get nothing. It still seems like the messaging was changed and only Gnome got the update. I just don't know what part of the desktop environment that would be. I assumed it was the window manager that caught that event, but maybe not. Metacity might be promoting the bell/beep event to a desktop sound, but xfce and lxde WMs can do that too. BTW, pscpkr *is* loaded on my system, so if the event was being handled that way, I should hear it and I don't.
It gets stranger. It seems that that the X11 bell keeps working across a reboot, but not if I shutdown and start the system back up again. This makes it sound like some kind of hardware initialisation issue, but that doesn't fit with the fact that the bell works fine from the console all the time.
Hmm, I don't hear anything on the console. I can't remember the last time I did. It was a while ago. That was after your trick replacing sawfish w/ metacity, right? P.S. I see this bug has drawn interest from a couple people. Would you spare a few votes for this bug, please?
No, my console bell worked from the outset. Looks like mine is a different bug. I'd file it separately, but I happened to upgrade the system board on the affected system this week and now my bell works as expected.
Now that I've transitioned some work off my Ubuntu system, this has become a serious problem for me. I run five different programs that rely on this long-standing feature, and I rely on the feature to notify me when these applications need attention. Is there anything I can do to help diagnose this problem? I would like to help.
Wow, I just assumed this was fixable. Is there anyone who knows anything about this? Seriously, I'm missing IMs, new e-mail notifications, and IRC messages because of this bug. I can't live with this.
ok. I poked around tonight on this. I think it's two things: 1. Pulseaudio doesn't deal with xbell events by default. It just ignores them. 2. metacity/compiz do pick those up and thats why it works there. I think you can configure pulseaudio to handle your use case: 1. yum install pulseaudio-module-x11 2. edit /etc/pulse/default.pa 3. Uncomment: load-sample-lazy x11-bell /usr/share/orage/sounds/Tear.wav (or whatever wav you want) load-module module-x11-bell sample=x11-bell 4. pulseaudio -k 5. wait for a sec and pulse should restart. 6. Try a bell and it should play that wav. 7. profit. I do kind of think it's odd that pulse ignores those by default, but on the other hand almost no one noticed or cared. ;( Can you try the above and see if it solves your issue?
Wow. Thanks, Kevin! Thanks for tracking that down. I'm getting sound now. I had no idea that it was be a pulse issue. Sorry! I didn't know where the event was getting lost. But, you clearly found it: it's pulse. There's a warning against using this workaround in the configuration file, but it's not clear why using the X11 modules prevent session sharing, why not sharing is bad, or what is the alternative. But, I'm not very worried about that. Did you notice the volume of the xbell is not adjustable using this method? It's not a part of the "Alert" volume, nor the "System Sounds" volume. BUT, that's got nothing to do with XFCE, so I'll bug the pulseaudio folks about it, you'll be happy to hear. I agree, it's very strange that pulse ignores xbell events. Since I was totally unable to track this down, but you did it, I'd like to ask you one thing. I realize I'm the only one who bother to report this, but I'm not be the only person who uses SSH and supports Linux servers. Is there some way forward that I can assist? What's the right solution for XFCE users?
Cool. So, probibly you want to file a new bug against pulseaudio or we can reassign this one and see what they think. As for Xfce, you're the only one who noticed. ;) So, I would say in order: 1. Just configure your apps to play sounds themselves, don't use beep. or 2. Use this workaround or 3. disable pulse entirely to go back to the old xbell behavior (not tested here, but a 'yum remove alsa-plugins-pulseaudio' and restarting should get you a non pulse setup. So, I don't think there is much more we can do here. Shall I close this now? Or reassign it over to pulseaudio ?
If you could reassign this to the pulseaudio folks, I would appreciate it. I was just wondering if XFCE was going to do what Gnome did and create a new handler for xbell. I take it that's not going to happen. I asked you about the "right" solution because I don't know what the Fedora gods intended. If the intention is for the window manger to handle this case, then that sounds like an XFCE bug. If they intended pulse to work with xbell, then it should go to the pulseaudio team. If they intended for all software packages to call sounds directly or integrate with the desktop sound system, then that's a number of other packages. I sounds like XFCE is expecting pluse to handle this, so let's see what they say. I'll try 1, of course. Thanks again, Paul
I don't know of any plans to do so. You could ask on the upstream Xfce lists...
Okay, thanks Kevin. I'll do that. BTW, I solved the volume problem. Traditional bell volume control, xset b, works, which is fine. Since you fixed this feature for me, I've noticed that other programs I use, including Firefox, also use the xbell. So, I was missing even more events than I thought. Many thanks!
Now that this bug has moved to the pulseaudio team, please let me know how I can help.
Hmm, what's the issue here? PA doesn't do any xkb bell magic by default. That's intended. If you want to hookup xkb bell with proper audio then use a window manager that is able to forward xkb bell events to libcanberra or suchlike, the way metacity does it. module-x11-bell is not really a solution since it configures the event sound on the server side, but the right place is the client so that it matches the sound theme and so on. I will not enable module-x11-bell by default. So, can somebody tell me what exactly is being requested here?
I wish I knew. I've been trying to figure out how to handle this for months. When I reported this to the Xfce team, they said they were passing beeps to pulseaudio, which was supposed to handle beeps. It seems likely the other desktops are doing the same. So, if any non-metacity desktops are going to work then something has to be done with PA. I *guess* that's what is expected. You don't have to enable that module on the "Desktop Edition." But now that Xfce and LXDE and all the other desktops have their own "spins", it should work out-of-the-box and they're all broken. You could enable the module on those spins, or remove PA from those spins, as Fenzi suggested. Specifically, I'm requesting that the xkbbell work, as expected, and as it has for many many years. I don't care what type of solution is chosen. In fact, I, too, would be grateful to learn how the Fedora Project would like this problem solved so I could help. But, at this point, I don't know how.
xkbbell should work the same way as it always did. PA doesn't turn this off. And if you are not running a WM that hooks into xkbell, then you should get the old X11 piezo bell. I am really not sure why this bug is filed against PA. PA is not involved at all unless somebody uses metacity, in which case things work just fine. Reassigning to kde.
> module-x11-bell is not really a solution since it configures the event sound on > the server side, but the right place is the client so that it matches the sound > theme and so on. I will not enable module-x11-bell by default. Well, can we enable it in start-pulseaudio-kde maybe? (That said, I've found that module to be unreliable, sometimes it just loses the grab of the X11 bell events for some reason.) > And if you are not running a WM that hooks into xkbell, then you should get the > old X11 piezo bell. Except that we don't load the pcspkr module by default anymore in the kernel, and that some PCs don't have a piezo buzzer to begin with.
(In reply to comment #25) > > module-x11-bell is not really a solution since it configures the event sound on > > the server side, but the right place is the client so that it matches the sound > > theme and so on. I will not enable module-x11-bell by default. > > Well, can we enable it in start-pulseaudio-kde maybe? No please don't. Fix this properly. BTW, would be cool anyway if KDE would adopt the event theme logic one of those days...
I rand this down on the XFCE development list and here was the reply I received: "this needs to be addressed in the toolkit, not the desktop." I'm not certain, but I think "tookit" mean the Gnome toolkit, GTK2, right? Perhaps we should reassign this bug to that group? I think the XFCE folks are implying that it's gtk that handles the xkbbell event.
Applies to Fedora 14, too.
Applies to Fedora 15, also. (Fresh install of Xfce spin.) Again, I'd like to help, but not sure how. All I can think to do is to keep updating the Fedora version affected so this issue doesn't just disappear. If someone could confirm that Gtk2 is the "correct" or at least the best place to address this behavior, then perhaps we can assign it to that component? Does that seem like a good idea? Or, maybe I should install Rawhide and confirm it there. Think this issue might gain some traction if it were against rawhide?
Okay, I think I have confirmed this problem in rawhide. I installed the nightly build and installed the rawhide repository.
*** Bug 720186 has been marked as a duplicate of this bug. ***
I just wanted to thank Matej for giving this bug his attention. Thanks much. Please let me know if I can help. Also, if anyone else is trying, the workaround described by Keven Fenzi (in <a href=#c30>Comment 15</a> ) is no longer working (since F15), for me, at least. The workaround involved configuring pulseaudio to honor the XBell event via a couple new lines in /etc/pulse/default.pa. If anyone finds a new one, please post.
Here's another case where the bell doesn't work. I have a vnc session (server) running on a remote suse 10.1 machine. When I connect to it from a redhat enterprise 3 machine using tightvnc 1.2.9 under gnome 2.2.2 bells (such as those from vi) from the remote machine are correctly sounded at the viewer end. Using tigervnc 1.0.90 or tightvnc 1.3.10 on fedora 14 (gnome 2.31.4) the bell is not sounded. However, the bell does sound using the gnome vinagre Remote Desktop Viewer. Looking at the sources for tigervnc and vinagre I believe that vinagre uses a gtk routine to handle BELL, whereas tigervnc is using the XLib function XBell.
I came across the same issue using the i3 window manager. The pulseaudio "load-module module-x11-bell" fix worked fine for me on F15. Rather than editing the system-wide /etc/pulse/default.pa I added pactl calls to my ~/.i3/config: exec pactl upload-sample /usr/share/sounds/gnome/default/alerts/glass.ogg bell exec pactl load-module module-x11-bell sample=bell
Thanks for encouraging me to try again. I didn't catch the relationship between the names and the module sample= option. It works again! I think something must have changed in PA, though, since I think I tried the same default.pa configuration that worked in F14 and it didn't work in F15. But, regardless, having in my session (wm config) is definitely better and I'm relieved to have the bell back. I genuinely hope everyone can be satisfied with whatever solution is finally implemented. P.S. i3 sounds nice. But, tiling hurts my head. Yet, it's so nerdy, lightweight, and cli, it calls to me.
Thanks guys, I solve my 'no bell' issue with Paul Egan's tips in comment 34! I have used Fedora for a while(F10 up to F16) and for long I have this issue (terminal echo -e "\a" gives no sound while all setting seems ok). Even under gnome there is no sound, but that's maybe because I disable the login sound. Now I prefer fvwm so I think I'll just add similar lines into my fvwm config file (~/.fvwm/config). I test in the console (Ctrl+Alt+F2) and find no sound there. Is that a different issue? How can that be fixed?
(In reply to comment #23) > I wish I knew. I've been trying to figure out how to handle this for months. > > When I reported this to the Xfce team, they said they were passing beeps to > pulseaudio, which was supposed to handle beeps. It seems likely the other > desktops are doing the same. So, if any non-metacity desktops are going to > work then something has to be done with PA. I *guess* that's what is > expected. You don't have to enable that module on the "Desktop Edition." But > now that Xfce and LXDE and all the other desktops have their own "spins", it > should work out-of-the-box and they're all broken. You could enable the module > on those spins, or remove PA from those spins, as Fenzi suggested. > > Specifically, I'm requesting that the xkbbell work, as expected, and as it has > for many many years. I don't care what type of solution is chosen. In fact, > I, too, would be grateful to learn how the Fedora Project would like this > problem solved so I could help. But, at this point, I don't know how. Of course -- Xterm is also affected! They simply use X, which then talks to the X server, which needs to "render" the sound. PulseAudio can do it, but doesn't because it wants to be a ???. The ??? is because here is the mismatch. The X server renders Graphics and a Bell. The Bell should be an audio source, PulseAudio SHOULD take it, and handle it just like any other "client". Except that it decides what it sounds like. In fact, all of my (remote) applications really have only one Audio need -- X bell. I really don't understand why PulseAudio is refusing to change this. I am one of the users affected as well. There may be some use case where this doesn't work (apparently, something having to do with "sharing" PulseAudio, from the comments in default.pa). I have never had the urge to "share" PulseAudio. But, any application that is terminal based, AND all older X applications are affected by this. Hell, it's NOT "Gnome", or "KDE" -- TWM is affected! Please make the default in PulseAudio render X bells by default! Add an option to the GUI configurator to disable this (allow "sharing") for the other use case, if needed.
(In reply to comment #37) > Please make the default in PulseAudio render X bells by default! Add an > option to the GUI configurator to disable this (allow "sharing") for the > other use case, if needed. X would need to become a pulse client to do this. Which pulse instance should it connect to? There's not a system pulse instance. The session instance is not defined until after the X server is running, and may never be created at all.
PulseAudio should listen to X bell events, not the other way round. In fact, it can already do this, the feature is just not enabled by default.
(In reply to comment #39) > PulseAudio should listen to X bell events, not the other way round. In fact, > it can already do this, the feature is just not enabled by default. Then this is a pulseaudio bug. Reassigning.
It is no good reassigning to pulseaudio when xkbbell does not generate an X11 bell event. That is bug 720186 which was wrongly closed as duplicate of this bug. Changing pulseaudio to listen to bell events is entirely unhelpful when no bell events are generated in the first place. This is with Fedora 17. Also, letting pulseaudio handle the issue also just means that it will rot forever, since: "PA doesn't do any xkb bell magic by default. That's intended. If you want to hookup xkb bell with proper audio then use a window manager that is able to forward xkb bell events to libcanberra or suchlike, the way metacity does it." But that is a theoretical problem, since there is not xkb bell in the first place.
Ah, the plot thickens. So, this is a detail that I did not understand before. Could you elaborate? I don't know the difference between xkb bell and X11 bell. This may be significant as I only reported xkb bell here *because* I thought it was the same bell as all the applications I'm using (e.g. xterm & terminal emulators) which produce "bell" events but are silent in F17 & F18 w/o Gnome Desktop. If they are not the same, it is possible I have reported a different bug than the one I intended to report.
xkbbell and the terminal emulators should produce the same event. As far as I can tell, neither produce any event at all in Fedora 17. Once that is fixed there is the second problem of getting the event to actually produce a sound. Getting that working locally is just a matter of a few lines in /etc/pulse/default.pa, so the second problem does not worry me.
It doesn't really make sense to assign this bug to xfdesktop because it also affects all the other non-GNOME desktops. IMHO, this should really be handled in PulseAudio. PulseAudio has a new upstream maintainer these days, who's coming from the KDE camp, have you tried talking to him about this?
PulseAudio cannot fix this bug. There are no x11 bell events generated that PulseAudio or anything else can react to. It is therefore not helpful to assign the bug to PulseAudio. The bug affects Gnome as well. If any Fedora 17 configuration is exempt from the bug, I'd like to hear about it.
> PulseAudio cannot fix this bug. There are no x11 bell events generated that > PulseAudio or anything else can react to. That is the separate bug #720186 which I just reopened. > It is therefore not helpful to assign the bug to PulseAudio. See above, but in any case, xfdesktop makes even less sense to assign it to.
I'm marking this bug as depending on bug #720186 because there's clearly no way to fix this (in a user-visible way) without fixing bug #720186 first.
Kevin Kofler, I certainly understand your sensibility; this is a bigger problem than just for XFCE users. But, this will never be solved by PA, so that's that. Comment 22 sort of explains everything. PA folks are saying that any desktop that wants to fix this problem will need to listen for and forward bell events to PA. (This isn't a horrible idea, actually; it gives the desktop the opportunity to customize the sounds according to it's own scheme, which is a pretty standard.) Now, it would be great if there was some way to do that once and fix all the desktops at the same time. If you know the name of that component, please reassign this bug to it. But, if such a grand solution existed, I'm sure this bug would have been fixed a long time ago. It seems pretty clear that each desktop will need to implement it's own solution. And, since my concern is getting XFCE fixed, I don't know where else to assign it. Moreover, if no other component is willing to accept this bug and fix it on behalf of the XFCE desktop, then what else is there to do? Sincerely, Paul
It's there where I vehemently disagree: XBell is a core system functionality, it does not make sense for every desktop to reimplement it independently. And your original bug report was about both Xfce and KDE, so assigning it to just xfdesktop is not going to help, without a clone against kde-workspace or something. As I said, talk to PulseAudio upstream about this issue. (Have you tried filing it at bugs.freedesktop.org?) The current upstream maintainer appears to be Arun Raghavan. You may also want to talk to Colin Guthrie, who worked on PulseAudio integration for KDE and later became the PulseAudio maintainer (which he had been for a while). I hope upstream will find a solution which works for everyone, not just for GNOME. If they really think the desktops are responsible for this, then they need to file RFEs in the upstream KDE and Xfce bug trackers.
Again, I cannot disagree with your perspective. XBell is clearly core and should not have been dumped so thoughtlessly, carelessly. But that was back in F11! If you (and I!) where in the majority, I don't think this bug would still exist. This is the *fourth* time the PA folks have commended on this issue, which I have reported in other tracking systems. I think what I'm trying to say is that the decision has already been made, according to the PA folks. I think they would have mentioned it if some other universal solution existed. I will try duplicating this bug upstream at freedesktop.org as you suggest.
Yes, filing upstream bugs is the way forward. I think doing this at distro level is not going to get anywhere, even more so if (as Lennart seems to think) desktops should implement this, because the feature is just not there in the desktops, so this would need to be implemented upstream by the desktops. (PulseAudio, on the other hand, already supports it, it would just have to be enabled. But Lennart is not going to do that in a Fedora patch for sure.)
Hmm...remember, PA does *not* support this. PA folks have stated that the PA-based "solution" mentioned here, in comments, is an unsupported work-around. The new bug is: https://bugs.freedesktop.org/show_bug.cgi?id=58930
I meant to file the bugs.freedesktop.org bug against PulseAudio of course! The desktop entry spec has absolutely nothing to do with this issue, it makes no sense whatsoever to assign the bug to that component. As for: > Hmm...remember, PA does *not* support this. we're choking on the ambiguity of the term "support" there. I mean PA supports this feature as in it's actually implemented in the code, unlike the alternative solution Lennart wants. It really sucks that the feature is not getting enabled due to reasons I consider purely political.
So, for those of us a bit less learned about the underpinnings of bell event propagation, where are we at? I see the work-around involving pulseAudio, and that would pick up my xterm bell events. But it doesn't catch things like whatever xbiff is doing. I recently upgraded from Fedora 16, where this was working, to Fedora 17, where it very much isn't. I can produce beeps via xkbbell (only) if I run with -force, and via beep (only) if I run as root. The pcspkr module is, of course, loaded. I'm using Fvwm as my window manager, and I use things like xbiff to notify. And I really don't want to use the pulseAudio workaround, even if xbiff worked with it, because what I like was the beep was via the pc speaker, rather than the installed sound card. (So, unless you can recreate that behaviour via pulseAudio, it's not what I was desperately hoping for.) Are there any options/work-arounds available for what I wanted? Frustrating to have a change in this sort of functionality post-upgrade with no way to re-configure similar behaviour using other means. Thanks for any guidance you can provide.
I have no idea if this will help anyone else involved in this ticket, but Peter Hutterer <peter.hutterer> posted a response to similar (?) bug (848895) which pointed me in the right direction. In going from F16 to F17 the default for audible bell changed and I had to run the (new?) command xkbset to see that. So running "xkbset b" in my .xsession restored the desired operation for me. Not sure if that helps anyone else, but thought I would cross-post here just in case. Also lets me thank Peter again. ;)
Hi Adam, To answer your first question: We're trying to get some traction with the freedesktop.org folks As you can see, this bug has lasted many years and many versions of Fedora; it's much older than F16. I've never been concerned with the PC speaker, per se. And, I've never had to touch xkbset, either in pursuing the various workarounds for this problem. So, while I don't understand the bell event, either, I don't think your problem is the same as this bug. Although, it may certainly be related. ...I've read you bug...interesting. I tried playing with 'xkbset b' and it had no effect with or without pulseaudio nor with or without the current PA workaround (comment 15). So, I think you are specifically after the PC Speaker beep, right? So, to be clear, I opened this bug for *any* representation of the bell event. I would have been satisfied with any output. But, I think this bug is now specifically for "audio enhanced" bell event servicing. I have to say, though, it is shocking that the PC Speaker beep has worked more reliably than using the audio system in the modern era with respect to this issue. Although, perhaps it makes more sense because the bell event was originally serviced by the PC Speaker.
So, this is clearly still stuck. Suppose I want to add a workaround to openbox -- what event should I be looking for, and what should I do if/when I see it? Also, do I have to _dis_able the pulseaudio workaround to enable openbox to see the event at all? Thanks
This message is a reminder that Fedora 18 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 18. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '18'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 18's end of life. Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 18 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 18's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Definitely affects F19. I assume F20, also, but I'll be honest and wait to test.
F20 also
F21. Also, workaround developed long ago from this thread (loading sample to pa after X11 session is started) has stopped working. Just starting to look into it, now.
(In reply to Paul DeStefano from comment #61) > Also, workaround developed long ago from this thread (loading sample to pa > after X11 session is started) has stopped working. I can't remember all the bits, now, but I was able to restore the workaround. I think it had to do with PA auto-start changes in PA 6. But, they go resolved.
This message is a reminder that Fedora 21 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 21. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '21'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 21 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Oh bother. This has clearly been a rawhide issue for a long time, but I haven't had time to install rawhide to verify.
I am on f22 and it seems both XBell and XkbBell (used by xkbbell tool) X calls seems to work for me. What I did: # modprobe pcspkr And unmuted "beep" channel in alsamixer.
Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.