On Mon, 2007-05-21 at 14:03 -0300, Henrique de Moraes Holschuh wrote: > 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? Yup. > > > 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? I'll update this afternoon and send you the latest DSDT. > > > 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. I don't think so. Maybe not HAL, probably a keymap was my first choice. > > > > 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. Sure, but what does IBM 0x000 0x005 mean to a random program like NetworkManager? If this is the bluetooth disable key, then this should be nicely abstracted IMO, not discovered by every application author listening to acpid. > > > 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 Already covered in the acpi-core button events. > and buttons on docks also creating hotkey > events, but I have *never* seen those, and nobody documented any in > thinkwiki either. Sure, we can map those to the proper buttons. 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
