ATI USB remote keypresses ignored

Matt,

I think the problem is with the multimedia keys (XF86VolUp, XF86VolDown, XF86Audio, etc.)
Please, try to press 1,2,3 keys on your remote. They "should" work.

I have a multimedia keyboard (Samsung Pleomax) on USB. Before bug 311254 was fixed, any press on a multimedia button produced a crash. Now, after fixing, any press on a multimedia button is ignored. Exactly like your USB remote. On the other hand, any other buttons work.

Interestingly, the Power button on my keyboard works as expected: generates Shutdown Computer dialog. I think this is because it is intercepted by the ACPI daemon and doesn't reach X.

It would be nice if someone who has a multimedia keyboard on USB can test and report if the multimedia buttons work for them. This might help to restrict the problem to only some hardware.

On Sat, Jan 17, 2009 at 09:32:18PM -0000, Dan Andreșan wrote:
> I think the problem is with the multimedia keys (XF86VolUp, XF86VolDown, XF86Audio, etc.)
> Please, try to press 1,2,3 keys on your remote. They "should" work.

No, none of the keys work (including arrows, numbers, etc.) on the remote.
I think you have a different problem than I do.

--
 - mdz

I have a Microsoft Natural Desktop (wireless keyboard+mouse on USB). I have the same issues described here, i.e. pressing multimedia and other extended buttons used to crash X before bug 311254 was fixed and are ignored altogether now.

Because the patch for bug 311254 covers both master=0x0 and mk=0x0 (the latter was originally reported as bug 309785, and specifically related to extended keys in multimedia keyboards, but was later duped agains 311254), it may well be that the sources for the null values are separate and we have two different bugs here.

Please, let us know if we need to file a different bug for multimedia keyboards, or it's better to handle these issues together.

I'm getting the same with Logitech wireless keyboard. Running Jaunty AMD64 with ext4. Multimedia keys do not work.

I'm also having problems with my multimedia keys in Jaunty. I'm using a Dell wireless keyboard (don't know the model, but it's the default type with the Studio Hybrid desktops). The multimedia keys worked fine in 8.10, but after the dist-upgrade, they do not work anymore.

"xev" shows nothing, but, strangely, I can see using "top" that "hald" and "hald-addon-input" jump to around 6% processor load (from 0%) when I press the multimedia keys.

How do I even begin to debug this?

I think the root cause here is that something lower level than X (kernel? hal?) is providing a null input device some times. X wasn't prepared for handling that so was crashing. We fixed the crash in X, but it still leaves the question of why the input device was null to begin with.

The fact that xev is giving no output indicates that the error definitely is below X, but further analysis will be needed to find what that is. It may be the kernel, but I'm refiling against hal since that's the next layer down.

@Gina, Tomasso, and tvst, maybe you have the same issue as Matt, maybe not. I would encourage each of you to refer to http://wiki.ubuntu.com/Hotkeys for guidance in debugging your issues, and would recommend you each file your own bugs against hal after doing so. (If it does turn out you have the same problem, a bug triager can quite easily mark them as dupes.)

I just followed the troubleshooting guide at https://wiki.ubuntu.com/Hotkeys/Troubleshooting , and found that the command "sudo input-events <device num>" correctly prints my multimedia keys to the terminal when I press them.

When I execute "hal-find-by-capability --capability input | xargs -n1 lshal -u", I find that

input.x11driver = evdev
info.capabilities = { ..., 'input.keys', ... }

according to the troubleshooting guide, this means I have hit a bug in X. :-/

Oh, apparently this bug is for a remote control, not a wireless keyboard. Sorry, about the mixup. I will create a new bug report.

https://bugs.freedesktop.org/show_bug.cgi?id=19954

Why was this bug associated to xserver-xorg-video-ati?

It's a bug about an ATI remote, not about an ATI videocard. Yes, I guess that the remote comes with the videocard but...

All of the buttons on the remote seem to work properly at the input layer, i.e. I can see the events with input-events(1).

*Most* of the buttons also trigger events visible with lshal -m:

perseus:[...25.90/debian/build/xine/src] lshal -m

