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 <hdego...@redhat.com>
To: Pavel Machek <pa...@ucw.cz>
Cc: Jacek Anaszewski <j.anaszew...@samsung.com>, Jacek Anaszewski
<jacek.anaszew...@gmail.com>, Tony Lindgren
<t...@atomide.com>,
linux-l...@vger.kernel.org,
linux-o...@vger.kernel.org,
linux-arm-ker...@lists.infradead.org,
linux-kernel@vger.kernel.org, Darren Hart
<dvh...@infradead.org>, Hans de Goede <hdego...@redhat.com>
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 <hdego...@redhat.com> . 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
signature.asc
Description: Digital signature
