Bug 14234
Summary: | The PC speaker console beep no longer happens | ||
---|---|---|---|
Product: | Drivers | Reporter: | Allan Duncan (spam_swamp) |
Component: | Console/Framebuffers | Assignee: | James Simmons (jsimmons) |
Status: | CLOSED CODE_FIX | ||
Severity: | normal | CC: | florian, rjw |
Priority: | P1 | ||
Hardware: | All | ||
OS: | Linux | ||
Kernel Version: | 2.6.30 2.6.30.6 2.6.31 | Subsystem: | |
Regression: | Yes | Bisected commit-id: | |
Bug Depends on: | |||
Bug Blocks: | 13070 |
Description
Allan Duncan
2009-09-26 13:02:42 UTC
Additional: This happened on an x86_64, whereas running 2.6.30 on an Athlon K7 doesn't trigger the bug. When time permits I will create a 32bit install on the Phenom mboard. Have you noticed this problem still? I just tried 2.6.33-rc8 on x86_64 and at least at run level 3 the beep is back. At this instant, due to a lack of mouse and keyboard input to X with this kernel, I can't confirm that it works with level 5, but since it appears to use drivers/char/vt.c for terminal emulation I presume so. Looking at the diffs 2.6.29 to 2.6.30 there didn't seem to be any change of consequence, but I did notice that there exists flags SND_BELL and SND_TONE that feature in drivers/input/misc/pcspkr.c and drivers/char/keyboard.c, but I was unable to find where these are actually set. Changing that setting is all that is needed to create the behaviour I see. I will dig further as time permits, but if the beep is back, I'm less motivated. How to alter this low level behaviour needs to be up front though, there are good arguments for the user to choose the applicable expression of ^G. I'm closing this as fixed then. |