[lkml]   [2016]   [Dec]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] leds: Allow drivers to update the core, and generate events on changes

> > 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.

Please see this thread:

Date: Tue, 15 Nov 2016 13:06:14 +0100
From: Hans de Goede <>
To: Pavel Machek <>
Cc: Jacek Anaszewski <>, Jacek Anaszewski
<>, Tony Lindgren
<>,,,,, Darren Hart
<>, Hans de Goede <>
Subject: Re: LEDs that change brightness "itself" -- that's a
trigger. Re: PM regression with LED changes in next-20161109

...and you may want to cc: Hans de Goede <> . He is
apparently solving same problem.

(cesky, pictures)
[unhandled content-type:application/pgp-signature]
 \ /
  Last update: 2016-12-27 22:12    [W:0.104 / U:0.264 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site