Start monitoring devicelist:
-------------------------------------------------
14:07:21.176: usb_device_bc7_4_noserial_logicaldev_input condition ButtonPressed = mute
14:07:22.312: usb_device_bc7_4_noserial_logicaldev_input condition ButtonPressed = mute
14:07:24.016: usb_device_bc7_4_noserial_logicaldev_input condition ButtonPressed = mute
14:07:36.640: usb_device_bc7_4_noserial_logicaldev_input condition ButtonPressed = www
14:07:37.224: usb_device_bc7_4_noserial_logicaldev_input condition ButtonPressed = bookmarks
14:07:37.712: usb_device_bc7_4_noserial_logicaldev_input condition ButtonPressed = edit
14:07:38.456: usb_device_bc7_4_noserial_logicaldev_input condition ButtonPressed = edit
14:07:39.144: usb_device_bc7_4_noserial_logicaldev_input condition ButtonPressed = bookmarks
14:07:40.312: usb_device_bc7_4_noserial_logicaldev_input condition ButtonPressed = www
14:08:12.184: usb_device_bc7_4_noserial_logicaldev_input condition ButtonPressed = volume-down
14:08:13.495: usb_device_bc7_4_noserial_logicaldev_input condition ButtonPressed = volume-up
14:08:35.064: usb_device_bc7_4_noserial_logicaldev_input condition ButtonPressed = mute
14:08:47.512: usb_device_bc7_4_noserial_logicaldev_input condition ButtonPressed = menu
14:08:48.672: usb_device_bc7_4_noserial_logicaldev_input condition ButtonPressed = menu
14:09:14.040: usb_device_bc7_4_noserial_logicaldev_input condition ButtonPressed = coffee
14:09:22.536: usb_device_bc7_4_noserial_logicaldev_input condition ButtonPressed = front
14:09:23.008: usb_device_bc7_4_noserial_logicaldev_input condition ButtonPressed = front
14:09:36.176: usb_device_bc7_4_noserial_logicaldev_input condition ButtonPressed = rewind
14:09:36.712: usb_device_bc7_4_noserial_logicaldev_input condition ButtonPressed = forward
14:09:44.072: usb_device_bc7_4_noserial_logicaldev_input condition ButtonPressed = play
14:09:46.784: usb_device_bc7_4_noserial_logicaldev_input condition ButtonPressed = stop
14:09:52.072: usb_device_bc7_4_noserial_logicaldev_input condition ButtonPressed = record
14:10:02.080: usb_device_bc7_4_noserial_logicaldev_input condition ButtonPressed = power
14:10:15.680: usb_device_bc7_4_noserial_logicaldev_input condition ButtonPressed = coffee
14:10:35.864: usb_device_bc7_4_noserial_logicaldev_input condition ButtonPressed = coffee
14:10:46.968: usb_device_bc7_4_noserial_logicaldev_input condition ButtonPressed = menu
14:10:48.952: usb_device_bc7_4_noserial_logicaldev_input condition ButtonPressed = menu
14:10:49.560: usb_device_bc7_4_noserial_logicaldev_input condition ButtonPressed = menu
14:10:50.128: usb_device_bc7_4_noserial_logicaldev_input condition ButtonPressed = menu
14:10:50.520: usb_device_bc7_4_noserial_logicaldev_input condition ButtonPressed = menu
14:10:50.936: usb_device_bc7_4_noserial_logicaldev_input condition ButtonPressed = menu
14:10:52.512: usb_device_bc7_4_noserial_logicaldev_input condition ButtonPressed = coffee
14:10:58.872: usb_device_b...

Here is the lshal output for the device:

