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

Martin Abente martin.abente.lahaye at gmail.com
Wed May 6 14:18:37 EDT 2015


Alright, working on it already ;) Should have something to show today.

On Wed, May 6, 2015 at 5:31 AM, Sam P. <sam.parkinson3 at gmail.com> wrote:

> 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/bf0fe544/attachment-0001.html>


More information about the Sugar-devel mailing list