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? ** Attachment added: "acpi_fakekey.c" http://launchpadlibrarian.net/19907781/acpi_fakekey.c -- acpi_fakekey stopped working for certain keycodes https://bugs.launchpad.net/bugs/217504 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
