Red Hat Bugzilla – Bug 203213
"xset b 10" changes duration instead of volume
Last modified: 2009-07-14 12:47:43 EDT
Description of problem:
When "xset b N" is executed, the volume of the beep is not changed.
Instead, the duration is changed. However... if "xset b 10 400 N"
is executed, again the duration is changed. So, they are not swapped.
Only the first argument is interpreted wrongly.
Version-Release number of selected component (if applicable):
100% (on my hardware)
Steps to Reproduce:
1. Run "xset b 10"
2. Open shell and hit "backspace" on empty line
Duration is 10ms
Setting the volume to zero removes the beep and its starting click.
It seems that the old code works like this:
((1193190 / pitch) & 0xffff) |
(((unsigned long)duration *
loudness / 50) << 16));
But the kernel side is like this:
unsigned int ticks, count;
* Generate the tone for the appropriate number of ticks.
* If the time is zero, turn off sound ourselves.
ticks = HZ * ((arg >> 16) & 0xffff) / 1000;
count = ticks ? (arg & 0xffff) : 0;
count = CLOCK_TICK_RATE / count;
In other words, it ignores the volume altogether. So, when X tries to vary
the volume, the amount gets into the duration field.
I am not familiar with the history of this ioctl, but by the looks of it,
X may be in the wrong.
Another thing, here's an amusing commit message:
>>> quote begin
hw/xfree86/os-support/linux/lnx_kbd.c | 530 --------------
Author: Daniel Stone <daniel at fooishbar.org>
Date: Sat Aug 12 18:56:05 2006 +0300
completely remove OS keyboard layer
Completely axe the keyboard layer from os-support.
>>> quote end
Well, amputation is a sure way to take care of ingrown toenail.
When are we going to package it? My rawhide still uses the KDMKTONE:
bell percent: 20 bell pitch: 400 bell duration: 100
ioctl(4, KDMKTONE, 0x280ba6) = 0
bell percent: 10 bell pitch: 400 bell duration: 100
ioctl(4, KDMKTONE, 0x140ba6) = 0
This is with:
Based on the date this bug was created, it appears to have been reported
against rawhide during the development of a Fedora release that is no
longer maintained. In order to refocus our efforts as a project we are
flagging all of the open bugs for releases which are no longer
maintained. If this bug remains in NEEDINFO thirty (30) days from now,
we will automatically close it.
If you can reproduce this bug in a maintained Fedora version (7, 8, or
rawhide), please change this bug to the respective version and change
the status to ASSIGNED. (If you're unable to change the bug's version
or status, add a comment to the bug and someone will change it for you.)
Thanks for your help, and we apologize again that we haven't handled
these issues to this point.
The process we're following is outlined here:
We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.
Now the beep went silent (tested with bash and vim inside gnome-terminal).
Works on the Linux console. Also, default xset b is 40 400 100. Changing
to volume to 100 does nothing. Time to redefine the bug as "no beep in X"?
I remember that I had to edit /etc/gdm/custom.conf because of the beep
just a few weeks ago, so it looks like we keep changing this area.
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9. 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 '9'.
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 9's end of life.
Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 9 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 please change the 'version' of this
bug to the applicable version. If you are unable to change the version,
please add a comment here and someone will do it for you.
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.
The process we are following is described here:
Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 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.
Thank you for reporting this bug and we are sorry it could not be fixed.