Ubuntu

acpi_fakekey stopped working for certain keycodes

Reported by Daniel Hahler on 2008-04-14
140
This bug affects 5 people
Affects Status Importance Assigned to Milestone
Debian
Fix Released
Unknown
acpi-support (Ubuntu)
Undecided
Unassigned
Declined for Intrepid by Steve Langasek
Declined for Jaunty by Steve Langasek
Hardy
Undecided
Unassigned
linux (Ubuntu)
Undecided
Unassigned
Declined for Intrepid by Steve Langasek
Declined for Jaunty by Steve Langasek
Hardy
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-support/key-constants
acpi_fakekey $KEY_WWW

$ grep KEY_WWW /usr/share/acpi-support/key-constants
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://people.freedesktop.org/~hughsient/quirk/quirk-keymap-index.html for more information, about creating the required information files and maybe you can come up with some patch for hal-info and/or there's a patch available already somewhere, which needs to get included.

I'm still unsure about these problems, maybe acpi_fakekey gets "silenced" somewhere intentionally, because HAL is supposed to get used?!

Daniel Hahler (blueyed) on 2008-04-15
Changed in linux:
assignee: nobody → ubuntu-kernel-team
importance: Undecided → High
status: New → Triaged
Daniel Hahler (blueyed) on 2008-04-15
description: updated
Joey Chan (ttdlx1989) wrote :

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.

Joey Chan (ttdlx1989) wrote :

Additional note.
The problem would have been caused by the kernel somehow changing the order of the devices, and one of them is being incorrectly detected as a keyboard.

Nikolaus Filus (nfilus) wrote :

On my Samsung P35 the most important key not working is KEY_VIDEOOUT (227)
I'm using kernel 2.6.24.16.18

Using the previous comments maybe the input mapping is relevant:
[ 11.855577] input: Macintosh mouse button emulation as /devices/virtual/input/input0
[ 11.902929] input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input1
[ 43.722822] input: SynPS/2 Synaptics TouchPad as /devices/platform/i8042/serio4/input/input2
[ 43.808329] input: PC Speaker as /devices/platform/pcspkr/input/input3
[ 44.387808] input: Power Button (FF) as /devices/virtual/input/input4
[ 44.414697] input: Lid Switch as /devices/virtual/input/input5
[ 44.426723] input: Sleep Button (CM) as /devices/virtual/input/input6
[ 46.406183] input: Video Bus as /devices/LNXSYSTM:00/device:00/PNP0A03:00/device:01/LNXVIDEO:00/input/input7

Joey Chan (ttdlx1989) wrote :

