On Mon, Mar 12, 2012 at 2:34 AM, AceLan Kao <acelan.kao@xxxxxxxxxxxxx> wrote: > Dear Corentin, > > No, I don't use acpi_backlight=vendor or something like that. > And there is no ACPI backlight functions in the BIOS. Hum ok, I see. I would be curious to take a look at the DSDT, is this possible ? > Yes, we just need to inform the userspace to update the backlight > brightness status, and I found that using backlight_notify doesn't work, so I let it send > the key event directly. Here is how backlight notification work these days: When a backlight related hotkey is received: - The BIOS already have handled it and changed the brightness: we have to call backlight_force_update(bd, BACKLIGHT_UPDATE_HOTKEY) to tell userspace that the brightness have changed in response to an hotkey - The BIOS haven't handled it: we should only send an input event (KEY_BRIGHTNESSDOWN or KEY_BRIGHTNESSUP) and userspace will deal with it (setting the appropriate sysfs file, and displaying an OSD). When we call backlight_force_update(bd, BACKLIGHT_UPDATE_HOTKEY), it do two things: - send a change notification on the actual_brightness file (userspace can monitor it using inotify or related). - send a uevent which can be catched by udev or others (with SOURCE being an env variable containing the source of this change). It's possible that some desktop components don't handle that correctly yet (gnome-power-daemon, gnome-settings-daemon, powerdevil, xrandr, etc..). But in this case you should send them a bug report. ref: backlight: Allow drivers to update the core, and generate events on changes - https://lwn.net/Articles/341289/ -- Corentin Chary http://xf.iksaif.net -- To unsubscribe from this list: send the line "unsubscribe platform-driver-x86" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
