On Sun, Jul 15, 2007 at 06:54:53PM -0300, Henrique de Moraes Holschuh wrote: > On Sun, 15 Jul 2007, Matthew Garrett wrote: > > 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? If they're Thinkpad-specific, they're already doing the right thing. If they're specific to another model, they're not running on a Thinkpad. > > 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. That's fine. You know that the event came from an external keyboard, so you know that it has to be handled actively. > 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. As I said, the existing userspace implementation disagrees. I'd prefer to avoid breaking that. -- Matthew Garrett | mjg59@xxxxxxxxxxxxx ------------------------------------------------------------------------- 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
