Hi, I was just wondering, why the Thinkpad special keys don't work when I use a Debian kernel instead of my home-grown one and I stumbled over this bug report ...
> Well, I just looked at the most up-to-date acpid, and it supports > netlink. > > Therefore, the issue is just that thinkpad-acpi wants you to get > hotkeys from the input layer since kernel 2.6.23, Fair enough. But who gets them? > and now finally the > borrowed time is over in Debian installs, with the procfs event > delivery being shut off. Which leaves users out in the cold. > What I wrote about a thinkpad-apci backwards compatibility mode was > slightly incorrect... teaches me to trust memories over one year old > about stuff I never had to look back at, before writing something. > The non-hotkey events go over netlink, yes. But hotkeys go only over > the input device, where they belong, and there is no driver switch to > mess with that. That's wrong. The default as of 2.6.31 is still to deliver them as both, input events and ACPI events (see the `hotkey_report_mode' parameter of thinkpad_acpi). But the ACPI events are only delivered through the legacy interface /proc/acpi/event and not through netlink. > This means that all configs that use acpid to process thinkpad-acpi > hotkeys will break, and need to be ported over to HAL or something > else that binds to input devices. You are kidding, right? You don't seriously suggest that I have to install HAL, D-BUS daemons and what not to be able to hibernate or switch WIFI on and off. > I think these bugs can be tagged "wontfix", and we just deal with it > as the usual perils of using "unstable" and "testing". It is > probably a good idea to leave them open in the BTS for a while, in > hopes that people will read them before filing more bugs. Thanks for that. > I don't think it affects any Debian standard config, but it will > affect most of the local configs by end-users. I would like to use a Debian standard config, however there doesn't seem to be any alternative to acpid handling these events (HAL is _not_ an alternative). So what is the standard? I haven't found any daemon that listens to input events and executes actions on them, like acpid does. The only thing available is inputlirc, but that just routes them to a socket which doesn't really gain you anything. So either acpid is extended to also listen to button events, or a daemon is provided, that does this. Until then, the only alternative is to support /proc/acpi/event so acpid can be used for the extra buttons. Cheers, harry
signature.asc
Description: PGP signature
