On Sun, 10 Jun 2007, Richard Hughes wrote: > On Sat, 2007-06-09 at 16:41 -0300, Henrique de Moraes Holschuh wrote: > > Now that KEY_UNKNOWN as the top choice is gone, and that HAL seems to want > > to map keys by default, the solution I used to not generate hotkey input > > events and ACPI events in duplicate is busted. > > Why busted? Legacy systems with acpid running and processing updates get > the notification events from ACPI, and newer systems using HAL map the > keys, and then INPUT events are used. We can disable the keymap stuff in > hal trivially if an admin wants to. Seems ideal to me. Hal opens all input event devices. When it does that, thinkpad-acpi stops generating ACPI events for all hotkeys that have a proper mapping. I could just leave all keys mapped to KEY_UNKNOWN anyway (in the name of ibm-acpi backwards compatibility in this case -- this is not something I'd expect other drivers to need to do, it is a very particular issue), so that if it is not a new-enough HAL+hal-info that knows that it needs to remap the keys according to the thinkpad model, the feature will lay dormant (unless the local admin remaps the keys himself, which is also very fine). What do you think? > > 2: allow the user to select which one using an extra mask in sysfs, default > > is ACPI > > Nope, because then we have to hack something in rc.local to set the key > on every boot. For one, if this were the case, every fedora install > would have this enabled by default. That would not be so bad, as one expects that fedora would do it along with the rest of the stuff in userspace that *expects* the hotkeys to be delivered over input, and not ACPI. > > 3: allow the user to select which one using a module parameter, default is > > ACPI > > This is preferable, with the default changed to INPUT, see below. No can do, we are talking about backwards compatibility here. If you do nothing, behaviour should stay the same and not migrate to input. > There is no ABI for acpi hkey events, it's just the bodge that we've There IS one for ibm-acpi. And it is a few years old and stable, at that. There is no generic one, but that doesn't matter here. > on INPUT in acpi core. Now the ACPI guys are in agreement that button > events should be handled in the abstract INPUT layer, and have even > converted internal modules to use input (e.g. button.c). Yep. So far so good. But doing it breaking userspace all around is not something I will do, unless there is no other sane choice. > Most of the acpi guys for the main distros agree that using hkeys acpi > events is broken, and there is no less than 12 (that I know about) hacky > daemons to capture the vendor specific scancodes and either run commands > as root, or inject them back into the kernel using uinput. This is not > something that I want to continue. I agree. I want to see the end of all thinkpad nvram snooping daemons, and other stuff that gets everything wrong all the time, too. Especially if we find a way to tap into the ACPI interrupts the low-level firmware does generate when it changes the NVRAM bits. > I understand you want to preserve compatibility, but that can be done > with either the KEY_UNKNOWN checks you are currently doing in the > input-hotkey branch, or with a use_acpi_events=1 module parameter. KEY_UNKNOWN appears to be the best choice for thinkpad-acpi, then. I understand HAL is going to re-map these keys to something when it loads up, and NOT use them as KEY_UNKNOWN, correct? -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ ibm-acpi-devel mailing list ibm-acpi-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel
