Message ID | 1247587564-27737-1-git-send-email-mjg@redhat.com (mailing list archive) |
---|---|
State | Accepted |
Headers | show |
Dne Tue, 14 Jul 2009 17:06:02 +0100 Matthew Garrett napsal: > +static void backlight_generate_event(struct backlight_device *bd, > + enum backlight_update_reason > reason) +{ > + char *envp[2]; > + > + switch (reason) { > + case BACKLIGHT_UPDATE_SYSFS: > + envp[0] = "SOURCE=sysfs"; > + break; > + case BACKLIGHT_UPDATE_HOTKEY: > + envp[0] = "SOURCE=hotkey"; > + break; > + default: > + envp[0] = "SORUCE=unknown"; There's a typo here. s/SORUCE/SOURCE/ Michal -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue 2009-07-14 17:06:02, Matthew Garrett wrote: > Certain hardware will send us events when the backlight brightness > changes. Add a function to update the value in the core, and > additionally send a uevent so that userspace can pop up appropriate > UI. The uevents are flagged depending on whether the update originated > in the kernel or from userspace, making it easier to only display UI > at the appropriate time. This adds new kernel API. Should it be documented somewhere?
On Tue, 14 Jul 2009, Matthew Garrett wrote: > Certain hardware will send us events when the backlight brightness > changes. Add a function to update the value in the core, and > additionally send a uevent so that userspace can pop up appropriate > UI. The uevents are flagged depending on whether the update originated > in the kernel or from userspace, making it easier to only display UI > at the appropriate time. Ok. I have it working (event-based AND poll-based) in thinkpad-acpi, although it needs to be tested by dual-GPU, ACPI-based and OpRegion-based owners. Should the driver notify of *any* changes, even when the user is hitting the "ceiling" or the "floor" and the backlight value didn't really change? If the answer is no, shouldn't the backlight class filter these out itself, to guarantee a consistent experience?
On Sat, Sep 19, 2009 at 08:24:24PM -0300, Henrique de Moraes Holschuh wrote: > Should the driver notify of *any* changes, even when the user is hitting the > "ceiling" or the "floor" and the backlight value didn't really change? I'd say yes - the user will expect the UI to appear whenever they hit the button.
On Sun, 20 Sep 2009, Matthew Garrett wrote: > On Sat, Sep 19, 2009 at 08:24:24PM -0300, Henrique de Moraes Holschuh wrote: > > Should the driver notify of *any* changes, even when the user is hitting the > > "ceiling" or the "floor" and the backlight value didn't really change? > > I'd say yes - the user will expect the UI to appear whenever they hit > the button. Ok. The thinkpad-acpi changes depends on a large patchset that I should send to Len today. After that, I will send the patch that adds brightness event support. Are you backlight patches in any tree? Are them expected to hit mainline this merge window?
diff --git a/drivers/video/backlight/backlight.c b/drivers/video/backlight/backlight.c index 157057c..01efb2d 100644 --- a/drivers/video/backlight/backlight.c +++ b/drivers/video/backlight/backlight.c @@ -73,6 +73,26 @@ static inline void backlight_unregister_fb(struct backlight_device *bd) } #endif /* CONFIG_FB */ +static void backlight_generate_event(struct backlight_device *bd, + enum backlight_update_reason reason) +{ + char *envp[2]; + + switch (reason) { + case BACKLIGHT_UPDATE_SYSFS: + envp[0] = "SOURCE=sysfs"; + break; + case BACKLIGHT_UPDATE_HOTKEY: + envp[0] = "SOURCE=hotkey"; + break; + default: + envp[0] = "SORUCE=unknown"; + break; + } + envp[1] = NULL; + kobject_uevent_env(&bd->dev.kobj, KOBJ_CHANGE, envp); +} + static ssize_t backlight_show_power(struct device *dev, struct device_attribute *attr,char *buf) { @@ -142,6 +162,8 @@ static ssize_t backlight_store_brightness(struct device *dev, } mutex_unlock(&bd->ops_lock); + backlight_generate_event(bd, BACKLIGHT_UPDATE_SYSFS); + return rc; } @@ -214,6 +236,25 @@ static struct device_attribute bl_device_attributes[] = { }; /** + * backlight_force_update - tell the backlight subsystem that hardware state + * has changed + * @bd: the backlight device to update + * + * Updates the internal state of the backlight in response to a hardware event, + * and generate a uevent to notify userspace + */ +void backlight_force_update(struct backlight_device *bd, + enum backlight_update_reason reason) +{ + mutex_lock(&bd->ops_lock); + if (bd->ops && bd->ops->get_brightness) + bd->props.brightness = bd->ops->get_brightness(bd); + mutex_unlock(&bd->ops_lock); + backlight_generate_event(bd, reason); +} +EXPORT_SYMBOL(backlight_force_update); + +/** * backlight_device_register - create and register a new object of * backlight_device class. * @name: the name of the new object(must be the same as the name of the diff --git a/include/linux/backlight.h b/include/linux/backlight.h index 79ca2da..0f5f578 100644 --- a/include/linux/backlight.h +++ b/include/linux/backlight.h @@ -27,6 +27,11 @@ * Any other use of the locks below is probably wrong. */ +enum backlight_update_reason { + BACKLIGHT_UPDATE_HOTKEY, + BACKLIGHT_UPDATE_SYSFS, +}; + struct backlight_device; struct fb_info; @@ -100,6 +105,8 @@ static inline void backlight_update_status(struct backlight_device *bd) extern struct backlight_device *backlight_device_register(const char *name, struct device *dev, void *devdata, struct backlight_ops *ops); extern void backlight_device_unregister(struct backlight_device *bd); +extern void backlight_force_update(struct backlight_device *bd, + enum backlight_update_reason reason); #define to_backlight_device(obj) container_of(obj, struct backlight_device, dev)
Certain hardware will send us events when the backlight brightness changes. Add a function to update the value in the core, and additionally send a uevent so that userspace can pop up appropriate UI. The uevents are flagged depending on whether the update originated in the kernel or from userspace, making it easier to only display UI at the appropriate time. Signed-off-by: Matthew Garrett <mjg@redhat.com> --- Updated to allow drivers to provide a reason for the change drivers/video/backlight/backlight.c | 41 +++++++++++++++++++++++++++++++++++ include/linux/backlight.h | 7 ++++++ 2 files changed, 48 insertions(+), 0 deletions(-)