Matthew Garrett wrote:
The problem in that case is that the kernel changes the backlight for us. The lack of consistency on this front makes life somewhat harder. In terms of the "Some hardware sends keyboard events but also changes the brightness", I'm working on a cleaner solution for this. The easiest would seem to be to generate a uevent when the backlight is changed, which would then allow userspace to pop up UI even though the key press events aren't propagated. It would seem to deal with the Eee (and older Thinkpad) cases quite nicely, but does require some more code in userspace.
Ok. Maybe it's trivial or "niche", but I really appreciate this. I think it's the only remaining issue I have with my EeePC :-).
I just saw the patch to generate uevents for the acpi video driver. It looks like it still generates KEY_BRIGHTNESSDOWN. Are you planning a followup patch, to suppress the input events when brightness_switch_enabled == 1?
Equally, w.r.t patch 3, I don't think eeepc-laptop, should generate brightness events on the *input* device anymore.
The rationale is that KEY_BRIGHTNESSDOWN is a user request to increase brightness. In these cases, the firmware/driver has already increased the brightness. We've notified userspace via the backlight device. So we shouldn't pass the request on to userspace; it has already been acted upon. If we still generate KEY_BRIGHTNESS*, userspace has to guess whether or not the change has already been applied. If there is too much latency, it guesses wrong :-(.
Thanks! Alan -- 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
