The file: /etc/modprobe.d/blacklist-mga (from module-init-tools) contains a blacklisting for pcspkr. This is, imho, a mistake. Here's why: 1. Choice of whether or not to use the pcspkr should be done in userspace, per user, rather than at the kernel level. For example, KDE has a GUI for the "System Bell", or one can use "xset -b". Both of these tools are broken at the moment, and it is not necessarily obvious why. 2. The pc bell is actually extremely helpful, for example: * At the console (VT1 etc), there is no X, so the Alsa/Pulse/Gnome/KDE notifications playing mp3 files etc simply don't work. * I can't be the only one who leaves the computer connected to the amplifier, with the volume quite high (for music playback). Hitting [Tab] shouldn't cause a very very loud amplified beep, especially with headphones. * Irrespective of other volume controls, the pc beeper is always available, it is relatively quiet, and it responds instantly (the ~1/4 second delay at the shell with software sounds is quite jarring). 3. For those who still hate the beeper, may I suggest a way to learn to love it: * Ensure that inputrc contains "set show-all-if-ambiguous on" * Make the beep very short (I have 50% volume, 400 Hz, 100ms).
CC: (none) => stormiSummary: pcspkr broken (wrongly blacklisted module) => Please do not blacklist the pcspkr module
Bug assigned to the package maintainer.
Version: 1 => CauldronAssignee: bugsquad => thierry.vignaudSource RPM: (none) => module-init-tools
AFAIK it was blacklisted at Mandriva times and the reason was that not all DEs were able to mute it. And on some laptops the pc speaker is so loud that it's a real pain to have. If you need it you can always remove it from blacklist but i still think that it should be blacklisted by default. There are a lot more people who don't want to know about it then there are people who do.
CC: (none) => sander.lepik
(In reply to comment #2) > AFAIK it was blacklisted at Mandriva times and the reason was that not all DEs > were able to mute it. And on some laptops the pc speaker is so loud that it's a > real pain to have. I disagreed with the Mandriva decision to blacklist it and I still do. If certain software does not work correctly then bugs should be filed against that software, rather than crippling a feature for all DE's and users. > If you need it you can always remove it from blacklist but i still think that > it should be blacklisted by default. There are a lot more people who don't want > to know about it then there are people who do. Yes *you* can remove the blacklist, but as the OP points out the reason for the feature being crippled is not obvious and tools designed to control it appear to be broken. I would vote for this to be removed and encourage bugs to be filed by anyone who cannot control the beep to their satisfaction.
CC: (none) => zen25000
Pinging, because nothing has happened with this report for more than 3 months, it still has the status NEW or REOPENED.
CC: (none) => marja11
That's probably because nobody wants it "fixed" :-)
CC: (none) => ftg
(In reply to comment #5) > That's probably because nobody wants it "fixed" :-) RESOLVED-WONTFIX is a solution, too, of course
It seems to me that modules should only be blacklisted if they are considered unstable, or if an alternative driver is preferred. I think it's technically inelegant to decide on this policy in the kernel modules, rather than leaving it to the individual logged-in user, especially on a multi-user system. Also, the current approach is not easily discoverable, and it now leaves the user rather puzzled: the GUI to actually enable the bell doesn't work!
Please disable the PC-SPEAKER! In my laptop it's so laud, that even connecting headphones and having them on the table is painful! Please add default values: In /etc/profile setterm -blength 0 In /etc/inputrc set bell-style none If we disabled it by default remving the module, please also mute it for those who have the speaker through sound card.
CC: (none) => n54
This is clearly more contentious than I thought. But at the same at the same time, we need to support choice, and work properly in a multi-user system - and we need to make sure that the GUI options actually work! It seems to me that the way forward is to leave the hardware enabled properly (load the module) and not do too much magic with /etc/profile But at the same time: -disable the bell with the gnome-terminal GUI -disable the bell with the KDE konsole GUI -optionally, disable it in the user's ~/.inputrc (via /etc/skel). That seems to me to be the best compromise: the functionality still exists for those who actually really need it, and the control features actually work properly. (It also avoids ugly undocumented hacks.) Incidentally, the reason I personally *want* the pcspkr to work is that, on my desktop, I have my soundcard connected to an amplifier (which usually plays music), whereas the system bell is a tiny piezo speaker on the motherboard. So I get a quiet "bip" coming from the PC iself when there is a tab-completion error, and I avoid konsole playing a very very loud "system notification" through my hi-fi speakers!
If it's possible to load the module and still have the speaker disabled, then we should probably do that, as well as provide a GUI way to enable and disable it. But I would strongly argue against having it enabled by default, as that is only going to result in a flood of "change-of-behavior" complaints from all the people who wanted it blacklisted in the first place. In the years since it was blacklisted, I can't remember anyone complaining that it didn't work, so I think those who want it are in the clear minority. They should be able to enable it easily if they want it, but it shouldn't be the default.
(In reply to comment #9) > Incidentally, the reason I personally *want* the pcspkr to work is that, on my > desktop, I have my soundcard connected to an amplifier (which usually plays > music), whereas the system bell is a tiny piezo speaker on the motherboard. So > I get a quiet "bip" coming from the PC iself when there is a tab-completion > error, and I avoid konsole playing a very very loud "system notification" > through my hi-fi speakers! Yes exactly. There seems to be some confusion between the sounder (on the mother board) and the sound system in this thread.
(In reply to comment #10) > In the years since it was blacklisted, I can't remember anyone complaining that > it didn't work, so I think those who want it are in the clear minority. Well I have for one ;) But we should still cater for the minority - I'm sure most office users don't have a sound system connected and prefer to use the sounder. > They should be able to enable it easily if they want it, but it shouldn't be the > default. Yes exactly, but not your way. That would mean it's disabled for all users. This should be configurable from the desktop through normal GUI tools. If they don't work then they need fixing. Your suggestion is comparable to making seat position adjustment in a car only to be done by a mechanic. My 2 cents
> But we should still cater for the minority - I'm sure most office users don't > have a sound system connected and prefer to use the sounder. > > > They should be able to enable it easily if they want it, but it shouldn't be the > > default. > > Yes exactly, but not your way. That would mean it's disabled for all users. > > This should be configurable from the desktop through normal GUI tools. If they > don't work then they need fixing. > > Your suggestion is comparable to making seat position adjustment in a car only > to be done by a mechanic. I think you're mixing up the comment authors... My suggestion in comment 10 was exactly to not make it the default but make it configurable via the GUI, although I would prefer MCC rather than individual DE GUIs.
(In reply to comment #13) > I think you're mixing up the comment authors... > > My suggestion in comment 10 was exactly to not make it the default but make it > configurable via the GUI, although I would prefer MCC rather than individual DE > GUIs. Sorry - no I just misinterpreted your intention.
> My suggestion in comment 10 was exactly to not make it the default but make it > configurable via the GUI, although I would prefer MCC rather than individual DE > GUIs. The reason for using the individual DE GUI is that the system bell is a property of the terminal application (konsole, gnome-terminal, xterm, rxvt etc) rather than a global. And at the moment, there are already GUIs in the terminal applications - which are currently broken: if I choose to enable the terminal bell in gnome-terminal, the GUI doesn't do what it says - because it's broken "upstream" in a non-user-visible manner. [Given the number of ways of setting the terminal bell, it might be worth MCC just listing all of them, so that the user can toggle all of the approximately 7 different switches that control one feature!] Incidentally, to avoid confusion: Most desktop machines have a physical piezo beeper on the motherboard controlled by pcspkr driver. Most laptops don't have the physical beeper, but route it through the soundcard. We all agree that the pcspkr beep should be much quieter than the main music/video. Unfortunately, the configuration which is optimal for desktops is pessimal for laptops - and vice-versa!
I'm for a new service to control it globally, in tty, console, Gnome, KDE, everywhere. And then to make it in a better way then just disabling a module. Regards.
Hi, This bug was filed against cauldron, but we do not have cauldron at the moment. Please report whether this bug is still valid for Mageia 2. Thanks :) Cheers, marja
Keywords: (none) => NEEDINFO
Yes, this is still present in Mageia 2. But this one is creating far more heat than light. I think it would be better for all concerned to have a wiki page (or release note) describing how to configure the pcspkr to taste.(*) The problem is that there is one boolean property "is pcspkr used or not" that is controlled by about 7 different switches (and where different people have differing views about the default states of those switches). (*)The particularly cursed configurations seem to be: - certain laptops with pulseaudio, which beep very very loudly through headphones - gnome terminal, which is resolutely mute, and nearly impossible to beep.
Keywords: NEEDINFO => (none)
Please look at the bottom of this mail to see whether you're the assignee of this bug, if you don't already know whether you are. If you're the assignee: We'd like to know for sure whether this bug was assigned correctly. Please change status to ASSIGNED if it is, or put OK on the whiteboard instead. If you don't have a clue and don't see a way to find out, then please put NEEDHELP on the whiteboard. Please assign back to Bug Squad or to the correct person to solve this bug if we were wrong to assign it to you, and explain why. Thanks :) **************************** @ the reporter and persons in the cc of this bug: If you have any new information that wasn't given before (like this bug being valid for another version of Mageia, too, or it being solved) please tell us. @ the reporter of this bug If you didn't reply yet to a request for more information, please do so within two weeks from now. Thanks all :-D
Severity: normal => enhancement