Since the DragonFly users are likely to be mostly its developers, I am asking this question here. (Tirez pas sur le pianiste.)
--- start of exposé -- Why is DragonFly's kernel (and some other kernels) "eating" my brightness adjustment keys with my Acer? To the extent of my lack of knowledge, the problem with adjusting the screen brightness is that it seems to have two parts, regardless of the OS: 1. The said keys _can_ interact *directly with the hardware* as proven by the fact that they work while you're in the BIOS screen (or at the GRUB/LILO prompt, or before the kernel is fully loaded), and they also work sometimes when the kernel is still detecting hardware and couldn't be aware yet of any model-specific hardware. 2. With or without the interaction of the said keys, a very few Linux distros are able to adjust my screen brightness in increments of 1%, from 0 to 100, through software e.g. KPowerSave: "Your hardware supports to change the brightness". While I appreciate the fact that this can be achieved through software (yet I don't know what can XF86BrightnessAdjust be set to trigger, exactly!?), I still want to be able to adjust the brightness manually (the 9 levels I can get through the keyboard) simply because unlike the volume keys, it's very rare to have software able to adjust the screen brightness. You can see a cross-OS synopsis here: http://beranger.org/blogo3/brightness_keys.png So FreeBSD and NetBSD seem to "leave those key alone" so they can adjust the brightness, whereas DragonFly BSD is interfering with them! --- end of exposé -- Question: How does it happen? How can a keycode *not* be "sensed" in the same hardware that can "sense" it in the bootloader screen? What is DragonFly doing? Thank you. R-C Get news delivered with the All new Yahoo! Mail. Enjoy RSS feeds right on your Mail page. Start today at http://mrd.mail.yahoo.com/try_beta?.intl=ca
