On Mon, Jul 16, 2007 at 03:19:11PM -0300, Henrique de Moraes Holschuh wrote: > Anyway, if the input layer is really not the place for "passive key > presses", then my decision to not issue input events for such stuff is the > correct one. That wasn't my interpretation of what Dmitry said - it's not a generic event layer, but when you have keys that generate events that would be useful to userspace then I think it makes absolute sense to send them. > Brightness can be notified through ACPI (ACPI 3.0b has standard events for > this), or it could be done through an improved backlight sysfs class. It > will require work either way, because you don't want ACPI video processing > these synthezised events, or because you need to get backlight to be > poll()/select() or inotify()-friendly if you don't want to add another > dumbass userspace polling loop. The simple fact of the matter is that when you get outside the range of the standard qwerty keys, the semantics of the buttons become hardware dependent. The behaviour of KEY_SWITCHVIDEOMODE is going to vary wildly between hardware. Wlan control may be active or passive (and the standard adopted there appears to be to send KEY_WLAN regardless). Dells will trigger a dock unplug event automatically if you hit the dock unplug button - Thinkpads won't. I think it makes absolute sense to get these notifications in the same way wherever possible, and then let userspace handle them as appropriate. On modern Thinkpads I need to alter whichever backlight interface is most appropriate to the machine in question (something that itself is going to differ between Thinkpads and, say, Macs) whereas in older ones I just want to pop up a notification with the new brightness. I realise your concern about breaking existing userspace, but as far as I can tell there /is/ no existing userspace to break. Hal does the right thing already, and there's nothing else that listens for key brightness events on Thinkpads. > Built-in headphone/speaker volume can be notified and controlled through an > ALSA mixer. It won't be a nice poll-less thing, but I can trap the ACPI hot > key events as a hint to update the mixer state, and if ALSA lets me do it, > issue mixer changed notifications. ALSA lets you do that. -- Matthew Garrett | mjg59@xxxxxxxxxxxxx - 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
