acpi_fakekey stopped working for certain keycodes
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Debian |
Fix Released
|
Unknown
|
|||
acpi-support (Ubuntu) |
Won't Fix
|
Undecided
|
Unassigned | ||
Hardy |
Invalid
|
Undecided
|
Unassigned | ||
linux (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned | ||
Hardy |
Invalid
|
Undecided
|
Unassigned |
Bug Description
There are popping quite a lot "hotkeys don't work anymore" bugs up and it boils down to certain acpi_fakekey keycodes being ignored/filtered out.
acpi_fakekey is shipped from the package acpi-support, and it basically takes a keycode and sends it to the keyboard fd.
E.g. "sudo acpi_fakekey 81" works and simulates pressing "3".
The problem however is, that keycodes like KEY_WWW do not seem to get through (e.g. a running "xev" does not receive any event, when using sleep, acpi_fakekey and putting focus in the xev window).
This causes the hooks provided by acpi-support to do nothing, e.g. the following should open a browser window, but does nothing:
$ cat /etc/acpi/webbtn.sh
#!/bin/bash
. /usr/share/
acpi_fakekey $KEY_WWW
$ grep KEY_WWW /usr/share/
KEY_WWW=150
$ sudo acpi_fakekey 150
TESTCASE:
1. start "xev" (from x11-utils) in a shell/terminal
2. arrange the xev window and terminal so that you can see events from xev in the shell window
3. in another shell execute "sleep 10; sudo acpi_fakekey 148"
4. Move the mouse cursor/focus in the xev window
5. Check if a KeyPress and KeyRelease gets displayed when the acpi_fakekey gets executed
Joey Chan wrote in bug 199502:
Bug is actually in the kernel.
acpi-support is a collection of scripts, acpi-fakekey works in 2.6.22
I also ran Xorg7.4/1.3 on 2.6.22, fakekey still works.
It's only when changing to 2.6.24 does it break. I don't think the
problem is X ignoring the event, but the kernel actually dropping the
fake input. Looking at the source, there aren't any X components linked
in.
From looking around at related issues it seems like the hotkeys probably should get handled using HAL.
See http://
I'm still unsure about these problems, maybe acpi_fakekey gets "silenced" somewhere intentionally, because HAL is supposed to get used?!
Changed in linux: | |
assignee: | nobody → ubuntu-kernel-team |
importance: | Undecided → High |
status: | New → Triaged |
description: | updated |
Changed in linux: | |
assignee: | nobody → timg-tpi |
importance: | Undecided → High |
status: | New → In Progress |
milestone: | ubuntu-8.04.1 → none |
Changed in linux: | |
status: | Confirmed → Triaged |
Changed in debian: | |
status: | New → Fix Released |
Something occurred to me when looking further into the problem.
It may be that acpi_fakekey is writing to the wrong device file.
I'm going to be doing a trace later tonight and see if that is the case.
If it is, I'll probably try and hammer out a patch to use hal to find the keyboard, instead.