Corentin Chary wrote: > On Tue, Jul 28, 2009 at 10:04 PM, Matthew Garrett<mjg59@xxxxxxxxxxxxx> wrote: > >> On Tue, Jul 28, 2009 at 09:51:09PM +0200, Corentin Chary wrote: >> >> >>> No answers. >>> I think I'll implement that as a backlight, because it is a backlight >>> even if it's not for a screen. >>> >> I believe the SMC driver for the Apples does it via LED, so it might >> make sense to be consistent with that. >> >> -- >> Matthew Garrett | mjg59@xxxxxxxxxxxxx >> >> > > So it will be a led. > I think you should also match the LED name used by the apple driver. As far as I know it's the only sensible way for userspace to identify the LED. The SMC driver uses "smc::kbd_backlight", so something like "eeepc::kbd_backlight". > There is another problem, Fn+F3/F4 generate ACPI events > > Fn+F3 : hotkey ATKD 000000c5 00000000 > Fn+F4 : hotkey ATKD 000000c4 00000000 > > Fn+F3: decreases keyboard brightness > Fn+F4: increases keyboard brightness > > Should we handle these events with acpi scripts or directly in the driver ? > IMHO it can be done directly in the driver, like LCD On/Off keys. > Here's my opinion based on no experience and 10 minutes with google :-). Userspace should take charge of changing the brightness. It would be good to generate input events (KEY_KBDILLUMUP etc) as well though. Hopefully hald-addon-generic-kbd-backlight already responds to KEY_KBDILLUM*. If so, then one could use Hal along with an FDI file like the apple one (<http://lists.freedesktop.org/archives/hal/2008-October/012360.html>). That's close to what we should ultimately be aiming for, except for the specific match on "smc::kbd_backlight". It would be great to just have one rule matching on *::kbd_backlight. 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
