Hi,
On 15-11-16 11:01, Jacek Anaszewski wrote:
Hi,
On 11/14/2016 01:51 PM, Hans de Goede wrote:
<snip>
Ugh, I see I accidentally send a v4 twice, instead of
calling the version which dropped those called v5 as
I should have, sorry.
The v4 which I would like to see merged, the one with
those calls dropped, is here:
https://patchwork.kernel.org/patch/9423093/
Right I've had an impression that I've already seen something
different than "first" v4.
Regarding the patch - adding led_notify_brightness_change() to
brightness_store() can have similar power consumption related
implications if brightness is set frequently via sysfs.
That means that userspace is waking up frequently to write the
sysfs file, so in that case userspace is already draining
a lot of energy, so I don't think that is something we need to
worry about.
I'm leaning
towards adding a new brightness file similar to user_brightness
discussed in this thread.
It would cover shortcomings and read/write inconsistencies that
brightness file currently has, but without breaking existing users.
I'd not however go for "user_brightness" name due to the possible
brightness adjustments made autonomously by firmware. I'm afraid
that devising a meaningful name for the new file will be hard,
so the simplest would be just brighntess2. Dedicated section
in leds-class.txt should be devoted to it.
Ok, let me quote myself from another part of this thread:
We've 2 sorts of brightness really:
1) transient brightness, aka current brightness, when blinking or
triggers are used this will switch many times a second
between off and some on level.
2) non-transient brightness, for non blinking leds this is the
actual brightness, for blinking leds this is the brightness
level used when the led is on.
Now we want to have a sysfs attribute reflecting 2, so that
userspace can poll on that, both for my use-case as well as so
that userspace process a can detect changes made by writing to
the brightness file by process b.
So maybe we need to simply call the new attribute
non_transient_brightness instead of user_brightness?
non_transient_brightness certainly seems like a better name
then brightness2 ?
Regards,
Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
