Hi Pali, Glenn,
Thanks for your feedback.
On 11/22/2016 03:58 PM, Pali Rohár wrote:
On Monday 21 November 2016 14:29:00 Jacek Anaszewski wrote:
Let's wait until every involved part agrees (Pavel, Pali).
Ok, I read that discussion on linux-leds ML and finally understand
motivation and results.
Personally I still do not like current approach and big problem what I
see is that I was not able to understand *why* introduction of
current_brightness is needed and how userspace application should use
it, before I read whole that linux-leds discussion.
For people who already understand situation it is probably OK, but when
I first time saw this patch series I just said WTF and description in
Documentation files nor in commit messages did not help me.
I would suggest to properly document *current* behaviour of LED sysfs
files in Documentation/ABI before doing any decision how to solve
current problem.
Without correct documentation how sysfs LED interface behave in
different situations (trigger is active; zero is written to brightness;
brightness is read when blinking is active; etc) it is really hard to
discuss about those problems. As many people (me included) first looked
at those documentation files and think that info written here is correct
and handle everything...
Adding trigger for LED devices which belongs to keyboard backlight has
only disadvantage: You cannot set other kernel trigger to control level
of keyboard backlight.
I can imagine that trigger "key pressed" or "mouse moved" can be really
useful for controlling keyboard backlight level. But that new keyboard
backlight trigger just disallow it.
On 11/22/2016 04:20 PM, Glenn Golden wrote:
> +1 on the above sentiment, sense of frustration well expressed.
So we have more voices against the trigger approach.
I would also appreciate your opinion on the other solution to the
problem of notifying brightness changes originating from hardware,
i.e. hw_brightness_change{_ro} file, that would support POLLPRI events,
and reading brightness.
Do you find the file name informative enough or maybe you'd like to
propose other name, or even entirely different approach?
--
Best regards,
Jacek Anaszewski
--
To unsubscribe from this list: send the line "unsubscribe platform-driver-x86" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
