[Sugar-devel] More details on brightness control in Sugar

[Sam P.]

Hi Martin,

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.

Please feel free to make the changes and send through a patch.

I will try and fix up the iconography issues.

Thanks,
Sam

On Wed, May 6, 2015 at 9:43 AM James Cameron <quozl at laptop.org> wrote:

> 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.  https://github.com/tchx84/
> > 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 dev.laptop.org #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
> http://quozl.linux.org.au/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20150506/8d499be4/attachment.html>