Re: [ibm-acpi-devel] ACPI: thinkpad-acpi: make the input event mode the default
On 7/15/07, Henrique de Moraes Holschuh [EMAIL PROTECTED] wrote: On Mon, 16 Jul 2007, Matthew Garrett wrote: Having checked other drivers, it looks like KEY_SWITCHVIDEOMODE is the one used for video toggling. If that's not actually how people are using it, we need to fix that - if it is, I'd just go for it. This looks like a breakage warning to me. Better decide once and for all what this keycode is supposed to do, and document it. Because switching video mode is not switch video output mode, and can easily be confused with switch screen resolution, switch video mode between expanded and normal or whatever. I will add a comment to input.h to the effect that KEY_SWITCHVIDEOMODE is to switch between available outputs (LCD/Monitor/TV-Out/Whatnot). Right now couple of RCs are using it for different purposes (cycling through inputs I think) so we should do somethig about these. -- Dmitry - 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel
Re: [ibm-acpi-devel] ACPI: thinkpad-acpi: make the input event mode the default
On Mon, 16 Jul 2007, Dmitry Torokhov wrote: I will add a comment to input.h to the effect that KEY_SWITCHVIDEOMODE is to switch between available outputs (LCD/Monitor/TV-Out/Whatnot). Right now couple of RCs are using it for different purposes (cycling through inputs I think) so we should do somethig about these. I will add KEY_SWITCHVIDEOMODE to FN+F7 (thinkpad cycle output video port key), then. -- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel
Re: [ibm-acpi-devel] ACPI: thinkpad-acpi: make the input event mode the default
On Sun, 15 Jul 2007, Matthew Garrett wrote: On Sun, Jul 15, 2007 at 03:05:29PM -0300, Henrique de Moraes Holschuh wrote: On Sat, 14 Jul 2007, Matthew Garrett wrote: Again, we have keycodes for most of these and we have the ability to make the driver choose the correct one by default. Why make things more difficult? Because I only map keys that are marked (silk-screened) on the keys on at least 90% of the current models. But we're able to differentiate between the models. Yes. And I was told to not do it in the kernel when possible, so I will map by default only what is marked and working on a vast majority. Otherwise, I'd need a big quirk db, based on what is silk-screened on the keyboards. HAL is welcome to remap the keys to whatever it wants, based on model-specific fdi files. And I could not find the proper keycode for switch output video port, yet. Yes, that's a good point. Dmitry? As vendors move towards adopting the ACPI video extension and getting the OS to look after this, we could really do with a standardised code. Well, that one I will add as soon as I get it :-) All thinkpads I know the keyboard layout have FN+F7 mapped to switch output video port. But I have seen a lot of non-thinkpad notebooks with set output port to LCD and set output port to vga out keys as well. -- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel
Re: [ibm-acpi-devel] ACPI: thinkpad-acpi: make the input event mode the default
On Sun, 15 Jul 2007, Matthew Garrett wrote: On Sun, Jul 15, 2007 at 05:09:48PM -0300, Henrique de Moraes Holschuh wrote: On Sun, 15 Jul 2007, Matthew Garrett wrote: But we're able to differentiate between the models. Yes. And I was told to not do it in the kernel when possible, so I will map by default only what is marked and working on a vast majority. Otherwise, I'd need a big quirk db, based on what is silk-screened on the keyboards. We already have in-kernel drivers that do this properly, so I'd suspect that whoever told you that was wrong. I got tired of being told one way or the other, already. My position is simple, for now: I am keeping model-specific knowledge on the driver to the bare minimum needed for correct driver operation. But I will add it anytime I fell it is needed to keep correct driver operation. The different lenovo/ibm keymaps were added because of the mess with the brightness and volume keys in the latest BIOSes. -- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel
Re: [ibm-acpi-devel] ACPI: thinkpad-acpi: make the input event mode the default
On Mon, 16 Jul 2007, Matthew Garrett wrote: On Sun, Jul 15, 2007 at 09:12:40PM -0300, Henrique de Moraes Holschuh wrote: On Sun, 15 Jul 2007, Matthew Garrett wrote: No, it doesn't. It interacts in a way that you may not consider to be ideal - the vast majority of our users appear to prefer it to the previous behaviour, so it's better than nothing. I don't go for better than nothing, when there is a way to have it right (and there is: an alsa mixer, or an extension to the input layer). Certainly. Once it's possible to do it the right way, we can do it the right way :) I can priorize one thing over another. HAL guys, please chose which one I shall work on first (non-zero chance of it getting ready before the merge window closes): 1. ALSA mixer interface for the thinkpad speakers-and-headphone-out volume control 2. CMOS NVRAM snooping support for transparent handling of non-acpi-event- enabled hot keys (i.e. tpb functionality). Needed by every thinkpad before the T43, and apparently, by the R60 for the thinkpad button. The only code currently listening for KEY_BRIGHTNESS* on Thinkpads is gnome-power-manager, and that uses the Hal information to check whether What about KDE? Doesn't it have any helpers? We've been listening for KEY_BRIGHTNESS* on Thinkpads for over a year. It's already implemented and works fine. If everything did it right, I would have never heard of it. Note that I am not accusing HAL of breakage, I am talking about *userspace*. I am *not* sure if hal is what broke it, and, if it indeed was hal, whether it was new enough. I am sure bleeding-edge hal does something sensible for brightness, and I have no reasons not to believe you that one-year-old hal will do something wrong, either. But there is other userspace, AND much older hal. We had a broken version of hal in a development version of Ubuntu. No release version (of Ubuntu or hal) has ever had this bug. What about other distros? Ubuntu isn't the world, anymore than HAL is all that matters in userspace. A broken version of HAL might explain the bug report, or it might not. I'd have to track it down, and frankly, I'd rather spend precious kernel hacking time with either option (1) or option (2) above instead. Oh, I miss an undock/eject generic device keycode, too. Can't use EJECTCD to undock... Again, what you want me to change in that default key code matrix that is not a passive-action key? I aimed to do the best I could according to the info I have (http://thinkwiki.org/wiki/Default_meanings_of_special_keys). Having checked other drivers, it looks like KEY_SWITCHVIDEOMODE is the one used for video toggling. If that's not actually how people are using it, we need to fix that - if it is, I'd just go for it. This looks like a breakage warning to me. Better decide once and for all what this keycode is supposed to do, and document it. Because switching video mode is not switch video output mode, and can easily be confused with switch screen resolution, switch video mode between expanded and normal or whatever. As for the passive keys - I can (with a very high level of certainty) assert that there is no existing userspace that will be broken by sending the brightness keys. We can quibble over the volume ones, but even there the breakage is minimal. Can't we just fix the damn thing instead? I am really, really grossed out by that abuse of the input layer. -- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel
[ibm-acpi-devel] ACPI: thinkpad-acpi: make the input event mode the default
Make the input layer the default way to deal with thinkpad-acpi hot keys, but add a kernel config option to retain the old way of doing things. This means we map a lot more keys to useful stuff by default, and also that we enable hot key handling by default on driver load (like Windows does). The documentation for proper use of this resource is also updated. Signed-off-by: Henrique de Moraes Holschuh [EMAIL PROTECTED] Cc: Richard Hughes [EMAIL PROTECTED] --- Documentation/thinkpad-acpi.txt | 89 ++- drivers/misc/Kconfig| 12 + drivers/misc/thinkpad_acpi.c| 19 +++- 3 files changed, 69 insertions(+), 51 deletions(-) diff --git a/Documentation/thinkpad-acpi.txt b/Documentation/thinkpad-acpi.txt index 91d0892..5b59cf5 100644 --- a/Documentation/thinkpad-acpi.txt +++ b/Documentation/thinkpad-acpi.txt @@ -155,52 +155,47 @@ Hot keys procfs: /proc/acpi/ibm/hotkey sysfs device attribute: hotkey_* -Without this driver, only the Fn-F4 key (sleep button) generates an -ACPI event. With the driver loaded, the hotkey feature enabled and the -mask set (see below), the various hot keys generate ACPI events in the +In a ThinkPad, the ACPI HKEY handler is responsible for comunicating +some important events and also keyboard hot key presses to the operating +system. Enabling the hotkey functionality of thinkpad-acpi signals the +firmware that such a driver is present, and modifies how the ThinkPad +firmware will behave in many situations. + +When the hotkey feature is enabled and the hot key mask is set (see +below), the various hot keys either generate ACPI events in the following format: ibm/hotkey HKEY 0080 -The last four digits vary depending on the key combination pressed. -All labeled Fn-Fx key combinations generate distinct events. In -addition, the lid microswitch and some docking station buttons may -also generate such events. - -Hot keys also generate regular keyboard key press/release events through -the input layer in addition to the ibm/hotkey ACPI events. The input -layer support accepts the standard IOCTLs to remap the keycodes assigned -to each hotkey. +or events over the input layer. The input layer support accepts the +standard IOCTLs to remap the keycodes assigned to each hotkey. When the input device is open, the driver will suppress any ACPI hot key events that get translated into a meaningful input layer event, in order to avoid sending duplicate events to userspace. Hot keys that are -mapped to KEY_RESERVED are not translated, and will always generate only -ACPI hot key event, and no input layer events. - -The bit mask allows some control over which hot keys generate ACPI -events. Not all bits in the mask can be modified. Not all bits that can -be modified do anything. Not all hot keys can be individually controlled -by the mask. Some models do not support the mask at all. On those -models, hot keys cannot be controlled individually. - -Note that enabling ACPI events for some keys prevents their default -behavior. For example, if events for Fn-F5 are enabled, that key will no -longer enable/disable Bluetooth by itself. This can still be done from -an acpid handler for the ibm/hotkey event. - -On some models, even enabling/disabling the entire hot key feature may -change the way some keys behave (e.g. in a T43, Fn+F4 will generate an -button/sleep ACPI event if hot keys are disabled, and it will ignore its -mask when hot keys are enabled, so the key always does something. On a -X40, Fn+F4 respects its mask status, but generates the button/sleep ACPI -event if masked off). - -Note also that not all Fn key combinations are supported through -ACPI. For example, on the X40, the brightness, volume and Access IBM -buttons do not generate ACPI events even with this driver. They *can* -be used through the ThinkPad Buttons utility, see -http://www.nongnu.org/tpb/ +mapped to KEY_RESERVED in the keymap are not translated, and will always +generate an ACPI ibm/hotkey HKEY event, and no input layer events. + +The hot key bit mask allows some control over which hot keys generate +events. If a key is masked (bit set to 0 in the mask), the firmware +will handle it. If it is unmasked, it signals the firmware that +thinkpad-acpi would prefer to handle it, if the firmware would be so +kind to allow it (and it often doesn't!). + +Not all bits in the mask can be modified. Not all bits that can be +modified do anything. Not all hot keys can be individually controlled +by the mask. Some models do not support the mask at all, and in those +models, hot keys cannot be controlled individually. The behaviour of +the mask is, therefore, higly dependent on the ThinkPad model. + +Note that unmasking some keys prevents their default behavior. For +example, if Fn+F5 is unmasked, that key will no longer enable/disable +Bluetooth by itself. + +Note also that not all Fn key combinations are supported through ACPI. +For
