New XO-1.5 10.2.0 build 120
http://wiki.laptop.org/go/F11_for_1.5 http://build.laptop.org/10.2.0/os120 Compressed image size: 678.35mb (-0.01mb since build 119) Description of changes in this build: * Speak: upstream Speak-14 release is broken (SL #1934), revert to Speak-11. * kernel, #10068: fix for "black Xv overlay when starting Record". * kernel, #10127: fix for "DMA image corruption from camera in C3/C4". * olpc-utils: olpc-pwr-log updates from rsmith. * olpc-update: Move configuration from /security to /etc. * powerd: "Modify handling of battery dis/charge wakeups which were preventing eventual shutdown, and improve power logging, but apparently not enough for Richard." * openchrome: minor cleanups from Jon Nettleton. * Pull F11 updates. Package changes since build 119: -NetworkManager-0.7.2.995-2.git20100225.fc11.i586 +NetworkManager-0.7.2.996-1.fc11.i586 -NetworkManager-glib-0.7.2.995-2.git20100225.fc11.i586 +NetworkManager-glib-0.7.2.996-1.fc11.i586 -NetworkManager-gnome-0.7.2.995-2.git20100225.fc11.i586 +NetworkManager-gnome-0.7.2.996-1.fc11.i586 -abiword-2.8.2-1.fc11.i586 +abiword-2.8.4-1.fc11.i586 -alsa-lib-1.0.22-3.fc11.i586 +alsa-lib-1.0.23-1.fc11.i586 -bootfw-q3a35-1.unsigned.i386 +bootfw-q3a36-1.unsigned.i386 -curl-7.19.7-6.fc11.i586 +curl-7.19.7-7.fc11.i586 -grep-2.6.1-1.fc11.i586 +grep-2.6.3-1.fc11.i586 -hulahop-0.4.9-13.fc11.i586 +hulahop-0.7.1-1.fc11.i586 -kernel-2.6.31_xo1.5-20100409.1311.1.olpc.03dde3f.i586 +kernel-2.6.31_xo1.5-20100421.2010.1.olpc.f2b9ce0.i586 -kernel-firmware-2.6.31_xo1.5-20100409.1311.1.olpc.03dde3f.i586 +kernel-firmware-2.6.31_xo1.5-20100421.2010.1.olpc.f2b9ce0.i586 -krb5-libs-1.6.3-27.fc11.i586 +krb5-libs-1.6.3-29.fc11.i586 -krb5-workstation-1.6.3-27.fc11.i586 +krb5-workstation-1.6.3-29.fc11.i586 -libabiword-2.8.2-1.fc11.i586 +libabiword-2.8.4-1.fc11.i586 -libcurl-7.19.7-6.fc11.i586 +libcurl-7.19.7-7.fc11.i586 -nano-2.0.6-6.fc11.i586 +nano-2.0.9-1.fc11.i586 -olpc-powerd-18-1.fc11.i586 +olpc-powerd-19-1.fc11.i586 -olpc-update-2.21-1.fc11.noarch +olpc-update-2.22-1.fc11.noarch -olpc-utils-1.0.21-1.fc11.i586 +olpc-utils-1.0.22-1.fc11.i586 -sudo-1.7.2p5-1.fc11.i586 +sudo-1.7.2p6-1.fc11.i586 -sysvinit-tools-2.86-27.i586 +sysvinit-tools-2.86-28.fc11.i586 -tzdata-2010f-3.fc11.noarch +tzdata-2010i-1.fc11.noarch -xorg-x11-drv-openchrome-0.2.904-6.1.fc11.i586 +xorg-x11-drv-openchrome-0.2.904-6.2.fc11.i586 -yp-tools-2.9-6.fc11.i586 +yp-tools-2.9-7.fc11.i586 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
[PATCH] viafb: Restore CR00-CR06 on resume
Restoring this subset of the CRT registers is required for the video
overlay to work after resume on the VX855/XO1.5 -- without the patch,
the overlay remains black. (OLPC Trac #10068.)
Signed-off-by: Chris Ball
---
drivers/video/via/viafbdev.c | 13 +
drivers/video/via/viafbdev.h |1 +
2 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/drivers/video/via/viafbdev.c b/drivers/video/via/viafbdev.c
index 767b026..0efc6e1 100644
--- a/drivers/video/via/viafbdev.c
+++ b/drivers/video/via/viafbdev.c
@@ -2042,12 +2042,17 @@ static void viafb_remove_proc(struct proc_dir_entry
*viafb_entry)
#ifdef CONFIG_PM
static int viafb_suspend(void *unused)
{
+ u8 i;
acquire_console_sem();
memcpy_fromio((void *)&viaparinfo->saved_video_regs,
viaparinfo->io_virt + 0x200,
sizeof(video_via_regs));
+ /* CR00-CR06 need to be preserved for the video overlay. */
+ for (i = 0; i <= 6; i++)
+ viaparinfo->saved_crt_regs[i] = viafb_read_reg(VIACR, i);
+
fb_set_suspend(viafbinfo, 1);
viafb_sync(viafbinfo);
release_console_sem();
@@ -2057,6 +2062,7 @@ static int viafb_suspend(void *unused)
static int viafb_resume(void *unused)
{
+ u8 i;
volatile video_via_regs *viaVidEng =
(volatile video_via_regs *)(viaparinfo->io_virt + 0x200);
video_via_regs *localVidEng = &viaparinfo->saved_video_regs;
@@ -2126,6 +2132,13 @@ static int viafb_resume(void *unused)
fb_set_suspend(viafbinfo, 0);
release_console_sem();
+
+ /* Restore CR00-CR06 */
+ viafb_unlock_crt();
+ for (i = 0; i <= 6; i++)
+ viafb_write_reg(i, VIACR, viaparinfo->saved_crt_regs[i]);
+ viafb_lock_crt();
+
return 0;
}
diff --git a/drivers/video/via/viafbdev.h b/drivers/video/via/viafbdev.h
index ca60452..bc72f15 100644
--- a/drivers/video/via/viafbdev.h
+++ b/drivers/video/via/viafbdev.h
@@ -151,6 +151,7 @@ struct viafb_par {
/* For suspend/resume */
video_via_regs saved_video_regs;
+ u8 saved_crt_regs[7];
};
struct viafb_modeinfo {
--
1.6.2.5
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: Hulahop browser screen width XO1.0 vs XO1.5
Currently the content is already different in the newest version of the activity as the XO1.5 has different features. Are you planning on rebasing the content somewhere? --Seth On Tue, Apr 20, 2010 at 10:29 PM, George Hunt wrote: > I'd like a solution which lets Activities run on both older and newer > versions of sugar. > > I just googled js screen_width. It looks like the DOM has a predefined > object screen, which we can use to select which CSS to use. I'll try that. > If it works I'll document it on the hulahop/webview page .as a solution > > George > > On Tue, Apr 20, 2010 at 6:06 PM, Seth Woodworth > wrote: >> >> It would be far easier to simply change the .css file and layout of the >> html content in the help activity for the latest versions of sugar. >> >> On Sun, Apr 18, 2010 at 10:27 PM, George Hunt >> wrote: >>> >>> Hi again, >>> >>> My activity uses Hulahop Browser for its help system. The default >>> browser on the XO`1.0 seems set up for 800x600. The CSS width specs on >>> the functioning HELP activity add up to 800 px wide and everything works out >>> ok. >>> >>> But on F11 XO1.5, the same help activity only renders about 2/3 full >>> screen. And I'm experiencing similar problems rendering my help pages >>> between 1.0 and 1.5. >>> >>> On F11, I believe the default screen width sensed by the xulrunner engine >>> is the 1200x900, the actual screen size. >>> >>> I'm pretty sure there's a way to ask the gecko engine to render on a >>> 800x600 screen, or alternatively to ask gecko on the XO1.0 to render on a >>> 1200x900 surface. >>> >>> But I don't know XUL well and I feel I'd be wasting my time learning >>> about how to set up gecko, if someone already knows how to solve this one. >>> I'd be willing to modify HELP activity, once we I find an acceptable >>> solution. >>> >>> George >>> >>> ___ >>> Devel mailing list >>> Devel@lists.laptop.org >>> http://lists.laptop.org/listinfo/devel >>> >> > > ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: How to build an .img
On Wed, Apr 21, 2010 at 05:19:39PM +0200, Bastien wrote:
> 2. I told build.py to run a script which removes the file I want to
> get rid of (which is ${imgdir}/home/olpc/.sugar-update) - but the
> script fails and complains this file is missing.
My apologies. .sugar-update is created by
/etc/rc.d/init.d/olpc-configure on first boot, so you should read that
script and patch it for your build. Or remove the file in a script that
runs after olpc-configure; such as /etc/rc.local.
--
James Cameron
http://quozl.linux.org.au/
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: [Server-devel] Collaboration server for existing network
On Wed, Apr 21, 2010 at 1:20 PM, Jerry Vonau wrote: > Just checked git, I had to touch also idmanager.py in order to have it > respect the variable in the config file. > /BIND_ADDRESS/#BIND_ADDRESS Ok. So you had to unset the default value... then the code block below that (Config.__init__()), which reads /etc/idmgr.conf to read in overrides is failing to override it. I don't want to remove the default value (which is correct for the XS), and I'd rather fix things to have working overrides... m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Server-devel mailing list server-de...@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: Record activity for XO-1.5
On 20 April 2010 18:06, Daniel Drake wrote: > Hi, > > Here's a version of the Record activity which works on XO-1.5: > git://dev.laptop.org/users/dsd/record I updated this git tree. The code I announced yesterday is now in the v60-plus-tweaks branch. The master branch (non-fast-forward) is now the Record git tree from activities.sugarlabs.org, with my v60 rework placed on top of it. i.e. working towards a patch series that can be applied to SL upstream. It's working fine but has a regression over v66 - v66 supports systems without Xv, this one does not. (not a release blocker, IMO, but might not be too much effort to add this again) Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Record activity for XO-1.5
On 20 April 2010 19:07, Aleksey Lim wrote: > In my mind, switch to camerabin would be the best way to go. Unfortunately > camerabin cant work as is on XO-1, it should be patched to let Record > use two phases encoding and it looks like pretty special in case of > upstream. But new Record could work on XO-1.5. OK, I read some more about camerabin and understand now. camerabin is a gstreamer element which provides the functionality of showing a video feed, saving it to a file, taking photos, and recording audio, and it lets you pick-and-mix those elements at your choosing. It does indeed sound like a good fit for record. One blocking problem in its current state is that it during video recording, the only option is for it to encoding theora video and vorbis audio on-the-fly. This is too much for the XO-1, probably any low-end system, and possibly even XO-1.5; we need to avoid the on-the-fly vorbis encoding, saving to wav and then re-encoding later. Another blocking issue is that it's incomplete-- see this page http://gstreamer.freedesktop.org/wiki/CameraBin So while I agree its a nice looking option, I think it's a 3-step process for the Record roadmap: 1. Make a working Record activity without camerabin 2. Assist camerabin developers in camerabin development until it's included in gst-plugin-good (or wait for the existing group of developers to achieve this) 3. Tweak Record to use camerabin I'm working on #1 (but probably can't dedicate much more time to this). Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: How to build an .img
Bastien writes:
> How to build a modified os802_fr.img (and its friend fs.zip)?
Ok, I made some progress.
http://wiki.laptop.org/go/Image_builder was helpful.
I managed to create my own images (fr802.crc, fr802.img, fr802.img.md5)
using build.py script.
But I still have two problems:
1. using the G1G1/802 activities gives an error about missing licenses.
What activities should I use in bundles/ to avoid this problem?
2. I told build.py to run a script which removes the file I want to get
rid of (which is ${imgdir}/home/olpc/.sugar-update) - but the script
fails and complains this file is missing.
Any idea?
Thanks a lot,
--
Bastien
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: Sugar Labs logo in bottom-left corner of olpc-bootanim
On Wed, Apr 21, 2010 at 7:54 AM, Ed McNierney wrote: > Folks - > > It's my impression that the boot animation in grayscale is an equally > important part of the XO design. IIRC, we went to some effort to use a > non-standard Fedora badge in order to retain the grayscale color scheme. So > if we're going to add a Sugar Labs graphic we should keep to the same > scheme. > >- Ed > > > On Apr 21, 2010, at 7:12 AM, Sean DALY wrote: > > > Colors (and different ones every time ;-) are an integral part of the > > Sugar Labs branding. > > > > And, we specifically chose to link boot logo colors to releases for > > SoaS precisely to aid everyone in identifying the versions :-) > > > > thanks > > > > Sean > > > > > > On Wed, Apr 21, 2010 at 5:30 AM, Bernie Innocenti < ber...@codewiz.org> > wrote: > >> On Tue, 2010-04-20 at 12:00 +0200, Sean DALY wrote: > >>> Yay for imagemagick Bernie ! > >>> > >>> can there be colors in the logo? > >> > >> Since everything else, including Fedora Remix logo, is rendered in a > >> subtle grey scale, I thought that something colorful in the corner would > >> have been a little too showy. > >> > >> If nobody is opposed, I'd also like a colorful logo to break the > >> monotony of the boot sequence: the color pair would change on every > >> release, helping users identify the version of Sugar running on their > >> computer. > >> > >> -- > >> // Bernie Innocenti - http://codewiz.org/ > >> \X/ Sugar Labs - http://sugarlabs.org/ > The OLPC/Sugar color design is described here, wiki.sugarlabs.org/go/Human_Interface_Guidelines/The_Sugar_Interface/Colors. Generally, gray-scale is used for non-personal elements, color for personal products such as Journal Activity instances. Extending this a bit, one might enliven the sugarlabs logo at the final frame, just before the Learner's Home view appears, connecting it more closely to the Sugar Learner environment than the earlier boot, which is more the responsibility of GNU/Linux and the distribution packaging. --Fred ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: How to build an .img
Hi, To build custom os from 802 for example you might use pilgrim[1]. Then to generate fs.zip file you need the OLPC implemention of bios-crypto package: # git clone git://dev.laptop.org/bios-crypto # cd bios-crypto/build # make With your keys you can sign the os generated. Regards, Esteban. [1] http://wiki.laptop.org/go/Building_custom_images 2010/4/20 Bastien > Hi all, > > OLPC France is creating customization keys (including the 802 version of > the OS) to help update the 100 XOs (soon to be 150) that children use in > Madagascar, Nosy Komba. > > We'd like to get rid of the initial message "Do you want to update the > software and the activity?" - children won't be able to connect to the > internet for now (we're working on this.) > > James told us to get rid of the /home/olpc/.sugar-update file, which is > fine, but how to exclude this file from the customization key? > > How to build a modified os802_fr.img (and its friend fs.zip)? We don't > plan to distribute this image. > > Thanks for any hint, > > -- > Bastien > ___ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel > ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Sugar Labs logo in bottom-left corner of olpc-bootanim
Folks - It's my impression that the boot animation in grayscale is an equally important part of the XO design. IIRC, we went to some effort to use a non-standard Fedora badge in order to retain the grayscale color scheme. So if we're going to add a Sugar Labs graphic we should keep to the same scheme. - Ed On Apr 21, 2010, at 7:12 AM, Sean DALY wrote: > Colors (and different ones every time ;-) are an integral part of the > Sugar Labs branding. > > And, we specifically chose to link boot logo colors to releases for > SoaS precisely to aid everyone in identifying the versions :-) > > thanks > > Sean > > > On Wed, Apr 21, 2010 at 5:30 AM, Bernie Innocenti wrote: >> On Tue, 2010-04-20 at 12:00 +0200, Sean DALY wrote: >>> Yay for imagemagick Bernie ! >>> >>> can there be colors in the logo? >> >> Since everything else, including Fedora Remix logo, is rendered in a >> subtle grey scale, I thought that something colorful in the corner would >> have been a little too showy. >> >> If nobody is opposed, I'd also like a colorful logo to break the >> monotony of the boot sequence: the color pair would change on every >> release, helping users identify the version of Sugar running on their >> computer. >> >> -- >> // Bernie Innocenti - http://codewiz.org/ >> \X/ Sugar Labs - http://sugarlabs.org/ >> >> > ___ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Sugar Labs logo in bottom-left corner of olpc-bootanim
Colors (and different ones every time ;-) are an integral part of the Sugar Labs branding. And, we specifically chose to link boot logo colors to releases for SoaS precisely to aid everyone in identifying the versions :-) thanks Sean On Wed, Apr 21, 2010 at 5:30 AM, Bernie Innocenti wrote: > On Tue, 2010-04-20 at 12:00 +0200, Sean DALY wrote: >> Yay for imagemagick Bernie ! >> >> can there be colors in the logo? > > Since everything else, including Fedora Remix logo, is rendered in a > subtle grey scale, I thought that something colorful in the corner would > have been a little too showy. > > If nobody is opposed, I'd also like a colorful logo to break the > monotony of the boot sequence: the color pair would change on every > release, helping users identify the version of Sugar running on their > computer. > > -- > // Bernie Innocenti - http://codewiz.org/ > \X/ Sugar Labs - http://sugarlabs.org/ > > ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
SD card compatibility (was: Re: B3 with different RAM chips)
On Tue, Apr 20, 2010 at 09:27:47PM -0400, John Watlington wrote: There a number of known issues. First, the performance of the external SD port on the XO-1 was belatedly discovered to have a high bit-error rate. [...] Is there a way to observe this from user space? On XO-1.5, we ran into similar issues. I fixed it for most cards, but there are notable exceptions. I was not able to eliminate the bit-error rate for any random card... What did you do to make it work for those cards? Did it require hardware changes or might tweaking some registers help? CU Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ signature.asc Description: Digital signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Access points - Engenius Senao EOC-3610S
Hello, Has anyone any experience using these APs with the XOs? http://www.keenansystems.com/engenius_senao_600mw_802bg_EOC-3610s_ext.htm David Leeming Honiara ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
