On Sun, 15 Jul 2007, Matthew Garrett wrote: > On Sun, Jul 15, 2007 at 05:59:34PM -0300, Henrique de Moraes Holschuh wrote: > > *HAL* does. HAL is *not* all there is to userspace. The input layer is not > > an interface between the kernel and HAL, it is an interface between kernel > > and userspace. > > Hal is the only piece of userspace that knows how to speak to more than > one type of backlight in any useful way, which makes it the de-facto > reference for how userspace interprets these keys. Since when does system-specific programs not count? Anyway, the idea of "special cases" that are not exposed anywhere and requires out-of-band information to be handled correctly is just broken IMO. This goes triple for an interface whose only canon documentation is the current kernel code, so you can't even tell people to read somewhere how to properly use it. Since we have detected the need for passive events, I'd much rather that information was added to the input layer itself, instead of being synthesized later. > > Add that knowledge to the input layer, and I will agree. Add it to every > > consumer of input events, and I will concede. Until then, it is good that > > HAL can overcome the lack of such information in the input layer, but that > > doesn't make it the right way to use the input layer. > > The fact that keys share event codes doesn't mean that these keycodes > are going to have identical semantics on all hardware. One solution to > that would be to avoid ever sending these keycodes, but that would make > having them defined in the first place a bit silly. Since they /are/ > there, it makes sense to use them. I see a keycode defined in the USB HID spec for use in stuff that only knows active handling -- passive doesn't even make any sense for them -- and its reflect on the kernel input layer. There _are_ a few platforms where *one* of the built-in devices need a different handling, and that's just because the firmware won't cooperate. But if I plug a USB keyboard on a thinkpad, for example, I need the proper (active) handling of the event. I definately think "avoid ever sending these keycodes" in this instance is the right way to go, until we can actually issue a "this is a passive key press" event. -- "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
