Volume Up button locks screen

[Matt Hohmeister]

9.04 with Macally iMediakey keyboard [USB keyboard from 2002]

The "Volume Up" key is registered by Keyboard Shortcuts as "XF86ScreenSaver"--which, of course, is pretty much arbitrary.

Even though I've tied it to "Volume up" in Keyboard Shortcuts, hitting this key raises the volume by one--then locks the screen. According to Keyboard Shortcuts, the actual shortcut to lock the screen is Ctrl+Alt+L.

[machrider (machrider)]

I'm having the same problem. Ubuntu 9.04 with a Macally Icekey USB keyboard. This is new after upgrading from 8.04 -> 8.10 -> 9.04 last night. I've tried both the Generic keyboard layout (pc104 and pc105), as well as evdev-managed keyboard. I figured out the following:

1. In Jaunty, keycode 160 is my volume up key
2. It's original mapping was XF86ScreenSaver
3. I can change it: xmodmap -e "keycode 160 = XF86AudioRaiseVolume"
4. Then I end up in the same spot as Matt -- pressing the key causes the volume to go up AND locks the screen.

It seems like something in Gnome has attached to the XF86ScreenSaver key, and when the keysym for keycode 160 changed, it didn't update internally. Digging through all the configuration in gconf-editor, it doesn't appear that the screensaver key behavior is configurable.

