Hi Matthew! On Sun, 15 Jul 2007, Matthew Garrett wrote: > On Sun, Jul 15, 2007 at 02:59:22PM -0300, Henrique de Moraes Holschuh wrote: > > On Sat, 14 Jul 2007, Matthew Garrett wrote: > > > > > On Sat, Jul 14, 2007 at 11:12:09AM -0300, Henrique de Moraes Holschuh wrote: > > > > > > Ah, I see this one fixes some of my comments. However: > > > > > > > + KEY_RESERVED, /* 0x0F: FN+HOME (brightness up) */ > > > > + /* Scan codes 0x10 to 0x1F: Extended ACPI HKEY hot keys */ > > > > + KEY_RESERVED, /* 0x10: FN+END (brightness down) */ > > > > > > > + KEY_BRIGHTNESSUP, /* 0x0F: FN+HOME (brightness up) */ > > > > + /* Scan codes 0x10 to 0x1F: Extended ACPI HKEY hot keys */ > > > > + KEY_BRIGHTNESSDOWN, /* 0x10: FN+END (brightness down) */ > > > > > > Why this difference? > > > > Brightness events are handled in firmware (and no, you cannot make the > > firmware NOT handle it) in IBM thinkpads. Lenovo thinkpads seem to be > > moving it to userspace, so you have to generate the events and actively > > handle them in the ACPI OSI or in userspace. > > I believe that this is dependent on the BIOS version, not whether the > distinction is Lenovo/IBM. Let's just say that IBM kept a certain behaviour consistent for all BIOS versions, and Lenovo is not following that behaviour. It might be considered a BIOS version thing, where all IBM-release BIOSES behave in one way, and most Lenovo ones behave in another way. But unless someone will start tracking the required information for me in thinkwiki or somesuch, I will only support the latest versions of a ThinkPad BIOS as a rule. IBM and Lenovo BIOS updates fix a damn big lot of problems quite often. It is not a good idea to use outdated ones, especially the EC firmware, anyway. > > Regardless, userspace *will* have to take some action to enable the hotkeys > > that are to only be used for passive monitoring. Right now this means > > enabling them in the mask, and remapping the key map. If this is that a big > > problem, I can add extra driver filtering, and make it only "enable it in > > the mask". > > HAL already has a flag indicating whether applications should respond to > brightness keys actively or passively. Life would be significantly > easier if they're mapped by default, since the alternative is that > everyone will just map them anyway. Life would be significantly easier if I could convey that information in the kernel. Since I cannot, I effectively consider these keys to be "defective" as far as the regular input device events are supposed to mean, and I don't generate events for them. -- "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 - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