udi = '/org/freedesktop/Hal/devices/usb_device_bc7_4_noserial_logicaldev_input'
  access_control.file = '/dev/input/event10' (string)
  access_control.type = 'mouse' (string)
  info.addons.singleton = {'hald-addon-input'} (string list)
  info.callouts.add = {'debian-setup-keyboard', 'hal-acl-tool --add-device'} (string list)
  info.callouts.remove = {'hal-acl-tool --remove-device'} (string list)
  info.capabilities = {'input', 'input.keys', 'input.mouse', 'button', 'access_control'} (string list)
  info.category = 'input' (string)
  info.parent = '/org/freedesktop/Hal/devices/usb_device_bc7_4_noserial' (string)
  info.product = 'X10 Wireless Technology Inc USB Receiver' (string)
  info.subsystem = 'input' (string)
  info.udi = '/org/freedesktop/Hal/devices/usb_device_bc7_4_noserial_logicaldev_input' (string)
  input.device = '/dev/input/event10' (string)
  input.originating_device = '/org/freedesktop/Hal/devices/usb_device_bc7_4_noserial' (string)
  input.product = 'X10 Wireless Technology Inc USB Receiver' (string)
  input.x11_driver = 'evdev' (string)
  input.xkb.layout = 'us' (string)
  input.xkb.model = 'pc105' (string)
  input.xkb.options = 'lv3:ralt_switch' (string)
  input.xkb.rules = 'evdev' (string)
  input.xkb.variant = 'dvorak' (string)
  linux.device_file = '/dev/input/event10' (string)
  linux.hotplug_type = 2 (0x2) (int)
  linux.subsystem = 'input' (string)
  linux.sysfs_path = '/sys/devices/pci0000:00/0000:00:1d.0/usb5/5-1/input/input32/event10' (string)

This is what I see in the X log when I connect the remote:

[52517.915011] (II) config/hal: Adding input device X10 Wireless Technology Inc USB Receiver
[52517.915136] (**) X10 Wireless Technology Inc USB Receiver: always reports core events
[52517.915164] (**) X10 Wireless Technology Inc USB Receiver: Device: "/dev/input/event10"
[52517.926325] (II) X10 Wireless Technology Inc USB Receiver: Found 4 mouse buttons
[52517.926357] (II) X10 Wireless Technology Inc USB Receiver: Found x and y relative axes
[52517.926374] (II) X10 Wireless Technology Inc USB Receiver: Found keys
[52517.926390] (II) X10 Wireless Technology Inc USB Receiver: Configuring as mouse
[52517.926405] (II) X10 Wireless Technology Inc USB Receiver: Configuring as keyboard
[52517.926435] (**) X10 Wireless Technology Inc USB Receiver: YAxisMapping: buttons 4 and 5
[52517.926455] (**) X10 Wireless Technology Inc USB Receiver: EmulateWheelButton: 4, EmulateWheelInertia: 10, EmulateWheelTimeout: 200
[52517.926491] (II) XINPUT: Adding extended input device "X10 Wireless Technology Inc USB Receiver" (type: KEYBOARD)
[52517.926529] (**) Option "xkb_rules" "evdev"
[52517.926562] (**) X10 Wireless Technology Inc USB Receiver: xkb_rules: "evdev"
[52517.926580] (**) Option "xkb_model" "pc105"
[52517.926610] (**) X10 Wireless Technology Inc USB Receiver: xkb_model: "pc105"
[52517.926626] (**) Option "xkb_layout" "us"
[52517.926656] (**) X10 Wireless Technology Inc USB Receiver: xkb_layout: "us"
[52517.926674] (**) Option "xkb_variant" "dvorak"
[52517.926704] (**) X10 Wireless Technology Inc USB Receiver: xkb_variant: "dvorak"
[52517.926722] (**) Option "xkb_options" "lv3:ralt_switch"
[52517.926753] (**) X10 Wireless Technology Inc USB Receiver: xkb_options: "lv3:ralt_switch"
[52518.078854] (**) X10 Wireless Technology Inc USB Receiver: (accel) keeping acceleration scheme 1
[52518.078922] (**) X10 Wireless Technology Inc USB Receiver: (accel) filter chain progression: 2.00
[52518.078950] (**) X10 Wireless Technology Inc USB Receiver: (accel) filter stage 0: 20.00 ms
[52518.078994] (**) X10 Wireless Technology Inc USB Receiver: (accel) set acceleration profile 0

