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. > I can only think of a few ways to go about it: > > 1: always generate both events (may cause problems for sleep to disk and > sleep to ram, at the very least) Both events are a pain for HAL to handle, although possible. > 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. > 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. > And the default of 2 and 3 will be bad for input/HAL, because it either will > require a module parameter or a write to sysfs to enable input hotkeys, > otherwise it would break the ACPI event ABI (because ACPI events would not > be generated anymore). There is no ABI for acpi hkey events, it's just the bodge that we've been using for years because the ACPI maintainers did not want to depend 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). 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 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. So please, make the default input, as all the other drivers we are working on (asus, sony, toshiba) will be slowly converted to use input by default, and it would be a crying shame for thinkpad_acpi to be the only "legacy" driver that needed odd options in rc.local just to get the keys working. 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
