Hello Richard, On Sun, 10 Jun 2007, Richard Hughes wrote: > On Sat, 2007-06-09 at 16:41 -0300, Henrique de Moraes Holschuh wrote: > > 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. I am almost done with the first part of the input patches, and the final QA scenarios check shows that the approach I currently use could be made a lot better if we do it a little different. Currently, thinkpad-acpi defaults to most hot keys disabled, AND the hot key system disabled. This is the firmware default, for obvious reasons (DOS/unknown O.S. support using the BIOS). This is also true for all versions of ibm-acpi. It can, of course, be overriden by module parameters. This means distros and HAL will go around poking the hotkey_ attributes anyway, which will cause all sort of trouble overriding the local system admin wishes anyway. So I think a change of strategies will be needed. Here's my new proposal: 1. Activate hot key handling and input device handling, with most keys already mapped by default in thinkpad-acpi. THIS DOES NOT, and WILL NOT enable brightness up/down, volume up/down, mute, and thinklight mappings. A new enough HAL that can handle them in passive mode will have to do it by itself (see below). 2. Add a kernel compile-time option to default to the current behaviour (not activate hot key handling by default, start with an empty input device map, which means ACPI events are the default when hot keys are enabled). For HAL, that means that: 1. HAL *must not* modify the hotkey_enable attribute. If it is zero, either it is talking to old thinkpad-acpi, or the user wants it like that. Don't change it. A HAL-friendly thinkpad-acpi will have hotkey_enable set to 1 by default. 2. IF HAL loads CMOS NVRAM monitors like tpb or thinkpad-keys, it should not do so if hotkey_all_mask & 0x00ff0000 is non-zero. 3. HAL will have to program the passive hot keys itself (keys that are only to be used for OSD reporting: volume up/down, mute, brightness up/down, thinklight). And I would leave the thinklight out of it, IMHO it is goofy to pop up an OSD saying "thinklight ON/OFF" when the user can *clearly* see when it is turned on/off to begin with... These keys will be set to KEY_RESERVED in the keyboard map when thinkpad-acpi loads. All others will be set to either KEY_UNKNOWN or to a real key. What do you think? -- "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
