Intrepid: kernel acpi event -> acpid -> /etc/acpi/*btn.sh -> acpi_fakekey -> /dev/input/eventX -> X server -> *splat*
It seems that the X server grabs the relevant /dev/input/eventX with ioctl(EVIOCGRAB), which means it gets exclusive access to the events, so hald-addon-input never hears them.
Probably what we want in the end is:
kernel acpi event -> hald-addon-acpi -> hald
but that won't fly for Intrepid as it would require ripping and replacing acpi-support with hal FDI files.
With some help from Dustin Kirkland and Julien Cristau on IRC, I have a working theory for what's causing this:
Hardy: kernel acpi event -> acpid -> /etc/acpi/*btn.sh -> acpi_fakekey -> /dev/input/eventX -> hald-addon-input -> hald
Intrepid: kernel acpi event -> acpid -> /etc/acpi/*btn.sh -> acpi_fakekey -> /dev/input/eventX -> X server -> *splat*
It seems that the X server grabs the relevant /dev/input/eventX with ioctl(EVIOCGRAB), which means it gets exclusive access to the events, so hald-addon-input never hears them.
Probably what we want in the end is:
kernel acpi event -> hald-addon-acpi -> hald
but that won't fly for Intrepid as it would require ripping and replacing acpi-support with hal FDI files.
For Intrepid, we could try to get this working:
kernel acpi event -> acpid -> hald-addon-acpi -> hald
I believe hald-addon-acpi has native support for the weird thinkpad ACPI events.
OR, we could try to make the input events work somehow. If X insists on exclusive access, something in the session would need to listen for them.