Tested. It detects my keyboard fine, but still doesn't work. The format doesn't appear changed, either. No errors from writing to the device file. Moreover, standard keys still work through acpi_fakekey, so for some reason or another, the kernel is deciding that extraneous keys are ignored (what the kernel decides is extraneous is beyond me. Most of my special keys still work, only the blue Access IBM button doesn't).

It wouldn't be fixing the problem, but it may be worthwhile to convert or at least whitelist known problematic keys in acpi_fakekey to do fake X key events, rather than fake device key events.

Joey Chan (ttdlx1989) wrote :

Interestingly enough, when I manually define the keycode using setkeycodes (in my case, the IBM button is e017 on a T40p) the key magically works.
However, it seems that it's dependent on each other. The key isn't recognized until both the kernel has it defined, and the key is triggered through an acpi_fakekey.
I find that odd, since it should at least work if it's defined at the kernel level.

Also, this implies the change does not persist through reboot.

Sergei Ianovich (ynvich-gmail) wrote :

I am experiencing similar behavior with debian/unstable on Sony TX770P laptop. Ubuntu bug 187980 looks a duplicate of this one. Debian 373660 also addresses the same problem.

Sergei Ianovich (ynvich-gmail) wrote :

Since August 2007, kernel input handler checks that a triggered key is reported as present by keyboard. This patch should restore all types of acpi_fakekey related regressions.

Joey Chan (ttdlx1989) wrote :

Hmm, looks like you got it.
I was starting to think the kernel was doing some kind of check to see if the key being read was the actual key being triggered, but I couldn't figure out how the kernel would know since all events go through the device file one way or another.

And it seems it was just as I thought. The change was committed in 2.6.23. Probably why no one has caught it up to now.

Tomas Zilvar (jcd17) wrote :

Hi guys, I've recently submitted a bug, which was marked as a duplicate of this one (see #218333). However, there are some minor differences, eg. I'm running kernel 2.6.22.14-generic (uname -r, fresh install of Kubuntu CD), and my keys are recognized by HAL, no error can be seen in dmesg output, quite contrary to what the forementioned freedesktop.org quirk-keymap website describes (so I can't provide any help there). The test case suggested in the bug description reproduces the error, which means there are no events logged by xev.

I've fixed it with a workaround (using dcop call), but it just doesn't feel right. I just wanted to let you know and see if my bug really is a duplicate of this one.

josh04 (josh04) wrote :

Will this get in to Hardy before release?

I can confirm that adding the line
  setkeycodes e017 148

to '/usr/share/hotkey-setup/ibm.hk' fixes the 'Access IBM' button on my T42p.

I can confirm as well that showkey and acpi_listen show the button, but without the setkey fix the event isn't propagated through to X via acpi_fakekey.

Interestingly ibm.hk says the button should no longer be defined in there since its handled via the polling daemon 'thinkpad-buttons'. But a trace on thinkpad-buttons shows it doesn't receive any events at all anymore.

chrhei (ch-heimanns) wrote :

I can confirm that adding the line

  setkeycodes e017 148 (for the ThinkVantage button)
and
  setkeycodes 0082 192 (for the Fn+SPACE combination)

to /etc/rc.local is working for me on my LENOVO, ThinkPad R61, 8943DMG with Ubuntu 8.04.

Not nice, but it works.

Seth Randall (sethrandall) wrote :

I will second Philippe Seewer's fix. I added it to my T61 and my ThinkVantage button is working again.

Blaise Alleyne (balleyne) wrote :

@Seth: ditto for me

chrhei (ch-heimanns) wrote :

mmmhhhh..... I'm not happy with the fix (setkeycodes e017 148). The fix seems to conflict with Fn+F8 (touchpad on/off). After running setkeycodes e017 148 the ThinkVantage button is producing the same keycode as the Fn+F8 combination. For helping troubleshooting I attach the output of showkey:

showkey -k

kb Modus war UNICODE

Taste drücken (Programm beendet sich 10s nach dem letzten Tastendruck)...)
0x9c
0x00 0x82 0xe8 0x80 0x82 0xe8 # ThinkVantage
0x00 0x81 0x94 0x80 0x81 0x94 # Fn+F8
0x00 0x82 0xf4 0x80 0x82 0xf4 # Fn+Space

VictorGreen (publicpolicywonk) wrote :

Where do I add the setkeycodes e017 148? Philippe Seewer said /usr/share/hotkey-setup/ibm.hk and christian said /etc/rc.local. I tried adding the code to the first suggested file, but didnt know where so I stuck it in at the bottom.

The command: "xbindkeys --key" still showed no input from repeated hammering of the thinkvantage button my my X61 running Hardy 64 clean install. Same results with xbindkey when I took the code out of the first suggestion and put it in rc.local instead. Do I have to restart or reload x after making the changes to one of these config folders?

Blaise Alleyne (balleyne) wrote :

@VictorGreen: You can add that line anywhere to the file (ibm.hk), as long as it's on a separate line. I'm not sure what exactly needs to be restarted in order to make it work (especially since it says the bug is in the kernel, as it works with 2.6.22), but I waited until I restarted my whole machine before testing it out. It worked fine after a restart.

I think ibm.hk is preferable to rc.local. My understanding is that rc.local is a sort of generic startup script which is run in Debian-based distributions at the end of all the multi-user boot levels, whereas ibm.hk is specifically for this sort of thing. Both ought to work I guess, but it seems ibm.hk is a more appropriate place.

@Victor: /etc/rc.local and /usr/share/hotkey-setup/ibm.hk are both only executed at boot time. So you would have to reboot to see the effect of changes there.

But you can also execute "sudo setkeycodes e017 148" in a terminal for an immediate result.

It does not really matter if you use ibm.hk or rc.local, but I'd vote for rc.local, because that is (as the name suggests) the startup file for your local changes and, hence, does not interfer with files which are administrated by packages. (ibm.hk should be overwritten when an update to hotkey-setup comes out.)

@all: The setkeycodes fix is a *very* dirty hack. In fact, it does not matter which scancode is used at the first position. I've got
     setkeycodes e07f 148 # ThinkPad Button
     setkeycodes e07e 192 # Zoom (Fn-Space)
in my rc.local and it also does work. These are only needed to convince the kernel that the keycodes in the second positions are legal, because it otherwise does not propagate them when they are issued by acpi_fakekey.

The way to go is Sergey's fix above, which would make this whole mess unnecessary.

VictorGreen (publicpolicywonk) wrote :

Thanks to balleyne and Benhamin Braatz the thinkvantage key is recognized by the keyboard shortcuts gui.

Daniel Hahler (blueyed) wrote :

Milestoning for 8.04.1, because the patch from Sergey appears to fix this regression, which breaks acpi-support in different ways (its invoked actions get discarded).

Changed in linux:
milestone: none → ubuntu-8.04.1
Tim Gardner (timg-tpi) wrote :

Daniel - in what tree does this cherry-pick exist?

Changed in linux:
assignee: ubuntu-kernel-team → timg-tpi
status: Triaged → In Progress
Daniel Hahler (blueyed) wrote :

Tim, it looks like a local commit to Sergey's private repository. Is that correct, Sergey?

Sergei Ianovich (ynvich-gmail) wrote :

> Tim, it looks like a local commit to Sergey's private repository. Is that correct, Sergey?

That's correct. I don't an exported kernel repository, only my local tree.

Roy Kimbrell (roy-kimbrell) wrote :

FYI

The CD eject button (and others) on my Sony Vaio VGN-A270P work fine in 7.10. They do NOT work in 8.04! Something (obviously) broke sonypi (I'm guessing). Running xev on 7.10 (clean install) gets the following when pushing the eject button:

FocusIn event, serial 30, synthetic NO, window 0x3200001,
    mode NotifyGrab, detail NotifyPointer

KeymapNotify event, serial 30, synthetic NO, window 0x0,
    keys: 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
           0 0 0 0 0 0 0 0 0 16 0 0 0 0 0 0

FocusOut event, serial 30, synthetic NO, window 0x3200001,
    mode NotifyUngrab, detail NotifyPointer

On 8.04 (clean install) it did nothing at all. I've reinstalled 7.10 on the Vaio because of other problems with 8.04. However, if you'd like me to reinstall 8.04 and run some tests, I'd be happy to do whatever I can to help.

Thanks
Roy

Daniel Hahler (blueyed) wrote :

The fix in Debian is described as follows, in acpi-support 0.109-1 (not the kernel):
   * Divert sleep button to sleep.sh if power management daemons are not
     running, for thinkpad, panasonic, sony and toshiba laptops.
     Closes: #467374, 373660.
I guess that does not make acpi_fakekey work again in general, but is rather a workaround for #467374.

Sami Lahtinen (samuelvasy) wrote :

Is this bug somehow related to this one https://bugs.launchpad.net/ubuntu/+source/hotkey-setup/+bug/211952 ?

"sudo setkeycodes e076 148" makes WOW-Video button visible, so I can map it to action I want.

unggnu (unggnu) wrote :

I can confirm that the sony eject button works fine again with Sergey Yanovich patch. It would be great if this could make it into Hardy 8.04.1.

unggnu (unggnu) wrote :

Btw. does anyone know why the kernel developers have changed this behavior? There have to be a reason. Is there any upstream bug report?

Steve Langasek (vorlon) on 2008-06-02
Changed in linux:
assignee: nobody → timg-tpi
importance: Undecided → High
status: New → In Progress
milestone: ubuntu-8.04.1 → none
Florian Birée (florian-biree) wrote :

Same problem on my Asus Z92J (also A6J), with xubuntu 8.04.1.

There is three key that doesn't work (and which works with 7.10) : the WWW key, the eject key, and the "Power4Gear" key, which start /etc/acpi/lockbtn.sh.

I have also noticed that the keycode send via acpi_fakekey is not the same than the one showed by xev. Is this normal? Maybe it is related...

As a really dirty hack, I've change the call to acpi_fackekey in /etc/acpi/*.sh to send a keycode that works.

MarcoBazzani (visik7) wrote :

same problem here I can confirm
fakekeys > 100 doesn't works

unggnu (unggnu) wrote :

The problem still appears with 2.6.26 Vanilla Kernel.

MarcoBazzani (visik7) wrote :

make some tests of a bunch of different installalation of hardy on laptops and desktops I can confirm this bug

Changed in linux:
status: In Progress → Confirmed
status: Confirmed → In Progress
status: In Progress → Confirmed
unggnu (unggnu) wrote :

This is still an issue in Intrepid. The patch works fine in Hardy and Intrepid and is a one-liner so what prevents it from being integrated or sponsored? Or are there plans to make acpi work with the new kernel code?

MarcoBazzani (visik7) wrote :

@unggnu
where is the patch ?

MarcoBazzani (visik7) wrote :

for who is interested here there is a deb of -generic i386 patched

Tim Gardner (timg-tpi) wrote :

@MarcoBazzani: It would be useful if you would attach the patch against -19.36 that you used to produce your binary package.

On Mon, Jul 21, 2008 at 7:00 PM, Tim Gardner <email address hidden> wrote:
> @MarcoBazzani: It would be useful if you would attach the patch against
> -19.36 that you used to produce your binary package.
>
> --
> acpi_fakekey stopped working for certain keycodes
> https://bugs.launchpad.net/bugs/217504
> You received this bug notification because you are a direct subscriber
> of the bug.
>

the patch is the one reported above.

--
Fran Lebowitz - "Food is an important part of a balanced diet."

Stas (stasic) wrote :

Patch presented by MarcoBazzani don't work for me.

P.S. ubuntu hardy

josh04 (josh04) wrote :

Me neither, also on hardy.

MarcoBazzani (visik7) wrote :

On Tue, Jul 22, 2008 at 1:32 AM, josh04 <email address hidden> wrote:
> Me neither, also on hardy.
>
> --
> acpi_fakekey stopped working for certain keycodes
> https://bugs.launchpad.net/bugs/217504
> You received this bug notification because you are a direct subscriber
> of the bug.
>

strange I've tested it on 5 machines and it works

Francisco T. (leviatan1) wrote :

Work for me with xev:

KeyPress event, serial 31, synthetic NO, window 0x3000001,
    root 0x59, subw 0x0, time 534081, (-289,312), root:(305,336),
    state 0x0, keycode 130 (keysym 0x0, NoSymbol), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyRelease event, serial 31, synthetic NO, window 0x3000001,
    root 0x59, subw 0x0, time 534081, (-289,312), root:(305,336),
    state 0x0, keycode 130 (keysym 0x0, NoSymbol), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyPress event, serial 31, synthetic NO, window 0x3000001,
    root 0x59, subw 0x0, time 538445, (-289,312), root:(305,336),
    state 0x0, keycode 146 (keysym 0x0, NoSymbol), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyRelease event, serial 31, synthetic NO, window 0x3000001,
    root 0x59, subw 0x0, time 538445, (-289,312), root:(305,336),
    state 0x0, keycode 146 (keysym 0x0, NoSymbol), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

but there are no associated actions.

MarcoBazzani (visik7) wrote :

On Tue, Jul 22, 2008 at 9:28 PM, Pepe <email address hidden> wrote:
> Work for me with xev:
>
> KeyPress event, serial 31, synthetic NO, window 0x3000001,
> root 0x59, subw 0x0, time 534081, (-289,312), root:(305,336),
> state 0x0, keycode 130 (keysym 0x0, NoSymbol), same_screen YES,
> XLookupString gives 0 bytes:
> XmbLookupString gives 0 bytes:
> XFilterEvent returns: False
>
> KeyRelease event, serial 31, synthetic NO, window 0x3000001,
> root 0x59, subw 0x0, time 534081, (-289,312), root:(305,336),
> state 0x0, keycode 130 (keysym 0x0, NoSymbol), same_screen YES,
> XLookupString gives 0 bytes:
> XFilterEvent returns: False
>
> KeyPress event, serial 31, synthetic NO, window 0x3000001,
> root 0x59, subw 0x0, time 538445, (-289,312), root:(305,336),
> state 0x0, keycode 146 (keysym 0x0, NoSymbol), same_screen YES,
> XLookupString gives 0 bytes:
> XmbLookupString gives 0 bytes:
> XFilterEvent returns: False
>
> KeyRelease event, serial 31, synthetic NO, window 0x3000001,
> root 0x59, subw 0x0, time 538445, (-289,312), root:(305,336),
> state 0x0, keycode 146 (keysym 0x0, NoSymbol), same_screen YES,
> XLookupString gives 0 bytes:
> XFilterEvent returns: False
>
> but there are no associated actions.
eh eh this is not my fault but now you can associate it :D

--
Rodney Dangerfield - "I worked in a pet store and people would ask
how big I would get."

Stas (stasic) wrote :

to MarcoBazzani

how to associate them ?

Francisco T. (leviatan1) wrote :

@MarcoBazzani: Yes I know. Thank you for the patch ;)

@Stas: For example https://help.ubuntu.com/community/MultimediaKeys

MarcoBazzani (visik7) wrote :

patched 2.6.24-20

josh04 (josh04) wrote :

Could anyone tell me how to assign the (presumably fixed) keys to brightness control?

MarcoBazzani (visik7) wrote :

this patch doesn't fix broken keys of brightness, if your buttons doesn't generate acpi events this patch is useless
run
tail -f /var/log/acpid
and press your brightness buttons and see if some kind of events are generated
(for me brightness works also without the patch)

josh04 (josh04) wrote :

The keys do generate acpi events, but the events call scripts which use acpi_fakekey, and that is what does nothing.

Pox (anthony-carapetis) wrote :

I've got events coming through on acpi_listen but acpi_fakekey isn't working even after an attempted setkeycodes hack... any ideas, anyone?

Dana Goyette (danagoyette) wrote :

This is also still broken in the latest Intrepid kernel, 2.6.26-5-generic.

registername (regname) wrote :

It looks like this will not be fixed in kernel 2.6.27 either because (at least up to rc3) the section of drivers/input/input.c in Sergey Yanovich's patch isn't going to change. I believe acpi_fakekey is only a Debian-based distro thing, so has anyone from Debian or Ubuntu even tried to argue that the mainline kernel be patched for this? Or is Debian acpi handling going to be modified? Even if a kernel change were proposed for
2.6.28 that will be around 1 year since it was broken in 2.6.24. I for one would appreciate it if Ubuntu/Debian proprietary kernel patches were kept to the absolute minimum.

MarcoBazzani (visik7) wrote :

since it's considered a feature and not a bug it will be difficult that this patch will be included in the mainline kernel
maybe there is better way to reproduce this kind of signals for example registering a fake input device

Dana Goyette (danagoyette) wrote :

Hmm, here's a thought: aren't the "uinput" framework and module meant exactly for this purpose (injecting input events)? Perhaps acpi_fakekey can be adapted to use uinput instead of writing to existing input devices.

The Ubuntu Kernel Team is planning to move to the 2.6.27 kernel for the upcoming Intrepid Ibex 8.10 release. As a result, the kernel team would appreciate it if you could please test this newer 2.6.27 Ubuntu kernel. There are one of two ways you should be able to test:

1) If you are comfortable installing packages on your own, the linux-image-2.6.27-* package is currently available for you to install and test.

