Hi!
> > 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 <hdegoede@xxxxxxxxxx>
To: Pavel Machek <pavel@xxxxxx>
Cc: Jacek Anaszewski <j.anaszewski@xxxxxxxxxxx>, Jacek Anaszewski
<jacek.anaszewski@xxxxxxxxx>, Tony Lindgren
<tony@xxxxxxxxxxx>,
linux-leds@xxxxxxxxxxxxxxx,
linux-omap@xxxxxxxxxxxxxxx,
linux-arm-kernel@xxxxxxxxxxxxxxxxxxx,
linux-kernel@xxxxxxxxxxxxxxx, Darren Hart
<dvhart@xxxxxxxxxxxxx>, Hans de Goede <hdegoede@xxxxxxxxxx>
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 <hdegoede@xxxxxxxxxx> . He is
apparently solving same problem.
Thanks,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Attachment:
signature.asc
Description: Digital signature
