Hardware volume button will maximize or mute completly instead of small steps in volume

[plindeman]

When pressing the volume up button on my HP notebook (zv6000) the volume goes up completely and the OSD will remain on the screen. when I press volume down it will complety going to mute.

This all happening on Intrepid beta with kernel 2.6.27-4-generic

Description: Ubuntu intrepid (development branch)
Release: 8.10

When these keys have been used I need to close X with Ctrl-Alt-Backspace otherwise an application won't get any keyboard input anymore.

If more info is needed plz let me know.
Peter

[Bryan Quigley (bryanquigley)]

This sounds like it might be a duplicate of https://bugs.launchpad.net/ubuntu/+source/gnome-power-manager/+bug/285323

Try killing gnome-power-manager and see if it solves the problem.

[plindeman (peter-lindeman-nl)]

I killed gnome-power-manager but it does not change the problem. After killing gnome-power-manager the same problem still occurs. I noticed that I can use the keyboard in X again when I have switch with Alt-F1 to a terminal session and then switch back with Alt-F7

[Bryan Quigley (bryanquigley)]

Do the menus still open, once the bug has been triggered?

[plindeman (peter-lindeman-nl)]

Do you mean the menu's of Gnome? No I can click on them and it seems as that they are pushed in but that's the only response.
After switching to terminal and back to X I can use the menu's (and the rest of the system) again.

[Lolo67 (girolamo67)]

I am having the same problem on my HP pavilion laptop (zv6000), I am running Intrepid 8.10 kernal 2.6.27-7.15

[Lolo67 (girolamo67)]

The volume applet on gnome on top panel works, and that is what I know use to control volume.
The volume buttons on laptop did work fine on Hardy 8.04.
I tried changing keyboard layout but nothing changed.

[ktemkin (kyle-ktemkin)]

This isn't a duplicate of the gnome power manager bug.

The issue is that on certain systems' PS/2 keyboards, the volume control keys (and certain media keys) report a KEY_DOWN when they're pressed, but not a KEY_UP when they're released. The result of this is that the system acts like they're stuck- and repeats them indefinitely, preventing use of the keyboard and/or mouse.

Why don't we implement the same solution that was implemented in the old Xorg KBD drivers?

That is, add to the PostKbdEvent() function in evdev.c something along the lines of:

    /* fix events for volume keys */
    if(ev->code == KEY_VOLUMEDOWN || ev->code == KEY_VOLUMEUP)
    {
 //post a keydown and then a keyup, as media keys have no automatic key-up
 xf86PostKeyboardEvent(pInfo->dev, code, 1);
 xf86PostKeyboardEvent(pInfo->dev, code, 0);
 return;
    }

?

(I posted information about a temporary 'fix' here: http://ubuntuforums.org/showthread.php?t=974723)

[Lolo67 (girolamo67)]

Thank you ktemkin, your temporary fix works great, I used method 1..

this is the fix link on ubuntu forums http://ubuntuforums.org/showthread.php?t=974723

[jetdog (slicksterdave)]

Marked bug as non-duplicate.

It has come to my attention that there is a flood of keyboard volume button/wheel =hardware= quirks that have never been dealt with, all having the same general problems.

To keep a long story short, there is a fair chance (though not guaranteed) that this is a kernel input driver bug/quirk for your volume control input device. (and even if not, the following will help determine what is wrong)

What I need the bug submitter to do (if not already), is to provide a model number for their laptop/desktop (or if custom-built, provide the model number of your: keyboard or multimedia device with the volume control realted to this bug)

- and if you could please, put that model number in the summery with something like this:
"Toshiba Satellite U300 volume button repeating forever"

If we can keep these volume control bugs pertaining to the __system/hardware in question__, it will help the maintainers a lot more.

Althought I can't guarantee/guess immediately what is going on here, what I will suggest is:

Provide some logs of the following:
(If you get some logs that run forever, please cut them short)

# echo "dmidecode > mydmilog.txt" | sudo bash

# echo "showkey -s > mykeylog.txt" | sudo bash
(use your volume up, volume down, volume up, and then volume down)

# echo "xev > myxevlog.txt" | sudo bash
(use your volume up, volume down, volume up, and then volume down)

This will greatly assist the maintainers in understanding and dealing with your bug.

Hopefully this helps speed these problems along :)

[jetdog (slicksterdave)]

****Note to kernel-maintainer/debugger: there is a keyboard-quirk fix in the official kernel source already for the dv6100 volume repeat quirk , and it seems some whoever was dealing with that submission forgot to include the dmi/bios information for the dv6000.

Reference: drivers/input/keyboard/atkbd.c , look for "dv6100"

****

[jetdog (slicksterdave)]

Please refer to bug #311353 . I have filed this bug as a duplicated of the latter.

[MacRules (macrules)]

More info here:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/271706
That seems to be the first en most broadly discussed one.
in my case I can see no key-release event is given for the FN + sound keys (sudo showkey) , so remapping the sound keys helped me, but it sucks.
Hope they find a fix!

[Dr. Amr Osman (dr3mro)]

aq fix will land in a few minutes at
https://launchpad.net/~dr3mro/+archive/xserver-xorg-input-evdev