[Sugar-devel] Deployments survey results
Hello community, In the last months, the SuarLabs Oversight Board run a survey between people involved in the deployments, with the objective of get information to help us evaluate alternatives for future developments at SugarLabs, Here is a document we elaborated, summarizing the results of the survey: http://wiki.sugarlabs.org/images/4/48/Survey_summary.pdf This is a little step to try improve our communication with the deployments. If you are involved in a deployment, and would like to participate in future communications, just send me a email. Regards, -- SugarLabs Oversight Board ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] More details on brightness control in Sugar
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/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Feature freeze reminder
Hello everyone, This is just a friendly reminder that we are less than 2 weeks (May 18) away from our Features Freeze deadline [1]. For those working in features I recommend to prioritize and focus on those that have been actively reviewed. Quality over quantity will be ;) Also, make sure to include the feature information in our wiki [2]. Thanks, Martin. Refs: 1. http://wiki.sugarlabs.org/go/0.106/Roadmap#Freezes 2. http://wiki.sugarlabs.org/go/0.106/Feature_List ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Community XO software builds
I saw some discussion last week about the community XO software builds. This seems to be something which gets many people excited. However according to my web server, there have not been very many downloads of them. If I may ask: - Who actually is using/testing these images? - Why? - Is there a reason you are not looking into using an official (OLPC or deployment) build? - Have you engaged OLPC or another party to work on changes? - What direction do you believe the builds should go? Building XO builds by repacking existing work is relatively trivial. But the low-level kernel, driver, and OS work necessary to support XOs with newer operating systems (as well as newer XO batteries) is something I cannot do, and where we really need help. Without guidance from OLPC or others, I could build thousands of XO-# laptop images. But unless it looks like a significant number of deployments/children actually would benefit, there really is no point. --- SJG ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Community XO software builds
Who actually is using/testing these images? Why? I am as I try to to see if I could still get some life out of XO with whatever development that is going forward with upgrades. Is there a reason you are not looking into using an official (OLPC or deployment) build? Use that also but community driven images may be a good way to test things for feedback before things get official. - Have you engaged OLPC or another party to work on changes? I try to and the best things is I get some help along the way for a little DIY with my limited technical skills. - What direction do you believe the builds should go? 1. To make the XO multi-media ready :-) or provide scripts that we can just run to for enabling multi-media experience with the XO. Hate to see spinning wheels without images :-( 2. Have builds that target specific age groups with the right activities loaded or displayed. Building XO builds by repacking existing work is relatively trivial. But the low-level kernel, driver, and OS work necessary to support XOs with newer operating systems (as well as newer XO batteries) is something I cannot do, and where we really need help. Yes and I hope OLPC is still providing the necessary financial support for things to happen. Without guidance from OLPC or others, I could build thousands of XO-# laptop images. But unless it looks like a significant number of deployments/children actually would benefit, there really is no point. Build and they may come. Thanks. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Community XO software builds
Hi Samuel, I think your volunteer work is important. It is not clear to me exactly what the focus is of your images, nor where the repositories with the ini files for the builder, or the download link for the ready images. This is probably the reason you have so few downloads logged. Perhaps we should put all of this in a Wiki page? I am interested, but haven't been able to test because when I asked last time for the SD card images you told me you would build them but never let me know when/where I could get them. I understand it may be frustrating to work without feedback but it's simply the way it works at this point, unless you are in the field. Also, keep in mind that deployments are interested in updating OS images once every one or two years. Thanks, in the name of the children, for the work you do. I'll try to respond your questions inline below. Regards, Sebastian On 05/05/15 23:54, Samuel Greenfeld wrote: I saw some discussion last week about the community XO software builds. This seems to be something which gets many people excited. However according to my web server, there have not been very many downloads of them. If I may ask: * Who actually is using/testing these images? Not me, yet. * Why? I maintained in the past official images for Peru. * Is there a reason you are not looking into using an official (OLPC or deployment) build? Yes we like to roll our own to include native languages, features (e.g. Sugar Network), etc. * Have you engaged OLPC or another party to work on changes? I try to work upstream. * What direction do you believe the builds should go? The best possible experience for end users. Basically, on XO, means performance tuning. Building XO builds by repacking existing work is relatively trivial. But the low-level kernel, driver, and OS work necessary to support XOs with newer operating systems (as well as newer XO batteries) is something I cannot do, and where we really need help. Without guidance from OLPC or others, I could build thousands of XO-# laptop images. But unless it looks like a significant number of deployments/children actually would benefit, there really is no point. --- SJG ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- I+D SomosAzucar.Org icarito #somosazucar en Freenode IRC Nadie libera a nadie, nadie se libera solo. Los seres humanos se liberan en comunión - P. Freire ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] More details on brightness control in Sugar
Hello Sam and James, I am moving our discussion from Sam's pull request ( https://github.com/sugarlabs/sugar/pull/437) to here because this particular post is bit long. Regarding James request: ...instead understand how both gnome-settings-daemon and unity-settings-daemon implement what they do (for brightness), and reimplement that in Sugar? I have been reading GSD (gnome-settings-daemon) sources and I think I am making sense of it. Basically, GSD makes use of a tool called gsd-backlight-helper, which is provided by GSD. This tool queries Udev for the proper backlight device, and directly reads and writes to the device file. GSD uses a special PolKit action policy to allow unprivileged users to run this tool without root privileges for writing to the device. Examples: [tch@tch polkit-1]$ /usr/libexec/gsd-backlight-helper --get-brightness 4000 [tch@tch polkit-1]$ /usr/libexec/gsd-backlight-helper --get-max-brightness 4437 [tch@tch polkit-1]$ pkexec /usr/libexec/gsd-backlight-helper --set-brightness 4437 Details: 0) when using GSD over DBUS: dbus-send --session --print-reply --dest=org.gnome.SettingsDaemon /org/gnome/SettingsDaemon/Power org.freedesktop.DBus.Properties.Set string:org.gnome.SettingsDaemon.Power.Screen string:Brightness variant:int32:100 1) which is defined here: https://git.gnome.org/browse/gnome-settings-daemon/tree/plugins/power/gsd-power-manager.c#n82 2) triggers a callback in GSD, which makes a call to backlight_step_up: https://git.gnome.org/browse/gnome-settings-daemon/tree/plugins/power/gsd-power-manager.c#n2620 3) backlight_step_up is defined here: https://git.gnome.org/browse/gnome-settings-daemon/tree/plugins/power/gpm-common.c#n647 4) when running under Linux, backlight_step_up() calls to a function called to backlight_helper_set_value: https://git.gnome.org/browse/gnome-settings-daemon/tree/plugins/power/gpm-common.c#n692 5) then, backlight_helper_set_value makes a __system call__ to gsd-backlight-helper, which is a tool provided by GSD: https://git.gnome.org/browse/gnome-settings-daemon/tree/plugins/power/gpm-common.c#n491 NOTE: this system calls uses pkexec, and requires a PolKit action policy to allow unpriviledge users to write to the device without being root. 6) this gsd-backlight-helper tool is implemented here: https://git.gnome.org/browse/gnome-settings-daemon/tree/plugins/power/gsd-backlight-helper.c 7) and uses gsd_backlight_helper_get_best_backlight to find the proper device: https://git.gnome.org/browse/gnome-settings-daemon/tree/plugins/power/gsd-backlight-linux.c#n49 8) lastly, the PolKit policy file is here: https://git.gnome.org/browse/gnome-settings-daemon/tree/plugins/power/org.gnome.settings-daemon.plugins.power.policy.in.in Conclusions: 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 (this also works for the XO btw). @James, can you also give it a try? 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. @Sam, @James, if we think we can go this direction, I can will some changes on top of Sam's previous work tomorrow. Regards, Martin. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
