Comment 4 for bug 145337

I have the same symptoms as the OP on my up-to-date ThinkPad T60 running Kubuntu. Brightness keys do not work even though "lshal -m", "acpi_listen", and acpid all see them/do the right thing. No OSD from kmilo anymore either, for anything, even volume or thinklight which work (probably only because they are done in hardware). This all worked several weeks ago, and has actually always worked up until then. Guidance can still adjust the brightness with the slider.

Although it's not related directly to this bug, I tend to think it's not coincidental that my lock (Fn-F2, used to lock the session I think, I didn't use it much), battery (Fn-F3, which used to cause guidance-power-manager to show it's tooltip), suspend (Fn-F4), and suspend-to-disk keys (Fn-F12) do not work right anymore either, and broke at the same time. Their implementations in /etc/acpi and so forth are also all similar, only generating various fake keys (see below).

The biggest problem with my troubleshooting is that I can't understand/find information on the big picture, how is this mechanism supposed to work at all to begin with. I seem to remember (although admittedly not infallibly) that the scripts in /etc/acpi used to actually modify the brightness (and perform the other key actions) directly thru /sys or /proc somehow. Now all they appear do is synthesize keystrokes using acpi_fakekey. This works right too, xev for example sees these fake keystrokes (although many of them do not have keysyms). But, is some program supposed to receive these keystrokes and perform the action? Or am I barking up the wrong tree? What is HAL's role, if any, in making this work?

After the fake key generation, I lose the trail. Any clues? This is a terrible nuisance because I use(d) these keys frequently. Being night-blinded by your laptop is not cool :)