<div dir="ltr"><div><div><div><div><div>Hi Martin, </div>Using the sugar-backlight-helper with a polkit file to change the brightness file sounds like a very good idea. That would significantly reduce the complexity of the change. </div>Please feel free to make the changes and send through a patch. </div>I will try and fix up the iconography issues. </div>Thanks, </div>Sam </div> <div class="gmail_quote">On Wed, May 6, 2015 at 9:43 AM James Cameron <<a href="mailto:quozl@laptop.org">quozl@laptop.org</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Thanks for the research. On Tue, May 05, 2015 at 06:27:59PM -0400, Martin Abente wrote: > [...] > It would not be too difficult to re-implement the same mechanism for > Sugar. In fact I have re-implemented the exact same functionality > provided by "gsd-backlight-helper" in > Python. <a href="https://github.com/tchx84/" target="_blank">https://github.com/tchx84/</a> > sugar-backlight-helper/blob/master/sugar-backlight-helper.py Have to remove .py from the link. > @James, can you also give it a try? Worked fine for me on Ubuntu 14.04.2 on commodity hardware. Small changes to README.md sent in pull request. > (this also works for the XO btw). Yes, and it will be useful for integration with the proposed frame device icon for the display. The F9 and F10 keys will continue to be intercepted by olpc-kbdshim.c, which calls olpc-brightness shell script in subprocess. However, a similar user experience with the audio device icon will occur, where the Sugar UI will ignore changes made by olpc-brightness. See #1677 and <a href="http://dev.laptop.org" target="_blank">dev.laptop.org</a> #9913. So Sugar will need a way to be informed of brightness changes made by other processes; which on commodity hardware will be brightness controls handled by other system programs, and on XO laptops will be olpc-kbdshim and powerd. To detect changes to a sysfs file; not sure how this is done, but for the time being we can read it occasionally. To make that more efficient, I've added --get-path option to the helper. See pull request #2. > Regarding the use of a separate tool to deal with permissions, I > wonder if GSD deliberately separated that tool to simplify the > integration with PolKit. The question is: should we do something > similar with sugar? I personally think is a valid option, but I > wonder if there is another way of using PolKit to grant permissions > directly to Sugar for writing to the device. I don't have much > experience with PolKit. Security design is that the program that needs the secure access should be as small as possible. Otherwise, you widen the attack vector to everything in Sugar shell. > @Sam, @James, if we think we can go this direction, I can will some > changes on top of Sam's previous work tomorrow. Adding sugar-backlight-helper to the sugar sources seems to be the right direction. This adds a dependency on polkit, but you could make it a soft dependency and not install the helper if polkit is not available. -- James Cameron <a href="http://quozl.linux.org.au/" target="_blank">http://quozl.linux.org.au/</a> </blockquote></div>