On 27/12/2016 21:07, Pavel Machek wrote: > Hi! > >> Similarily to commit 325253a6b2de ("backlight: Allow drivers to update >> the core, and generate events on changes"), inform userspace about >> brightness changes and allow drivers to request updates of the >> brightness value. > > First... we had similar patch in tree, and it caused problems, we are > now trying to figure out how to do it properly. Oh, I didn't know that, sorry. > LED can be updated many times per second, uevent is probably _not_ > good mechanism to achieve that. Ummm, right, I didn't think of that. > Generating uevent for /sys changes does not make much sense, right? I planned to use this patch mostly for keyboard backlights, for which some DEs provide a UI similar to the one for screen backlights. Having uevents also for /sys changes means having the UI always in sync with the kernel/hardware, as it happens for screen backlights. In case of LEDs only the application changing the brightness is aware of the change. >> +extern void led_brightness_force_update(struct led_classdev *led_cdev, >> + enum led_brightness_update_reason reason); > > I see this may make some sense, but there are no uses for this in this > patch. > > My preffered solution would be ... for hardware that changes led > brightness itself, introduce a "trigger", so that userspace knows this > led is special, and then provide poll()able /sys fs file interested > parties can read. OK, I'll see if I can come up something good. Regards, Gabriele > Best regards, > > Pavel > -- To unsubscribe from this list: send the line "unsubscribe linux-leds" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html