Note that the variant is being set to 'dvorak', which matches my console keyboard, but doesn't make sense for a remote control with only letters A through F. I tried overriding this by temporarily editing /etc/default/console-setup, to check that this was not the cause of the problem, and it didn't seem to change anything. The keypresses are still ignored by X.

The one key which *does* work is the screen lock key (KEY_SCREENLOCK at the input layer, 'coffee' in HAL). I assume this is going directly to gnome-screensaver or somewhere, and not passing through X, since it doesn't show up in xev.

Here is the input-events output from pressing each of the keys on the remote in turn:

/dev/input/event10
   bustype : BUS_USB
   vendor : 0xbc7
   product : 0x4
   version : 256
   name : "X10 Wireless Technology Inc USB "
   phys : "/input0"
   bits ev : EV_SYN EV_KEY EV_REL

waiting for events
15:22:04.528554: EV_KEY KEY_A (0x1e) pressed
15:22:04.528572: EV_SYN code=0 value=0
15:22:04.528580: EV_KEY KEY_A (0x1e) released
15:22:04.528586: EV_SYN code=0 value=0
15:22:05.280550: EV_KEY KEY_B (0x30) pressed
15:22:05.280567: EV_SYN code=0 value=0
15:22:05.280575: EV_KEY KEY_B (0x30) released
15:22:05.280581: EV_SYN code=0 value=0
15:22:06.056551: EV_KEY KEY_POWER (0x74) pressed
15:22:06.056570: EV_SYN code=0 value=0
15:22:06.056578: EV_KEY KEY_POWER (0x74) released
15:22:06.056584: EV_SYN code=0 value=0
15:22:06.784542: EV_KEY KEY_TV (0x179) pressed
15:22:06.784559: EV_SYN code=0 value=0
15:22:06.784566: EV_KEY KEY_TV (0x179) released
15:22:06.784573: EV_SYN code=0 value=0
15:22:07.392548: EV_KEY KEY_DVD (0x185) pressed
15:22:07.392566: EV_SYN code=0 value=0
15:22:07.392575: EV_KEY KEY_DVD (0x185) released
15:22:07.392581: EV_SYN code=0 value=0
15:22:07.992548: EV_KEY KEY_WWW (0x96) pressed
15:22:07.992566: EV_SYN code=0 value=0
15:22:07.992574: EV_KEY KEY_WWW (0x96) released
15:22:07.992579: EV_SYN code=0 value=0
15:22:08.576551: EV_KEY KEY_BOOKMARKS (0x9c) pressed
15:22:08.576570: EV_SYN code=0 value=0
15:22:08.576579: EV_KEY KEY_BOOKMARKS (0x9c) released
15:22:08.576585: EV_SYN code=0 value=0
15:22:09.200551: EV_KEY KEY_EDIT (0xb0) pressed
15:22:09.200569: EV_SYN code=0 value=0
15:22:09.200577: EV_KEY KEY_EDIT (0xb0) released
15:22:09.200584: EV_SYN code=0 value=0
15:22:11.408553: EV_KEY KEY_VOLUMEDOWN (0x72) pressed
15:22:11.408571: EV_SYN code=0 value=0
15:22:11.408579: EV_KEY KEY_VOLUMEDOWN (0x72) released
15:22:11.408585: EV_SYN code=0 value=0
15:22:13.104548: EV_KEY KEY_VOLUMEUP (0x73) pressed
15:22:13.104566: EV_SYN code=0 value=0
15:22:13.104575: EV_KEY KEY_VOLUMEUP (0x73) released
15:22:13.104580: EV_SYN code=0 value=0
15:22:14.496555: EV_KEY KEY_MIN_INTERESTING (0x71) pressed
15:22:14.496573: EV_SYN code=0 value=0
15:22:14.496582: EV_KEY KEY_MIN_INTERESTING (0x71) released
15:22:14.496589: EV_SYN code=0 value=0
15:22:19.664551: EV_KEY KEY_CHANNELDOWN (0x193) pressed
15:22:19.664579: EV_SYN code=0 value=0
15:22:19.664587: EV_KEY KEY_CHANNELDOWN (0x193) released
15:22:19.664593: EV_SYN code=0 value=0
15:22:20.520549: EV_KEY KEY_CHANNELUP (0x192) pressed
15:22:20.520567: EV_SYN code=0 value=0
15:22:20.520574: EV_KEY KEY_CHANNELUP (0x192) released
15:22:20.520580: EV_SYN code=0 value=0
15:22:21.872555: EV_KEY KEY_1 (0x2) pressed
15:22:21.872574: EV_SYN code=0 value=0
15:22:21.872582: EV_KEY KEY_1 (0x2) released
15:22:21.872588: EV_SYN code=0 value=0
15:22:22.320544: EV_KEY KEY_2 (0x3) pressed
15:22:22.320563: EV_SYN code=0 value=0
15:22:22.320570: EV_KEY KEY_2 (0x3) released
15:22:22.320577: EV_SYN code=0 value=0
15:22:22.688548: EV_KEY KEY_3 (0x4) pressed
15:22:22.688566: EV_SYN code=0 value=0
15:22:22.688573: EV_KEY KEY_3 (0x4) released
15:22:22.688580: EV_SYN code=0 value=0
15:22:23.520549: EV_KEY KEY_4 (0x5) pressed
15:22:23....

