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. -- Pali Rohár pali.rohar@xxxxxxxxx -- 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
