On Mon, 21 May 2007, Richard Hughes wrote: > On Mon, 2007-05-21 at 10:05 -0300, Henrique de Moraes Holschuh wrote: > > There is no way around that. It is how these things work. You are actually > > requesting to the firmware that "OSI will handle these hotkeys". > > On all models? When I enable my hkeys on my X60, the hardware still does > the actions. Argh. Even for keys that are masked out? > > And I suspect we are missing part of the interface on the X60 new BIOS, too. > > Is a X60 onwer up to some DSDT debugging ? > > I have an X60, although the bios is 2.03 iirc. I'd appreciate a report on how it works in a X60 with the latest BIOS (2.10). Anyone? > > It is a binary attribute, that looks like a little-endian file composed of > > u16 values. Read from it to get the current hotkey->keycode map, write to > > it to change the mapping. There are 16 keycodes right now, but if we find > > out the hotkey interface in ACPI can be extended, it will grow. > > > > KEY_RESERVED disables the issuing of input events for that key. Anything > > else (valid) enables it, including KEY_UNKNOWN. > > > > Would HAL need to mess with these? If it does, it means I need to add a > > lock attribute that disables changes to it (which HAL is *not* allowed to > > touch) so as to allow the admin to preserve his setup. > > Well, at the moment the input stuff is al up in the air, and so we can > do this anyway that works. My preference is as much stuff in the kernel, > and then do the fancy stuff in HAL. Do you intend to do any sort of "this is a thinkpad model foo, let's program thinkpad-acpi to use keycode map bar" in HAL? If so, I need the lock. > > > Also, is the aim to deprecate or remove the hotkey events, or shall I > > > add workarounds to HAL so we don't get double events? > > > > There is a bit of a problem. The ACPI hotkey events are complete, and can > > handle *anything* the firmware produces as long as there is code in > > thinkpad-acpi to intercept the events. > > Sure, but currently usersapce is unaware of the ibm acpi events, unless > HAL proxies them using DBUS. This is obviously non-ideal. No, _userspace_ is quite well aware of them. acpid gets them just fine. > > Is there an event we can send through the input layer capable of carrying a > > 16-bit value ? Otherwise, I can remove the ACPI events, but I'd have to add > > generic uevents to replace them. > > What sort of value? If it's not a keypress then a uevent seems most sane > IMO. It is a key press, sort of. But one that is not mapped, or which is new. Borislav mentions lid switches and buttons on docks also creating hotkey events, but I have *never* seen those, and nobody documented any in thinkwiki either. -- "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