(The "lock screen" keyboard shortcut is still set to the original value, <Ctrl><Alt>L. Changing or disabling that doesn't stop this from happening.)

My other three "special" keys, lower volume, mute, and eject, all work fine.

[Björn Schließmann (b-schliessmann)]

XF86ScreenSaver is grabbed by gnome-screensaver. Killing it caused my XF86ScreenSaver (Fn-F3) to go "dead", i.e. not lock the screen.

[Pedro Villavicencio (pedro)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. A new version of xkeyboard-config is available in both Lucid and Maverick and we are wondering if this is still reproducible in any of those versions, May you please test and give us of feedback about it? Thanks in advance.

[Bryce Harrington (bryce)]

We're closing this bug since it is has been some time with no response from the original reporter. However, if the issue still exists please feel free to reopen with the requested information. Also, if you could, please test against the latest development version of Ubuntu, since this confirms the bug is one we may be able to pass upstream for help.

[machrider (machrider)]

The "volume up key locks screen" behavior is still present for me in Lucid. My setup is described above.

[Tim Cuthbertson (gfxmonk)]

I also have this bug, also with a macalley IceKey. I reported it over here [ http://ubuntuforums.org/showthread.php?p=9946901&posted=1#post9946901 ] because I couldn't for the life of me figure out what package it should be assigned to, but my symptoms are identical.

I am running lucid, and there was a response yesterday that stated the issue is still present in maverick.

[Janusz (yorashtan2)]

Having this bug in Maverick and in Linux Mint 10.

[frazzmatazz (frazzmatazz)]

Same problem here. Using a Macally Icekey keyboard

The Volume up key on this keyboard produces "keycode 160 (keysym 0x1008ff2d, XF86ScreenSaver)" using xev. And it seems this "XF86ScreenSaver" is hard coded somewhere in X or gnome so you can't reallocate it using the usual gnome keyboard shortcuts program.

In my case though I've disabled gnome-screensaver, to use xscreensaver. So this key does nothing. And I also can't reallocate it to something else useful, like putting the volume up!

[Bryce Harrington (bryce)]

There isn't enough information provided in this bug report to be certain (p.s. use 'ubuntu-bug xorg' when reporting X bugs!) however this smells a lot like a kernel bug to me. I'm refiling as 'linux'.

I would suggest re-testing against the current development version (natty) and filing bugs via the above command, which will ensure the necessary debug data is collected.

[machrider (machrider)]

Bryce, there may be multiple bugs here, but the most important one (IMO) is that you can't remap this key's behavior in X. Agreed that identifying the volume up key as XF86ScreenSaver could be a product of keyboard driver strangeness. But it should always be possible to remap a key with xmodmap and have it perform a new function. However, remapping this keycode to a new keysym, while it appears to work via xev, does not actually stop the screensaver from running. Someone, somewhere in Xorg or Gnome has hard-coded this behavior to run the screensaver despite the new key mapping.

[frazzmatazz (frazzmatazz)]

I only came across this bug when I began using "evdev" instead of "kbd" for the keyboard.

Originally had this in xorg.conf, and it worked fine (though gnome's keyboard shortcut mapping program did sometimes allocate funky XF86*Action* names that didn't match the keyboard labels, remapping worked as expected):

Section "InputDevice"
        Identifier "Generic Keyboard"
        Driver "kbd"
        Option "CoreKeyboard"
        Option "XkbRules" "xorg"
        Option "XkbModel" "pc104"
        Option "XkbLayout" "us"
EndSection

Now running without xorg.conf and Xorg.0.log says this (among other similar repeats):

(II) config/udev: Adding input device Macally Peripherals Macally ICEKey keyboard (/dev/input/event6)
(**) Macally Peripherals Macally ICEKey keyboard: Applying InputClass "evdev keyboard catchall"
(**) Macally Peripherals Macally ICEKey keyboard: always reports core events
(**) Macally Peripherals Macally ICEKey keyboard: Device: "/dev/input/event6"
(II) Macally Peripherals Macally ICEKey keyboard: Found keys
(II) Macally Peripherals Macally ICEKey keyboard: Configuring as keyboard
(II) XINPUT: Adding extended input device "Macally Peripherals Macally ICEKey keyboard" (type: KEYBOARD)
(**) Option "xkb_rules" "evdev"
(**) Option "xkb_model" "pc104"
(**) Option "xkb_layout" "us"

And have the same problems as the others described above.

Might be a combination of XF86Screensaver being hardcoded somewhere in gnome, and the evdev keyboard driver being inflexible about key naming too. (sorry don't have a great grasp of the inner workings, not a programmer, just user)

[Jeremy Foshee (jeremyfoshee)]

Hi Matt,

Please be sure to confirm this issue exists with the latest development release of Ubuntu. ISO CD images are available from http://cdimage.ubuntu.com/daily/current/ . If the issue remains, please run the following command from a Terminal (Applications->Accessories->Terminal). It will automatically gather and attach updated debug information to this report.

apport-collect -p linux 377175

Also, if you could test the latest upstream kernel available that would be great. It will allow additional upstream developers to examine the issue. Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Once you've tested the upstream kernel, please remove the 'needs-upstream-testing' tag. This can be done by clicking on the yellow pencil icon next to the tag located at the bottom of the bug description and deleting the 'needs-upstream-testing' text. Please let us know your results.

Thanks in advance.

    [This is an automated message. Apologies if it has reached you inappropriately; please just reply to this message indicating so.]

[Sylvain RIVIER (sylvain-rivier-lyon)]

hello

I have the same issue than other poeple : no way to reassign XF86ScreenSaver.
The strange point is that one week ago, it seemed ok, and suddenly the screensaver is started, without conf change...

makes me crazy....

Thank your for the support

[Eduard Hasenleithner (eduard-hasenleithner)]

Launching "dbus-monitor --system" and pressing the button gives

signal sender=:1.12 -> dest=(null destination) serial=2054 path=/org/freedesktop/Hal/devices/platform_i8042_i8042_KBD_port_logicaldev_input; interface=org.freedesktop.Hal.Device; member=Condition
   string "ButtonPressed"
   string "coffee"

In gnome-screensaver/src/gs-listener-dbus.c there is a hard-coded(!) handler for the "coffee" button which instruct gnome-screensaver (i.e. itself) to lock the screen. Apparently, unrelated buttons are mapped by HAL to the "coffee" button. E.g. I have the problem with my Cherry CyMotion master linux keyboard, when I press the "Copy" key.

[Eduard Hasenleithner (eduard-hasenleithner)]

Further information: I use the Keyboard (Cherry CyMotion Master Linux) in PS/2 mode on a docking station of an HP notebook. In "/usr/share/hal/fdi/information/30-keymap-hp.fdi" the scancode of the copy key (e00a) is mapped to "screenlock". In the same directory, mappings for several other computer manufacturers are provided.

And since gnome-screensaver listens on "screenlock" (which is identical to "coffee"), the screensaver is started when the "copy" key is pressed. I use the same keyboard on a different computer (non-HP) and there the behavior is not observed, since the manufacturer string does not match in "30-keymap-hp.fdi" and the scancode (e00a) is not set.

This is not directly related to the Macally keyboard since it is connected by means of USB, but somehow on kernel level keycode 152 (KEY_COFFEE) is likely to be generated, which completely bypasses the X11 key handling.

[frazzmatazz (frazzmatazz)]

It seem to me the problem may be hard coding of "XF86Screensaver" key (which is volume up key on the Macally Icekey keyboard) in Gnome-screensaver.

The problem has gone away for me since I disabled gnome-screensaver (from memory couldn't remove it due to dependencies)
chmod -x /usr/bin/gnome-screensaver
chmod -x /usr/bin/gnome-screensaver-command
chmod -x /usr/bin/gnome-screensaver-preferences
And continued using Xscreensaver.

I can currently reassign the Volume up key to Volume up function, without triggering the screensaver now. :)

xev tell me this about the Volume Up on Macally Icekey:

KeyRelease event, serial 33, synthetic NO, window 0x5000001,
    root 0x106, subw 0x0, time 15780915, (484,231), root:(489,361),
    state 0x0, keycode 160 (keysym 0x1008ff2d, XF86ScreenSaver), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

[Eduard Hasenleithner (eduard-hasenleithner)]

I see two possibilities why the Macally keyboard locks the screen. Either it emits Usage ID 0xF9 on HID Usage Page 0x07 (Keyboard), or it emits Usage ID 0x19e on HID Usage Page 0x0C (Consumer). In order to verify this theory, it might be useful to have a look at the HID descriptor and the HID events.

Depending on the results, special quirk handling of the keyboard might be added to the linux kernel and/or gnome-screensaver gets a option to ignore the (fake) "lock screen" key.

HOWTO:
1. get the USB vendor+product ID using lsusb
> lsusb
Search for the line with the Macally Keyboard
(e.g. I get "Bus 001 Device 007: ID 046a:0023 Cherry GmbH CyMotion Master Linux Keyboard" for my keyboard, so the vendor:id is 046a:0023)

2. look at the device descriptors
> cd /sys/kernel/debug/hid
> ls
(I have here four entries, my keyboard makes up two of them 0003:046A:0023.0002 and 0003:046A:0023.0003; notice the matching vendor:id 046a:0023)
> sudo cat $YOUR_DEVICE1/rdesc
> sudo cat $YOUR_DEVICE2/rdesc

3. look at the events of the keys
(Please be aware that the following records all your keypresses, so don't enter passwords or other sensitive information if you intend to post the event log to the bug report! Entering the password for "sudo" is ok, because it asks the password _before_ running the command)
3.1 first device
> sudo cat $YOUR_DEVICE1/events
press the volume up key
exit with CTRL-C
3.2 second device
> sudo cat $YOUR_DEVICE2/events
press the volume up key again
exit with CTRL-C

Please find attached the output from my keyboard. It is only for demonstration purposes, because when connected via USB my keyboard does not exhibit the "lock screen" bug.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Tim Cuthbertson (gfxmonk)]

output from Eduard Hasenleithner's instructions.

Only one of my devices logged anything when I pressed the volume up button, so I've only included that one.

It seems to be sending the "keyboard.f9" event, which is inded mapped to "coffee".

Note: I'm now running fedora 17 beta, but this bug has been with me through multiple ubuntu & fedora versions, so I don't think it's distro-specific.

[David D Miller (justdave)]

Here's my output from the same, since I have this keyboard also, and am having the same problem. Note that the volume down key is also mapped incorrectly, and returns the code for "Refresh" instead of "VolumeDown".

[David D Miller (justdave)]

I'll point out that the Mute and Eject buttons are in fact mapped correctly however, so those two do what they're supposed to. :)

[David D Miller (justdave)]

What else needs to be done to get this fixed? Anything I can do to help it along faster?