Matt,

I am still following this bug, hoping that my keyboard problem will be solved.
I know that you said in comment 3 that my problem might be different, but it has the same symptoms:
- multimedia keys used to crash X
- immediately after that bug was fixed, they don't crash X anymore but are simply ignored
- lshal -m sees them all perfectly (with the right names)
- one key is working: for you is Screen Lock, for me is Power (I don't have Screen Lock) as ACPI will directly interpret it

after all, your remote is seen by X as a keyboard. The receiver is on USB and it receives the IR from remote and convert it in keyboard events sent by USB. X has no way to know that your Remote is anything else than a keyboard...

If you need me to post lshal -m output or other stuff then I can do it. But I think that the developers have enough info already.

On Sat, Feb 14, 2009 at 04:01:55PM -0000, Dan Andreșan wrote:
> I am still following this bug, hoping that my keyboard problem will be solved.
> I know that you said in comment 3 that my problem might be different, but it has the same symptoms:
> - multimedia keys used to crash X
> - immediately after that bug was fixed, they don't crash X anymore but are simply ignored
> - lshal -m sees them all perfectly (with the right names)
> - one key is working: for you is Screen Lock, for me is Power (I don't have Screen Lock) as ACPI will directly interpret it
>
> after all, your remote is seen by X as a keyboard. The receiver is on
> USB and it receives the IR from remote and convert it in keyboard events
> sent by USB. X has no way to know that your Remote is anything else than
> a keyboard...

I assume, however, that the "normal" keys on your keyboard, like 0-9 and
A-Z, work fine, or you wouldn't even be paying attention to the multimedia
keys. :-)

The alphanumeric keys on the remote don't work at all. Therefore your
symptoms are at least somewhat different, and you should file a separate bug
report. If it turns out to be the same, it is easy to mark the bug report
as a duplicate, but it is hard to disentangle multiple issues from within a
single bug report.

--
 - mdz

Looks like there's a proper patch for this issue upstream. I'll pull it in.

This bug was fixed in the package xorg-server - 2:1.5.99.902-0ubuntu7

---------------
xorg-server (2:1.5.99.902-0ubuntu7) jaunty; urgency=low

  * Add 161_force_paired_kbd_device.patch: Fixes issue where a multimedia
    keyboard (or keyboard-like device) sends its multimedia key events
    through the mouse device file. In this case, pair the device with the
    master before processing the events. Patch cherrypicked from upstream.
    (LP: #318261)

 -- Bryce Harrington <email address hidden> Tue, 17 Feb 2009 17:20:51 -0800

Great, this fixed my problem too. I was prepared to fill a new bug this morning, as advised, but this update made it not necessary.

Thanks to all involved.

P.S. Now if only the bug [when I click on the Date/Time/Weather applet, instead of opening the calendar popup, it just freeze all gnome panels making an useless gnome session] would be fixed...

Confirmed fixed on current Jaunty. Thanks!