--or--

2) The upcoming Alpha5 for Intrepid Ibex 8.10 will contain this newer 2.6.27 Ubuntu kernel. Alpha5 is set to be released Thursday Sept 4. Please watch http://www.ubuntu.com/testing for Alpha5 to be announced. You should then be able to test via a LiveCD.

Please let us know immediately if this newer 2.6.27 kernel resolves the bug reported here or if the issue remains. More importantly, please open a new bug report for each new bug/regression introduced by the 2.6.27 kernel and tag the bug report with 'linux-2.6.27'. Also, please specifically note if the issue does or does not appear in the 2.6.26 kernel. Thanks again, we really appreicate your help and feedback.

Dana Goyette (danagoyette) wrote :

I can confirm, this is still broken in the 2.6.27 kernel.

MarcoBazzani (visik7) wrote :

it will not be fixed increasing the kernel version number but removing
the check of keys provided by a keyboard
or rewriting acpi_fakekey
:)
cheers
   Marco

On Thu, Aug 28, 2008 at 6:03 PM, Leann Ogasawara <email address hidden> wrote:
> The Ubuntu Kernel Team is planning to move to the 2.6.27 kernel for the
> upcoming Intrepid Ibex 8.10 release. As a result, the kernel team would
> appreciate it if you could please test this newer 2.6.27 Ubuntu kernel.
> There are one of two ways you should be able to test:
>
> 1) If you are comfortable installing packages on your own, the linux-
> image-2.6.27-* package is currently available for you to install and
> test.
>
> --or--
>
> 2) The upcoming Alpha5 for Intrepid Ibex 8.10 will contain this newer
> 2.6.27 Ubuntu kernel. Alpha5 is set to be released Thursday Sept 4.
> Please watch http://www.ubuntu.com/testing for Alpha5 to be announced.
> You should then be able to test via a LiveCD.
>
> Please let us know immediately if this newer 2.6.27 kernel resolves the
> bug reported here or if the issue remains. More importantly, please
> open a new bug report for each new bug/regression introduced by the
> 2.6.27 kernel and tag the bug report with 'linux-2.6.27'. Also, please
> specifically note if the issue does or does not appear in the 2.6.26
> kernel. Thanks again, we really appreicate your help and feedback.
>
> ** Tags added: cft-2.6.27
>
> --
> acpi_fakekey stopped working for certain keycodes
> https://bugs.launchpad.net/bugs/217504
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--

