GNOME Bugzilla – Bug 389996
Improve Vol up+down in media keys window
Last modified: 2007-02-14 17:25:40 UTC
I got a new cherry keyboard some days ago and tried to assign some special keys using the keyboard shortcuts window. I have two keys, "+" and "-" and I assigned them to do volume up and down. This works fine but I have to press multiple times because teh volume slider only moves one "step" per press. For example when I have set volume to 100%, to go to aprox. 50% I have to tab "-" around 6 times. To move it back to 100% I even have to tab "+" more than that, around 15 times. What I would like to have is that I can press "-" and hold it, and have the slider slowly move all the way to 0% as long as I hold the key. For this naturally the slider would have to move not in streps of 10% or what it does now, but 1% steps or something similar. I tested this with both the old gtk widget as well as the very new composite one, both work the same and should be altered the same way.
1) I'm not sure setting the value to 1% is a good default. I prefer the larger steps the slider uses now. 2) You can adjust the step in gconf if you like (/apps/gnome_settings_daemon/volume_step). Not sure if this really needs to be exposed. 3) The asymmetry between vol-up and vol-down should certainly be fixed. I'll try to come up with a patch.
Thanks for answering! First, I found that the first problem I reported was due to me using the new keyboard in USB mode. If I use the PS/2 adapter it works well, meaning it uses key-repeat. I didn't know about the gconf key but that's cool with me. I tried 1% and its really to small but perhaps 2% would be ok for me (keep the default, I can set it myself now) BUT: when I set it to less than 5% the "volume up" key does not work anymore! Setting it to 6% makes it work again. Even with these small settings the "vol down" key works. Also I noticed that sometimes after the slider reaches a special value (looks like about 5%) the slider gets stuck and the speaker gets unmuted. I have to use the slider in the software mixer to make the keyboard keys work again...
(In reply to comment #2) > when I set it to less than 5% the "volume up" key does not > work anymore! Setting it to 6% makes it work again. Even with these small > settings the "vol down" key works. That's basically the asymmetry issue as well which is caused by converting between ints and floats internally. > Also I noticed that sometimes after the > slider reaches a special value (looks like about 5%) the slider gets stuck and > the speaker gets unmuted. I have to use the slider in the software mixer to > make the keyboard keys work again... Recipe to reproduce?
Still don't know where exactly the problem is but if I press "down" all the way down to 0% and then tip up/down/up/... a few times it happens. In this case both the media keys window as well as the gnome mixer applet (set to muted!) will show a volume bigger than 0%, while gnome mixer and alsamixer show that it is in fact 0%. Really, really strange...
Does that also happen if you set a larger step size? I suspect this could be the rounding issue as well (which looks pretty hard to solve, fwiw).
I've just reproduced it using step size == 20 but it seems to be harder with bigger step sizes.
Created attachment 81795 [details] [review] vol- + vol+ = vol= Here's a patch that fixes the asymmetry for me (against current SVN trunk). Does it help you, too? I haven't been able to hit the other problem you have.
This does not work for me: I set volume to 100% and volume_step to 5. Now pressing vol- I get: 94, 90, 84, 77, 71, 65... Same with step=10: 100, 90, 81, 71, 61, 52... But: pressing up gives the same values again, meaning it's now decreasing/increasing at the same rate.
It's impossible to make it stick to the exact step size. The abstraction layer works with a volume from 0 - 100 (%), while gstreamer works with integer ranges it gets from the hardware (or maybe ALSA; for my card, I think it was 15 - 69 or something). So, as far as I am concerned, the patch did work for you. ;-)
Ok "works" for volume_step > 2. For volume_step == 1: no movement For volume_step == 1: movement stops somewhere (eg lets me control between 77 and 65
Yeah, same problem. If the mapping from percent to hardware range results in hardware steps < 1.0 you're stuck. Not much that can be done about it (except not setting such small step sizes). Bastien, any comments?
The patch looks good to me. Whether it doesn't work properly for anything but the default stepping value, given that the problem clearly is the lack of precision from the hardware/driver, isn't something we'd care too much about.
Committed.
*** Bug 161632 has been marked as a duplicate of this bug. ***
*** Bug 336783 has been marked as a duplicate of this bug. ***