On 7/15/07, Henrique de Moraes Holschuh <hmh@xxxxxxxxxx> wrote:
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.
I am unconvinced that input layer is the proper place to add such information. These are events signalling state change of some device. In case of volume changes these events do not refect change in keyboard state but rather some other device (sound card) so I would expect these events be coming from there. I also do not want to convert input layer into kitchen sink of generic userspace notifications. Laptop "battery removed" does not belong to input. "Network cable removed" does not belong to input. "Hard driver dying" does not belong to input.
> > 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.
How do you know that this is a "passive keypress"? Can you put another (better) soundcard in a docking station? Woudl the firmware still control that card (doubtful)? Do we want the same keys to control that card's volume? -- Dmitry - 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
