On Sat, Mar 20, 2010 at 08:55:53AM +0800, Yong Wang wrote: > On Fri, Mar 19, 2010 at 03:23:23PM +0000, Matthew Garrett wrote: > > > > > > > + if (code >= NOTIFY_BRNUP_MIN && code <= NOTIFY_BRNUP_MAX) > > > > > + code = NOTIFY_BRNUP_MIN; > > > > > + else if (code >= NOTIFY_BRNDOWN_MIN && code <= NOTIFY_BRNDOWN_MAX) > > > > > + code = NOTIFY_BRNDOWN_MIN; > > > > > > > > Do the brightness keys just send notifications, or do they actually > > > > change the brightness? If they actually change the brightness, we > > > > shouldn't send input events. > > > > > > > > > > Yes, hardware and bios change brightness by themselves without software intervention > > > on my Eee PC 1005 when pressing the hotkeys. > > > > Ok. In that case, you shouldn't send input events. Once backlight > > control is implemented in the eee-wmi driver you can send notifications > > via that instead. > > > > One question just popped off the top my head. What if there is a power > applet that wants to display a slider field at the bottom of the screen > showing the current brightness real time whenever users press brightness > hotkeys? Shouldn't it listen to the standard input events translated by > X into standard XF86 keysyms? Or shall it listen to the ACPI backlight > events? If so, it is the ACPI LCD event when using acpi backlight > driver. But what if those vendor specific backlight drivers are used? > > Thanks > -Yong > -- You may select/poll for the sysfs file actual_brightness. It will return POLLPRI. Basically, backlight devices end up calling sysfs_notify that will allow sysfs_poll to work. Read the comments about sysfs_poll at fs/sysfs/file.c. You should either use backlight_force_update in your driver or let the user update it writing to the brightness file. In your case, I'd say you should use backlight_force_update and give BACKLIGHT_UPDATE_HOTKEY as the reason. Regards, Cascardo.
Attachment:
signature.asc
Description: Digital signature
