On Wed, 2007-06-13 at 11:05 -0300, Henrique de Moraes Holschuh wrote: > 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. Sure, but just opening the device is not remapping the keys - it's a two step process. > 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). Sure, seems sane. > > 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. Non ideal, but yes, we can cope with this if we have to. A module parameter might be even better for distros. > > 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. Well, I could argue, but I appreciate you're the maintainer and you have to answer the snotty emails when stuff breaks. :-) <usual quotes about kernel ABI go here...> > > 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. Yes, although I've had no luck with this on my X60. Ideas welcome. > > 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? Correct. Richard. ------------------------------------------------------------------------- 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