Casey Stengel - "All right everyone, line up alphabetically according
to your height."

PandaMine (pandamine) wrote :

MarcoBazzani, would you be able to use Sergey Yanovich patch on the latest Hardy Heron linx kernel (linux-image-2.6.24-19-generic_2.6.24-19.45ubuntu1_i386.deb) and upload it since the latest patch you have released is on linux-image-2.6.24-19-generic_2.6.24-19.36ubuntu1_i386.deb and the 2.6.24-19.36 package is no longer in the repositories

Thanks heaps

MarcoBazzani (visik7) wrote :

truly I'm quite tired of keeping this package update, kernel team release a new version every 2 weeks and this patch isn't included yet, I'm really pissed off about this behaviour.
I give up and I keep the bug on my system too, just to explain that this is not the case where I've the package and I don't want to release to everybody :)
but I can post you instructions on how to build it by yourself so you can keep this package updated
here they are:
apt-get source linux-image-`uname -r`
cd linux-2.6.24
vim drivers/input/input.c
around line 160 you need to change this:

  if (is_event_supported(code, dev->keybit, KEY_MAX) &&
      !!test_bit(code, dev->key) != value) {

into this:
               if (!!test_bit(code, dev->key) != value) {

save the file and run
dch -i
add a ~whatever0 to the version number (whatever means whatever you want :D)
than run
CONCURRENCY_LEVEL=3 AUTOBUILD=1 NOEXTRAS=1 fakeroot debian/rules binary-generic
the first parameter CONCURRENCY_LEVEL=3 depends on how many cores you have I've 2 cores usually concurrency is N°cpu+1 but you could increase it or decrease it at 1 too it's only take longer to build.
after this go to the parent directory and you should have a new package ready to install
cheers
     Marco

registername (regname) wrote :

This bug seems to have been reported again for Intrepid here: https://bugs.launchpad.net/bugs/267682.

Daniel Hahler (blueyed) on 2008-09-23
Changed in linux:
status: Confirmed → Triaged
Tom Jaeger (thjaeger) wrote :

Okay, so acpi_fakekey just looks for a random input device that it thinks is a keyboard and then sends the key to it. This is wrong, and patching the kernel is not the solution. The proper way is to go through uinput. But there are two problems: First, single key uinput devices are detected as mice, not keyboards, but this is easy two work around (see bug #256429). The bigger problem is that it takes a while for hal to set everything up, so we need a (considerable) delay between creating the device and sending the key. I've attached a proof-of-concept acpi_fakekey program that does just this, but the delay is of course unacceptable.

So what I think should be done is have acpid create the device and then expose it via a fifo. I'll write something up (but I'm not sure I'll get to it today).

Any thoughts? By the way, who is upstream here?

Bryce Harrington (bryce) wrote :

Hi Tom,

There isn't really an upstream for this package - it's maintained entirely by Ubuntu (and Debian). If you can get a working patch, then you just need one of the Ubuntu engineers to incorporate it for you. I'd be happy to do this when you're ready with a patch - just ping me on IRC.

MarcoBazzani (visik7) wrote :

On Mon, Nov 24, 2008 at 11:31 PM, Bryce Harrington <
<email address hidden>> wrote:

> Hi Tom,
>
> There isn't really an upstream for this package - it's maintained
> entirely by Ubuntu (and Debian). If you can get a working patch, then
> you just need one of the Ubuntu engineers to incorporate it for you.
> I'd be happy to do this when you're ready with a patch - just ping me on
> IRC.
>

the working patch at least for the kernel was pointed out by me some posts
ago

to patch acpi_fakekey I really dunno where to begin

Tom Jaeger (thjaeger) wrote :

I've added an updated acpi-support package to my PPA that should fix this issue regardless of the kernel used. It splits up the work that acpi_fakekey is currently doing into an acpi_fakekeyd daemon that creates a uinput device and then listens for input on a fifo and an acpi_fakekey frontend that sends keycodes to the fifo. The package also contains a fix for bug #59695.

i386:
http://ppa.launchpad.net/thjaeger/ubuntu/pool/main/a/acpi-support/acpi-support_0.114+ppa2_i386.deb
amd64:
http://ppa.launchpad.net/thjaeger/ubuntu/pool/main/a/acpi-support/acpi-support_0.114+ppa2_amd64.deb

lujana (lujana-nakhodka) wrote :

Hi Tom!

I have tried your acpi package on Sony Vaio-TX2. Unfortunately, i have seen no difference with additional keys. Xev showes nothing.

Thanks for your effort, Tom.

Sorry to bring you bad news, but I have tried your (i386) acpi-support package on my Thinkpad R52 (where most keys work on Intrepid, but "Access IBM" key doesn't), but after installation at least the volume buttons ceased to work too (don't even show up on xev). I tried to reboot, too, but that didn't help.

I've since reverted to the default intrepid version (and volume buttons started to work again immediately). If there's any output/status/log you'd like to see, I'd be happy to help (although I'm a bit busy, so it might take a few days).

Tom Jaeger (thjaeger) wrote :

lujana, do you see acpi events if you press those keys while running "sudo acpi_listen"?

Matja, that's strange. Can you check if acpi_fakekeyd is even running? If not, what's the output of "sudo acpi_fakekeyd?

@Tom:

matija@.....:~$ sudo -i acpi_fakekeyd
matija 22840 0.0 0.0 3236 808 pts/0 S+ 22:51 0:00 grep fake
matija@.....:~$ which acpi_fakekeyd
/usr/bin/acpi_fakekeyd
matija@.....:~$ sudo acpi_fakekeyd
open: No such file or directory

Congratulations to me for copy-ing wrong (and even stupidly wrong) command (and appending the correct response). The first line should have been:
  matija@.....:~$ sudo ps aux | grep fake

Tom Jaeger (thjaeger) wrote :

Thanks. So the uinput module isn't automatically loaded in a default ubuntu installation. I've modified the postinst script now to load uinput if necessary add uinput to /etc/modules if it's not already there. Is that the right way to do it (it's how thinkfinger does it) or should I have the daemon load the uinput module if necessary? Packages will appear in my PPA in about 20 minutes.

After manually loading uinput, acpi_fakekeyd sucesfully started, volume keys *do* work, as well as the "Access IBM" key, that didn't work before (with intrepid's version of acpi-support). So it seems to work for me! Thank you, I will use this as a workaround until it is ready to become an official one. :)

Tom Jaeger (thjaeger) wrote :

Tom Jaeger wrote:
> Packages will appear in my PPA in about 20 minutes.

Updated packages (+ppa3) are here:
http://ppa.launchpad.net/thjaeger/ubuntu/pool/main/a/acpi-support/

lujana (lujana-nakhodka) wrote :

Hi Tom!

Thanks. Great job !!!
Now almost everything works fine, except two volume keys. But they produce no acpi events at all.

Sika (sikamikaniboots) wrote :

I confirm this package solve the issue with an asus f3sv.
Thanks a lot!

Tom Jaeger (thjaeger) wrote :
Tim Gardner (timg-tpi) wrote :

Does not seem to be a kernel issue.

Changed in linux:
assignee: timg-tpi → nobody
importance: High → Undecided
assignee: timg-tpi → nobody
importance: High → Undecided
status: Triaged → Invalid
Joey Chan (ttdlx1989) wrote :

It IS kernel incompatibility, but the kernel behavior is correct.
Rather, the scripts were using unsafe (in terms of security) methods for generating fake keys.

Sergei Ianovich (ynvich-gmail) wrote :

I cannot see anything insecure in the way acpi_fakekey works. After all, it's a root-only feature.

More than that, 'setkeycodes' allows to achieve similar results to my proposed patch by mapping a wild guess keycode to the wanted keys. However, the solution is not portable, because it requires a keycode, which is guaranteed not to be present on all boxes.

Steve Langasek (vorlon) wrote :

acpi_fakekey (and acpi-support itself) is considered deprecated; mapping acpi events to input events should be handled by an in-kernel driver instead.

Who has the original keyboard with the KEY_WWW problem? Is this still a problem in Ubuntu 8.10? If so, please provide information about your laptop model.

Please see https://wiki.ubuntu.com/Hotkeys for information about hotkey handling and how to troubleshoot non-functional hotkeys.

Changed in linux:
status: In Progress → Confirmed
Tom Jaeger (thjaeger) wrote :

Steve Langasek wrote:
> acpi_fakekey (and acpi-support itself) is considered deprecated; mapping
> acpi events to input events should be handled by an in-kernel driver
> instead.
And until that happens we have a perfectly viable alternative using
uinput. Just saying.

> Who has the original keyboard with the KEY_WWW problem? Is this still a
> problem in Ubuntu 8.10? If so, please provide information about your
> laptop model.
I'm not that person, but it's evident from the description that the
problem is still present in the version of acpi-support that is in intrepid.

Michał Gołębiowski (mgol) wrote :

I've got ASUS A6B00U notebook (from A6U series). This is an issue for me.
OS: Hardy Heron 8.04.1
Kernel: 2.6.24-22-generic

Sika (sikamikaniboots) wrote :

I'd like a bit of clarification:
What needs to be done to solve this bug? An in-kernel driver?
Is there some work being done for that or is it waiting for someone to start?
Why does the proposed patch is not released until the 'perfect' solution is ready?

Steve Langasek (vorlon) wrote :

I've confirmed with the original submitter that the hotkey in question now works for him in jaunty, without the need of acpi_fakekey working; the linux task here is therefore either invalid or fixed.

acpi_fakekey itself, as well as all of acpi-support, is deprecated. If you are having problems with any other hotkeys in jaunty, please follow the directions at https://wiki.ubuntu.com/Hotkeys/Troubleshooting and file a new bug report on the correct package according to that page.

Changed in linux:
status: Confirmed → Invalid
Martin Pitt (pitti) wrote :

I just debugged the very same issue in bug 268429, and got to the same result. acpi_fakekey opens the right device and writes to it, but nothing happens for e. g. "150" (KEY_WWW).

As written in https://wiki.ubuntu.com/AcpiSupportDeprecation, we can either fix the kernel to convert *all* ACPI hotkey events to input key events, or keep acpi-support around to do this conversion in userspace.

Changed in linux:
status: Invalid → Triaged
Tom Jaeger (thjaeger) wrote :

acpi_fakekey is just broken, it's just unreasonable to send a key to a random keyboard device and expect that the kernel will let the event though the key isn't actually present on the keyboard.

If we decide to keep acpi_fakekey around, I think we should switch to uinput to get rid of these issues once and for all as proposed earlier in this bug report. See http://launchpadlibrarian.net/21350541/acpi-support_0.115_0.115%2Bthjaeger1.diff.gz for a suggested implementation.

By the way, the issue has been "fixed" on my thinkpad; the ThinkVantage button now calls acpi_fakekey on a different keycode that the kernel doesn't drop, but this issue is still present for example for KEY_WWW.

Thomas Hood (jdthood) wrote :
Thomas Hood (jdthood) wrote :

In Jaunty (4 March 2009), xev can now see the ThinkVantage keypress on my ThinkPad X61 and the ThinkVantage key can be assigned as a keyboard shortcut in GNOME.

However, the Zoom key (i.e., Fn-Space) is still not seen by xev.

acpi_listen can see both ThinkVantage and Zoom:

 $ acpi_listen
 ibm/hotkey HKEY 00000080 00001018
 ibm/hotkey HKEY 00000080 00001014

xev sees the ThinkVantage key this way:

 KeyPress event, serial 35, synthetic NO, window 0x4400001,
    root 0x91, subw 0x0, time 3068137, (74,831), root:(1406,883),
    state 0x10, keycode 156 (keysym 0x1008ff41, XF86Launch1), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

 KeyRelease event, serial 35, synthetic NO, window 0x4400001,
    root 0x91, subw 0x0, time 3068137, (74,831), root:(1406,883),
    state 0x10, keycode 156 (keysym 0x1008ff41, XF86Launch1), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

On Fri, Mar 06, 2009 at 07:08:56AM -0000, Thomas Hood wrote:
> In Jaunty (4 March 2009), xev can now see the ThinkVantage keypress on
> my ThinkPad X61 and the ThinkVantage key can be assigned as a keyboard
> shortcut in GNOME.

> However, the Zoom key (i.e., Fn-Space) is still not seen by xev.

Correct. X can only handly 256 distinct keycodes due to a protocol
limitation, and due to evdev the keycodes are now standardized to match the
Linux input layer - with no keycode below 256 that could reasonably be
substituted for KEY_ZOOM.

As a workaround, you can add your own fdi file to /etc/hal/fdi/information
that maps this key to a different keycode (see
/usr/share/hal/fdi/information/10freedesktop/30-keymap-module-thinkpad-acpi.fdi
for an example of how this is currently done).

But this is unrelated to acpi_fakekey, which is not needed for ThinkPad keys
at all. For concerns about specific hotkeys not working, please open
separate bug reports; this bug report should be reserved for the matter of
acpi_fakekey itself working, rather than being used as a metabug for all the
myriad individual hotkey issues.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

Thomas Hood (jdthood) wrote :

Thanks for the information.

I will pursue the Zoom key issue at #267682.

lujana (lujana-nakhodka) wrote :

@Tom Jaeger

Tom, could you make a separate patch for acpi_fakekey for 9.04 though the acpi bag is fixed but fake_key is not working

Sorry, I don't have the time to keep the patch up to date and it is my
understanding that most multimedia keys are be handled by the kernel at
this point, so this should be largely unnecessary.

The patch for 0.115 is still available at

http://launchpadlibrarian.net/21350541/acpi-support_0.115_0.115%2Bthjaeger1.diff.gz

you might want applying it against the current version of acpi-support.

lujana wrote:
> @Tom Jaeger
>
> Tom, could you make a separate patch for acpi_fakekey for 9.04 though
> the acpi bag is fixed but fake_key is not working
>

Steve Langasek (vorlon) wrote :

acpi-support is deprecated, and acpi_fakekey is not going to be fixed. Hotkey synthesis should always happen within the Linux kernel instead.

Changed in linux (Ubuntu):
status: New → Fix Released
Changed in acpi-support (Ubuntu):
status: Triaged → Won't Fix
Changed in debian:
status: New → Fix Released
Julian Wiedmann (jwiedmann) wrote :

This release has reached end-of-life [0].

[0] https://wiki.ubuntu.com/Releases

Changed in linux (Ubuntu Hardy):
status: New → Invalid
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.