Re: HTML Canvas performance in the Browse activity
I suspect that the reason relates to the OLPC's unique screen. The physical pixels are spaced at 200 per inch horizontally and vertically. But there's only one color per pixel, not three. Each pixel lights up in a particular color. In a 'red' pixel, the green and blue sub-values from the frame buffer are ignored (but they get averaged into a nearby blue pixel by the dcon chip). (In 'normal' 96 dpi screens they actually have three subpixels horizontally (red, green, and blue), so the resolution in the horizontal direction is almost 300 dpi while vertically it's only 96 dpi.) Perhaps it's that you'd like the software to draw very crisp text by knowing that the screen really renders 200 dpi, but draw pictures at some lower dpi like 134, knowing that you can't represent all the colors in the original pixels unless you enlarge it somewhat. > The XO browser has two problems actually: 1) performance issue caused by > scaling everything up; 2) the difference in the scaling logic from a > normal Gecko build. > Problem 2: Keeping the current 134 DPI value would always require Gecko to > be patched, thus making it different from other Gecko builds. Maybe the > browser could use 200 DPI? Perhaps pages would render too big. Is there a good reason that the upstream Gecko maintainers wouldn't take this a patch, or one like it? As long as the scale factor is 1 on ordinary screens (and the code optimizes that path), adding this would have little impact on speed or space on non-OLPCs. (And if Pixel Qi succeeds in selling their screens, there are going to be more 'unusual' cheap & high performance screens that we'll want good free software support for.) John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Fwd: Xo 1.5 wlan]
On Sunday 31 May 2009 11:15:58 am Tomeu Vizoso wrote: > On Sun, May 31, 2009 at 16:09, Tiago Marques wrote: > > On 5/31/09, John Watlington wrote: > >> On May 30, 2009, at 12:04 PM, Reinder E.N. de Haan wrote: > >>> Subject: Xo 1.5 wlan > >>> Date: Thu, 07 May 2009 19:56:27 +0200 > >>> From: Reinder de Haan > >>> To: John Watlington > >>> > >>> Hello, > >>> > >>> I have a couple of questions regarding the wlan module in xo 1.5; > >>> > >>> 1) will it be an off the shelf module (3th party) or a quanta/olpc > >>> 'private' module > >> > >> One of the complications of the Gen 1.5 design has been improving > >> the WLAN module. The existing module takes lots of power, and > >> the USB driver still needs extensive modification to speed up > >> suspend/resume. > > > > Being power the major concern, will wireless range also be enhanced in > > some way? Most of the early claims that the XO had a top class > > wireless range have not materialized, at least when I compare it to > > other devices like a Fon2100 or an IPW2200 from Intel, which is > > probably the device with best wireless range that I've ever seen. > > > > A way to change the transmit power in software would be great for > > power and range, depending on the application. Does the module have > > anything like that or are you just mainly focusing on power and > > relegating range to 2nd place? > > I think that there have been recent improvements in the algorithm for > choosing the transmission power in the linux kernel. I'm not sure if > all wifi drivers benefit from it, but a laptop with b43 has improved > dramatically its range after updating to Ubuntu Jaunty. I think what you're talking about is the rate selection algorithm, I dont think the kernel dynamically changes the Tx power. Linux has moved to minstrel [0] as its default rate control algorithm, which is way better than what we had previously in dealing with lots of collisions, where slower rates may not increase the chance of getting a packet through. This scenario is common in schools with lots of XOs. Some drivers still have their own algorithm, it is probable that the closed fullmac Marvell implementation has one. [0] http://linuxwireless.org/en/developers/Documentation/mac80211/RateControl/minstrel > > > Best regards, > > > > Tiago Marques > > > >> Unlike Gen 1, we don't have the time or expected market to > >> develop and certify a custom module. > >> > >> The current plan is to use an existing WLAN module, based on > >> the Marvell 88W8686 and connected to the system using an > >> SDIO interface. > >> > >>> 2) if it is a private module please break out jtag and the serial port > >>> for debugging (xo 1.0 only had jtag.. serial ended right at the > >>> balls of > >>> the chip :-( > >> > >> Sorry, the module doesn't bring any of the internal debugging signal > >> out. > >> > >>> 3a) if its a 3th party moduel is it posible to buy it somewhere ? > >> > >> Yes and no. There are 88W8686-based SDIO modules already > >> available, and electrically/software-wise they will be identical to the > >> one we are planning to use. > >> > >> The actual module used in XO-1.5 will have a half-height miniPCI-e > >> form factor. Even if you could buy it in small quantities, you > >> would have > >> to arrange an adapter board to use internally. > >> > >> Cheers, > >> wad ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: HTML Canvas performance in the Browse activity
On Sun, May 31, 2009 at 9:12 PM, Mihai Sucan wrote: >> - which version(s) of Sugar targets your project? > > I am not intimate with the development cycle and work-flow of the OLPC XO. > I learned sufficiently to see it's Fedora Core-based, and that Sugar is > becoming distro agnostic. > > Thus, my answer is simply limited to my current usage of the XO. I want > PaintWeb to work well on the OLPC XO-1 laptop, with the latest stable OS > release (that's 8.2.1). That's a F-9 + Sugar 0.82. Tomeu is currently working on Sugar 0.84, which is being build & polished into Sugar-on-a-Stick (F-11+Sugar 0.84.x). Sugar-on-a-Stick can boot (slowly) from a USB stick on an XO. It'd be interesting to see what performance it gets. My guess is that xulrunner isn't patched in SoaS, but Hulahop probably is the mostly the same as on XO OS 8.2.1. >> - already have an idea about how are going to be deployed any >> modifications that result from this? > > The modifications resulting from this work are already deployed into > PaintWeb. You can try the last working SVN trunk snapshot at: > > http://www.robodesign.ro/paintweb/trunk/src/paintweb.html And PaintWeb will be deployed as part of Moodle in the the XS. I've asked Mihai to make sure that PW can work with XO OS 8.2.1 as it is. If future Sugar or XO OS improve the behaviour of gecko in this area, fantastic. But for now, it has a workaround that works great. Hopefully these notes will help (a) get a better fix for the scaling issue and (b) implement workarounds in webapps that want to run with 8.2.1 :-) cheers, 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 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: HTML Canvas performance in the Browse activity
Hello Tomeu! Le Sun, 31 May 2009 20:10:49 +0300, Tomeu Vizoso a écrit: > On Sun, May 31, 2009 at 18:48, Mihai Sucan wrote: >> Hello everyone! >> >> I am Mihai Sucan, and I am working over the summer to develop and >> integrate a paint tool [1] into Moodle. [2] I am also involved in doing >> performance testing on the XO laptop. > > Thanks a lot for your nice work untangling this mess. I'm forwarding > this email to sugar-devel because I guess you want the Sugar > developers be aware of this. You're all welcome. ;) > Let me ask you a couple of questions: > > - which version(s) of Sugar targets your project? I am not intimate with the development cycle and work-flow of the OLPC XO. I learned sufficiently to see it's Fedora Core-based, and that Sugar is becoming distro agnostic. Thus, my answer is simply limited to my current usage of the XO. I want PaintWeb to work well on the OLPC XO-1 laptop, with the latest stable OS release (that's 8.2.1). > - already have an idea about how are going to be deployed any > modifications that result from this? The modifications resulting from this work are already deployed into PaintWeb. You can try the last working SVN trunk snapshot at: http://www.robodesign.ro/paintweb/trunk/src/paintweb.html The paintweb.js file contains the updateCanvasScaling() function which does the Canvas scaling. The application is working fine on the XO. Best regards, Mihai -- Mihai Sucan http://www.robodesign.ro ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Longer XO transformer power cord in the plans?
On Sun, May 31, 2009 at 3:34 PM, Reinder de Haan wrote: > > Tiago Marques wrote: > > On 5/31/09, Reinder de Haan wrote: > >> > >> Sascha Silbe wrote: > >>> On Sun, May 31, 2009 at 03:16:53PM +1000, James Cameron wrote: > >>> > 1. Earthing. The current design has no earth at the AC end, and is > isolated in relation to the DC end. An earthed AC plug in some > countries produces a more reliable and positive insertion and > anchoring. > >>> All "travel adapters" (power outlet adapters) I've come across so far > >>> had no earthing so would be impossible to use (unaltered). Of course > >>> this wouldn't be much of a change as the current wall warts also don't > >>> fit any adapter I've seen at shops. At SugarCamp in Paris, quite a few > >>> people (including myself) had "custom" ones, i.e. with mechanic > >>> alterations. > >>> Personally, I feel comfortable making minor mechanic changes to an > >>> adapter, but I won't usually dare using a non-earthing adapter with a > >>> device having an earthed plug (unless I know for sure this is safe). > >>> > >>> Actually, if you are able to use a standard plug (e.g. IEC-60320-C5/C6) > >>> at the power supply end, above won't apply at all as it's usually easy > >>> to get a matching cable, no travel adapter needed. :) > >> +1 for inline adaptor its MUCH easier to exchange only the mains cable: > >> 1) when its demaged > >> 2) when shiping to a different part of the world > >> you would need only one powersupply brick for (almost?) all or the > world. > >> i have seen some companies ship a couple of different cables so the > >> device is usable almost everywhere and doesn't need to be custom > >> packed/country. > >> > >> i would go which IEC-60320 C8/C9 which is used for half of the laptops > >> today. > > > > Completely not the picture around this part of Europe. Most of them > > come with C13 and some are being sold with C7, which is pretty much a > > oops i meant C7/C8 NOT C9!! > > > standard for other types electronics. C13 would be my favorite, if the > > size of the plug is not an issue, since it is also the standard for > > computer power supplies. As mentioned above, C5 would also be sweet. > > both are an earthed connector and so 'require' an earthed outlet. > combined with that almost all power supplies i have seen with a C5/C6 or > C13/C14 connect the earth input to the ground/0V dc output... > if you insert such power supply into an not earthed outlet (which are > quite common) > your whole laptop will be at ~1/2*Uin Vac due to the filter capacitors > in the mains filter. > which gives a nasty shock if you touch both a non insulated part of your > laptop and a earthed object.. > Sadly true, but a redisign of the XO power supply wouldn't take the earthing into account, right? So no problems for us. The power adapter can be design like with the C17 instead, which will also accept the more abundant C13 cables. The unpolarised C7 is also quite common and smaller, could be a better choice, IMHO, than any of the C13 or C5. Best regards, Tiago Marques > > > As for safety, adding something like the cable plug of the original > > Xbox pads would work perfectly and it's not as expensive as Apple's > > magnetic plug. Cost of this is something I have no clue about. > > > > Best regards, > > > > Tiago Marques > > > >> i feel a earthed design only increases the risks, even more so when you > >> cant depend on the quality of the mains supply. > >> the only advantage to the earthed design that im aware of is that the > >> power supply easier(cheaper?) meets EMC/FCC regulations. > >> > >>> I hope future XO versions will still have the same broad power input > >>> specs as the XO-1. It's been very useful already (e.g. cable-only "car > >>> adapter", no voltage conversion or even voltage limit necessary). > >>> > >>> CU Sascha > >>> > >>> > >>> > > >>> > >>> ___ > >>> 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 > >> > > > ___ > 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: HTML Canvas performance in the Browse activity
On Sun, May 31, 2009 at 18:48, Mihai Sucan wrote: > Hello everyone! > > I am Mihai Sucan, and I am working over the summer to develop and > integrate a paint tool [1] into Moodle. [2] I am also involved in doing > performance testing on the XO laptop. Thanks a lot for your nice work untangling this mess. I'm forwarding this email to sugar-devel because I guess you want the Sugar developers be aware of this. Let me ask you a couple of questions: - which version(s) of Sugar targets your project? - already have an idea about how are going to be deployed any modifications that result from this? Thanks, Tomeu > HTML 5 [3] has a new Canvas element [4] which provides an API for bitmap > drawing operations on a bidimensional surface. Rendering is generally > quite fast on desktop Web browsers, and it requires no plugins like Flash > or Java. > > = The problem = > > On the XO OS 8.2.x, and probably on older versions, HTML Canvas > performance is most often very slow because the default Browse activity is > configured to scale pages. Typically, pages are rendered using 96 DPI in > Web browsers, but on the XO the browser renders the pages using 134 DPI. > This ensures the text and images are still readable - otherwise they'd be > far too small because the XO display [5] has a high DPI resolution. > Nonetheless, scaling images up is quite slow - the high-quality bilinear > filter is used. This impacts the overall performance of the browser and > moreso the performance of the Canvas element. > > The Browse activity uses the xulrunner package [6], which contains the > Gecko layout engine [7] version 1.9.0 (the same as in Firefox 3.0). > > Users can change the DPI used for rendering a page by going to > about:config, where they can modify the layout.css.dpi value. Yet, Hulahop > includes some piece of puzzling code [8] which always resets the > layout.css.dpi configuration value to 134. > > The xulrunner package includes a patch [9] which alters the page scaling > logic [10] in Gecko. This patch makes a simple, yet important change to > how the DPI config value is used for scaling the page being rendered. A > normal Gecko build only scales pages using an integer scaling factor, but > on the XO the scaling factor can also be a floating-point number. This > means that a normal Gecko build uses a scale factor of 1 for DPI < 192, > and a scale factor of 2 for 192 <= DPI <= 288, and so on. > > = Patches = > > Gecko 1.9.1 includes a patch [11] which adds a new config option > layout.css.devPixelsPerPx. This allows OLPC to configure the browser such > that physical units render properly scaled using the correct DPI value, > but not the CSS pixel values. CSS pixels could be equal to device pixels - > they would all render small, but much faster. > > Another Gecko patch worth being noted is the CSS image-rendering property > support [12]. This would allow Web developers to tell Gecko to use > nearest-neighbour instead of bilinear interpolation for the scaling of > elements. > > = Solutions = > > The XO browser has two problems actually: 1) performance issue caused by > scaling everything up; 2) the difference in the scaling logic from a > normal Gecko build. > > Problem 1: Having everything render using 96 DPI is not acceptable - pages > would be unreadable. I would suggest that Gecko on the XO scales images > using a faster algorithm instead of the bilinear one. It would also be > interesting to experiment with the new layout.css.devPixelsPerPx > configuration set to 1. Maybe hardware acceleration in newer XOs? > > Problem 2: Keeping the current 134 DPI value would always require Gecko to > be patched, thus making it different from other Gecko builds. Maybe the > browser could use 200 DPI? Perhaps pages would render too big. > > A different line of thought would be: "why complain about problem 2?" I > mean, Web developers are not supposed to be tinkering with DPI in their > Web pages - it's the problem of the browser. > > As a Web developer I do not mind about problem 2 if problem 1 is fixed. > Problem 2 is important only when trying to work around problem 1. > > = Work around = > > It's simple: you need to scale down the Canvas element such that Gecko > cancels the scaling. However, you need to find out the DPI used for > rendering the page. You can do this only by using CSS 3 Media Queries [13]. > > Gecko has support for floating-point pixel values, so there's nothing to > worry about values being floating-point numbers. The work around I came up > with is described at: > > http://wiki.laptop.org/go/HTML_canvas_performance#Work_around > > This work-around is not ideal simply because it would be best if the > Browse activity would be faster by default. What do you guys think? Is > there something that can be done? The performance improvement is far from > being marginal when the work-around is used. > > > Sorry for this lengthy email. ;) > > > (I have posted this on the wiki as well for further reference to others > who
Re: HTML Canvas performance in the Browse activity
I have nothing to add, but would like to thank you for this work, and agree that the issue is important and merits further work. Jameson ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
HTML Canvas performance in the Browse activity
Hello everyone! I am Mihai Sucan, and I am working over the summer to develop and integrate a paint tool [1] into Moodle. [2] I am also involved in doing performance testing on the XO laptop. HTML 5 [3] has a new Canvas element [4] which provides an API for bitmap drawing operations on a bidimensional surface. Rendering is generally quite fast on desktop Web browsers, and it requires no plugins like Flash or Java. = The problem = On the XO OS 8.2.x, and probably on older versions, HTML Canvas performance is most often very slow because the default Browse activity is configured to scale pages. Typically, pages are rendered using 96 DPI in Web browsers, but on the XO the browser renders the pages using 134 DPI. This ensures the text and images are still readable - otherwise they'd be far too small because the XO display [5] has a high DPI resolution. Nonetheless, scaling images up is quite slow - the high-quality bilinear filter is used. This impacts the overall performance of the browser and moreso the performance of the Canvas element. The Browse activity uses the xulrunner package [6], which contains the Gecko layout engine [7] version 1.9.0 (the same as in Firefox 3.0). Users can change the DPI used for rendering a page by going to about:config, where they can modify the layout.css.dpi value. Yet, Hulahop includes some piece of puzzling code [8] which always resets the layout.css.dpi configuration value to 134. The xulrunner package includes a patch [9] which alters the page scaling logic [10] in Gecko. This patch makes a simple, yet important change to how the DPI config value is used for scaling the page being rendered. A normal Gecko build only scales pages using an integer scaling factor, but on the XO the scaling factor can also be a floating-point number. This means that a normal Gecko build uses a scale factor of 1 for DPI < 192, and a scale factor of 2 for 192 <= DPI <= 288, and so on. = Patches = Gecko 1.9.1 includes a patch [11] which adds a new config option layout.css.devPixelsPerPx. This allows OLPC to configure the browser such that physical units render properly scaled using the correct DPI value, but not the CSS pixel values. CSS pixels could be equal to device pixels - they would all render small, but much faster. Another Gecko patch worth being noted is the CSS image-rendering property support [12]. This would allow Web developers to tell Gecko to use nearest-neighbour instead of bilinear interpolation for the scaling of elements. = Solutions = The XO browser has two problems actually: 1) performance issue caused by scaling everything up; 2) the difference in the scaling logic from a normal Gecko build. Problem 1: Having everything render using 96 DPI is not acceptable - pages would be unreadable. I would suggest that Gecko on the XO scales images using a faster algorithm instead of the bilinear one. It would also be interesting to experiment with the new layout.css.devPixelsPerPx configuration set to 1. Maybe hardware acceleration in newer XOs? Problem 2: Keeping the current 134 DPI value would always require Gecko to be patched, thus making it different from other Gecko builds. Maybe the browser could use 200 DPI? Perhaps pages would render too big. A different line of thought would be: "why complain about problem 2?" I mean, Web developers are not supposed to be tinkering with DPI in their Web pages - it's the problem of the browser. As a Web developer I do not mind about problem 2 if problem 1 is fixed. Problem 2 is important only when trying to work around problem 1. = Work around = It's simple: you need to scale down the Canvas element such that Gecko cancels the scaling. However, you need to find out the DPI used for rendering the page. You can do this only by using CSS 3 Media Queries [13]. Gecko has support for floating-point pixel values, so there's nothing to worry about values being floating-point numbers. The work around I came up with is described at: http://wiki.laptop.org/go/HTML_canvas_performance#Work_around This work-around is not ideal simply because it would be best if the Browse activity would be faster by default. What do you guys think? Is there something that can be done? The performance improvement is far from being marginal when the work-around is used. Sorry for this lengthy email. ;) (I have posted this on the wiki as well for further reference to others who need help with Canvas on the XO) References: [1] http://code.google.com/p/paintweb [2] http://www.moodle.org [3] http://www.whatwg.org/specs/web-apps/current-work/multipage/ [4] http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html [5] http://wiki.laptop.org/go/Display [6] http://koji.fedoraproject.org/koji/buildinfo?buildID=60150 [7] http://en.wikipedia.org/wiki/Gecko_(layout_engine) [8] http://dev.laptop.org/git/projects/hulahop/diff/python/__in
Re: Longer XO transformer power cord in the plans?
Tiago Marques wrote: > On 5/31/09, Reinder de Haan wrote: >> >> Sascha Silbe wrote: >>> On Sun, May 31, 2009 at 03:16:53PM +1000, James Cameron wrote: >>> 1. Earthing. The current design has no earth at the AC end, and is isolated in relation to the DC end. An earthed AC plug in some countries produces a more reliable and positive insertion and anchoring. >>> All "travel adapters" (power outlet adapters) I've come across so far >>> had no earthing so would be impossible to use (unaltered). Of course >>> this wouldn't be much of a change as the current wall warts also don't >>> fit any adapter I've seen at shops. At SugarCamp in Paris, quite a few >>> people (including myself) had "custom" ones, i.e. with mechanic >>> alterations. >>> Personally, I feel comfortable making minor mechanic changes to an >>> adapter, but I won't usually dare using a non-earthing adapter with a >>> device having an earthed plug (unless I know for sure this is safe). >>> >>> Actually, if you are able to use a standard plug (e.g. IEC-60320-C5/C6) >>> at the power supply end, above won't apply at all as it's usually easy >>> to get a matching cable, no travel adapter needed. :) >> +1 for inline adaptor its MUCH easier to exchange only the mains cable: >> 1) when its demaged >> 2) when shiping to a different part of the world >> you would need only one powersupply brick for (almost?) all or the world. >> i have seen some companies ship a couple of different cables so the >> device is usable almost everywhere and doesn't need to be custom >> packed/country. >> >> i would go which IEC-60320 C8/C9 which is used for half of the laptops >> today. > > Completely not the picture around this part of Europe. Most of them > come with C13 and some are being sold with C7, which is pretty much a oops i meant C7/C8 NOT C9!! > standard for other types electronics. C13 would be my favorite, if the > size of the plug is not an issue, since it is also the standard for > computer power supplies. As mentioned above, C5 would also be sweet. both are an earthed connector and so 'require' an earthed outlet. combined with that almost all power supplies i have seen with a C5/C6 or C13/C14 connect the earth input to the ground/0V dc output... if you insert such power supply into an not earthed outlet (which are quite common) your whole laptop will be at ~1/2*Uin Vac due to the filter capacitors in the mains filter. which gives a nasty shock if you touch both a non insulated part of your laptop and a earthed object.. > As for safety, adding something like the cable plug of the original > Xbox pads would work perfectly and it's not as expensive as Apple's > magnetic plug. Cost of this is something I have no clue about. > > Best regards, > > Tiago Marques > >> i feel a earthed design only increases the risks, even more so when you >> cant depend on the quality of the mains supply. >> the only advantage to the earthed design that im aware of is that the >> power supply easier(cheaper?) meets EMC/FCC regulations. >> >>> I hope future XO versions will still have the same broad power input >>> specs as the XO-1. It's been very useful already (e.g. cable-only "car >>> adapter", no voltage conversion or even voltage limit necessary). >>> >>> CU Sascha >>> >>> >>> >>> >>> ___ >>> 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 >> > ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Fwd: Xo 1.5 wlan]
On Sun, May 31, 2009 at 16:09, Tiago Marques wrote: > On 5/31/09, John Watlington wrote: >> >> On May 30, 2009, at 12:04 PM, Reinder E.N. de Haan wrote: >> >>> Subject: Xo 1.5 wlan >>> Date: Thu, 07 May 2009 19:56:27 +0200 >>> From: Reinder de Haan >>> To: John Watlington >>> >>> Hello, >>> >>> I have a couple of questions regarding the wlan module in xo 1.5; >>> >>> 1) will it be an off the shelf module (3th party) or a quanta/olpc >>> 'private' module >> >> One of the complications of the Gen 1.5 design has been improving >> the WLAN module. The existing module takes lots of power, and >> the USB driver still needs extensive modification to speed up >> suspend/resume. >> > > Being power the major concern, will wireless range also be enhanced in > some way? Most of the early claims that the XO had a top class > wireless range have not materialized, at least when I compare it to > other devices like a Fon2100 or an IPW2200 from Intel, which is > probably the device with best wireless range that I've ever seen. > > A way to change the transmit power in software would be great for > power and range, depending on the application. Does the module have > anything like that or are you just mainly focusing on power and > relegating range to 2nd place? I think that there have been recent improvements in the algorithm for choosing the transmission power in the linux kernel. I'm not sure if all wifi drivers benefit from it, but a laptop with b43 has improved dramatically its range after updating to Ubuntu Jaunty. Regards, Tomeu > Best regards, > > Tiago Marques > >> Unlike Gen 1, we don't have the time or expected market to >> develop and certify a custom module. >> >> The current plan is to use an existing WLAN module, based on >> the Marvell 88W8686 and connected to the system using an >> SDIO interface. >> >>> 2) if it is a private module please break out jtag and the serial port >>> for debugging (xo 1.0 only had jtag.. serial ended right at the >>> balls of >>> the chip :-( >> >> Sorry, the module doesn't bring any of the internal debugging signal >> out. >> >>> 3a) if its a 3th party moduel is it posible to buy it somewhere ? >> >> Yes and no. There are 88W8686-based SDIO modules already >> available, and electrically/software-wise they will be identical to the >> one we are planning to use. >> >> The actual module used in XO-1.5 will have a half-height miniPCI-e >> form factor. Even if you could buy it in small quantities, you >> would have >> to arrange an adapter board to use internally. >> >> Cheers, >> wad >> >> ___ >> 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 > ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Fwd: Xo 1.5 wlan]
On 5/31/09, John Watlington wrote: > > On May 30, 2009, at 12:04 PM, Reinder E.N. de Haan wrote: > >> Subject: Xo 1.5 wlan >> Date: Thu, 07 May 2009 19:56:27 +0200 >> From: Reinder de Haan >> To: John Watlington >> >> Hello, >> >> I have a couple of questions regarding the wlan module in xo 1.5; >> >> 1) will it be an off the shelf module (3th party) or a quanta/olpc >> 'private' module > > One of the complications of the Gen 1.5 design has been improving > the WLAN module. The existing module takes lots of power, and > the USB driver still needs extensive modification to speed up > suspend/resume. > Being power the major concern, will wireless range also be enhanced in some way? Most of the early claims that the XO had a top class wireless range have not materialized, at least when I compare it to other devices like a Fon2100 or an IPW2200 from Intel, which is probably the device with best wireless range that I've ever seen. A way to change the transmit power in software would be great for power and range, depending on the application. Does the module have anything like that or are you just mainly focusing on power and relegating range to 2nd place? Best regards, Tiago Marques > Unlike Gen 1, we don't have the time or expected market to > develop and certify a custom module. > > The current plan is to use an existing WLAN module, based on > the Marvell 88W8686 and connected to the system using an > SDIO interface. > >> 2) if it is a private module please break out jtag and the serial port >> for debugging (xo 1.0 only had jtag.. serial ended right at the >> balls of >> the chip :-( > > Sorry, the module doesn't bring any of the internal debugging signal > out. > >> 3a) if its a 3th party moduel is it posible to buy it somewhere ? > > Yes and no. There are 88W8686-based SDIO modules already > available, and electrically/software-wise they will be identical to the > one we are planning to use. > > The actual module used in XO-1.5 will have a half-height miniPCI-e > form factor. Even if you could buy it in small quantities, you > would have > to arrange an adapter board to use internally. > > Cheers, > wad > > ___ > 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: slow wiki?
Ok, just got registered. Best regards On 5/31/09, Seth Woodworth wrote: > Sure, let's move this conversation over to the Volunteer Infrastructure > Group list: > > http://lists.laptop.org/listinfo/olpc-sysadmin > > I will start this conversation back up there Monday. > > --Seth > > On Sat, May 30, 2009 at 7:28 AM, Tiago Marques wrote: > >> I'm currently somewhat busy but I may be able to find some free time. >> If this can be done remotely, I may be able to help. >> Do you have any prediction of required time to finish this? >> >> Best regards, >> >> Tiago Marques >> >> On 5/30/09, Seth Woodworth wrote: >> > The Imagemagick install on pedal (which hosts the wiki) has been broken >> off >> > and on for quite some time. The plan of record is to migrate wiki.l.o >> > to >> a >> > new, clean VM with some additional spam features and the latest stable >> > MediaWiki release. The vig.l.o wiki represents some sandboxing effort >> for >> > this goal. >> > >> > Unfortunately, I have no real schedule planned for when this will be >> > finished. It would be an ideal project for an awsome wiki-sysadmin to >> work >> > on with Dogi and myself, but I *also* haven't taken the time to look >> > for >> one >> > ^__^ >> > >> > Someone want to help with the wiki migration or find a volunteer who >> > can? >> > >> > --Sww >> > >> > On Fri, May 29, 2009 at 12:24 PM, Sameer Verma wrote: >> > >> >> On Fri, May 29, 2009 at 6:47 AM, wrote: >> >> > anyone know why the olpc wiki is responding so slowly? >> >> > every new page i load is taking a really long time. >> >> > >> >> > paul >> >> > =- >> >> > paul fox, p...@laptop.org >> >> > ___ >> >> > Devel mailing list >> >> > Devel@lists.laptop.org >> >> > http://lists.laptop.org/listinfo/devel >> >> > >> >> >> >> It gets really slow on pages with several images...maybe because the >> >> wiki isn't thumbnailing anymore? >> >> >> >> Sameer >> >> -- >> >> Dr. Sameer Verma, Ph.D. >> >> Associate Professor of Information Systems >> >> San Francisco State University >> >> San Francisco CA 94132 USA >> >> http://verma.sfsu.edu/ >> >> http://opensource.sfsu.edu/ >> >> ___ >> >> 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: Longer XO transformer power cord in the plans?
On 5/31/09, Reinder de Haan wrote: > > > Sascha Silbe wrote: >> On Sun, May 31, 2009 at 03:16:53PM +1000, James Cameron wrote: >> >>> 1. Earthing. The current design has no earth at the AC end, and is >>> isolated in relation to the DC end. An earthed AC plug in some >>> countries produces a more reliable and positive insertion and anchoring. >> All "travel adapters" (power outlet adapters) I've come across so far >> had no earthing so would be impossible to use (unaltered). Of course >> this wouldn't be much of a change as the current wall warts also don't >> fit any adapter I've seen at shops. At SugarCamp in Paris, quite a few >> people (including myself) had "custom" ones, i.e. with mechanic >> alterations. >> Personally, I feel comfortable making minor mechanic changes to an >> adapter, but I won't usually dare using a non-earthing adapter with a >> device having an earthed plug (unless I know for sure this is safe). >> >> Actually, if you are able to use a standard plug (e.g. IEC-60320-C5/C6) >> at the power supply end, above won't apply at all as it's usually easy >> to get a matching cable, no travel adapter needed. :) > > +1 for inline adaptor its MUCH easier to exchange only the mains cable: > 1) when its demaged > 2) when shiping to a different part of the world > you would need only one powersupply brick for (almost?) all or the world. > i have seen some companies ship a couple of different cables so the > device is usable almost everywhere and doesn't need to be custom > packed/country. > > i would go which IEC-60320 C8/C9 which is used for half of the laptops > today. Completely not the picture around this part of Europe. Most of them come with C13 and some are being sold with C7, which is pretty much a standard for other types electronics. C13 would be my favorite, if the size of the plug is not an issue, since it is also the standard for computer power supplies. As mentioned above, C5 would also be sweet. As for safety, adding something like the cable plug of the original Xbox pads would work perfectly and it's not as expensive as Apple's magnetic plug. Cost of this is something I have no clue about. Best regards, Tiago Marques > > i feel a earthed design only increases the risks, even more so when you > cant depend on the quality of the mains supply. > the only advantage to the earthed design that im aware of is that the > power supply easier(cheaper?) meets EMC/FCC regulations. > >> >> I hope future XO versions will still have the same broad power input >> specs as the XO-1. It's been very useful already (e.g. cable-only "car >> adapter", no voltage conversion or even voltage limit necessary). >> >> CU Sascha >> >> >> >> >> ___ >> 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 > ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Longer XO transformer power cord in the plans?
On 5/31/09, James Cameron wrote: > I know of no such plans, but the physics of the configuration has a > bearing ... > > 1. a longer cable has a larger voltage drop, and so a greater amount of > power is lost as heat, leading to greater inefficiency of power use, > > 2. compensating for the voltage drop can only be done by either raising > the design voltage on the cable, or increasing the cross sectional area > of the copper, > > 3. raising the design voltage is an unattractive option, since it would > expose the user to greater risk, > > 4. increasing the cross sectional area would make the cable much > heavier, and a substantially higher cost, which would vary according to > metal prices, > > 5. increasing the length may also increase the trip hazard, and so > further reinforcement of the sheath and restraint points may be > required, > > 6. not every child will need an extra two metres. I have no idea of the kind of infrastructures kids have on the target market of the project, at least in developed countries it is a necessity for me, hence the e-mail I sent. > > Can you balance this against against the cost of properly placed > domestic 110V or 240V outlets? Nope, I understand that. Best regards, Tiago Marques > > -- > James Cameronmailto:qu...@us.netrek.org http://quozl.netrek.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: Longer XO transformer power cord in the plans?
On 31.05.2009, at 06:23, John Watlington wrote: > I am still getting quotes to see how this change might > impact the adapter cost, and getting the industrial designers > to think about it. Are you having them think of daisy-chaining, too? Like older PCs having both a C14 power inlet and a C13 outlet ... - Bert - ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Longer XO transformer power cord in the plans?
Sascha Silbe wrote: > On Sun, May 31, 2009 at 03:16:53PM +1000, James Cameron wrote: > >> 1. Earthing. The current design has no earth at the AC end, and is >> isolated in relation to the DC end. An earthed AC plug in some >> countries produces a more reliable and positive insertion and anchoring. > All "travel adapters" (power outlet adapters) I've come across so far > had no earthing so would be impossible to use (unaltered). Of course > this wouldn't be much of a change as the current wall warts also don't > fit any adapter I've seen at shops. At SugarCamp in Paris, quite a few > people (including myself) had "custom" ones, i.e. with mechanic > alterations. > Personally, I feel comfortable making minor mechanic changes to an > adapter, but I won't usually dare using a non-earthing adapter with a > device having an earthed plug (unless I know for sure this is safe). > > Actually, if you are able to use a standard plug (e.g. IEC-60320-C5/C6) > at the power supply end, above won't apply at all as it's usually easy > to get a matching cable, no travel adapter needed. :) +1 for inline adaptor its MUCH easier to exchange only the mains cable: 1) when its demaged 2) when shiping to a different part of the world you would need only one powersupply brick for (almost?) all or the world. i have seen some companies ship a couple of different cables so the device is usable almost everywhere and doesn't need to be custom packed/country. i would go which IEC-60320 C8/C9 which is used for half of the laptops today. i feel a earthed design only increases the risks, even more so when you cant depend on the quality of the mains supply. the only advantage to the earthed design that im aware of is that the power supply easier(cheaper?) meets EMC/FCC regulations. > > I hope future XO versions will still have the same broad power input > specs as the XO-1. It's been very useful already (e.g. cable-only "car > adapter", no voltage conversion or even voltage limit necessary). > > CU Sascha > > > > > ___ > 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: [Fwd: Xo 1.5 wlan]
On May 30, 2009, at 12:04 PM, Reinder E.N. de Haan wrote: > Subject: Xo 1.5 wlan > Date: Thu, 07 May 2009 19:56:27 +0200 > From: Reinder de Haan > To: John Watlington > > Hello, > > I have a couple of questions regarding the wlan module in xo 1.5; > > 1) will it be an off the shelf module (3th party) or a quanta/olpc > 'private' module One of the complications of the Gen 1.5 design has been improving the WLAN module. The existing module takes lots of power, and the USB driver still needs extensive modification to speed up suspend/resume. Unlike Gen 1, we don't have the time or expected market to develop and certify a custom module. The current plan is to use an existing WLAN module, based on the Marvell 88W8686 and connected to the system using an SDIO interface. > 2) if it is a private module please break out jtag and the serial port > for debugging (xo 1.0 only had jtag.. serial ended right at the > balls of > the chip :-( Sorry, the module doesn't bring any of the internal debugging signal out. > 3a) if its a 3th party moduel is it posible to buy it somewhere ? Yes and no. There are 88W8686-based SDIO modules already available, and electrically/software-wise they will be identical to the one we are planning to use. The actual module used in XO-1.5 will have a half-height miniPCI-e form factor. Even if you could buy it in small quantities, you would have to arrange an adapter board to use internally. Cheers, wad ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: slow wiki?
Sure, let's move this conversation over to the Volunteer Infrastructure Group list: http://lists.laptop.org/listinfo/olpc-sysadmin I will start this conversation back up there Monday. --Seth On Sat, May 30, 2009 at 7:28 AM, Tiago Marques wrote: > I'm currently somewhat busy but I may be able to find some free time. > If this can be done remotely, I may be able to help. > Do you have any prediction of required time to finish this? > > Best regards, > > Tiago Marques > > On 5/30/09, Seth Woodworth wrote: > > The Imagemagick install on pedal (which hosts the wiki) has been broken > off > > and on for quite some time. The plan of record is to migrate wiki.l.o to > a > > new, clean VM with some additional spam features and the latest stable > > MediaWiki release. The vig.l.o wiki represents some sandboxing effort > for > > this goal. > > > > Unfortunately, I have no real schedule planned for when this will be > > finished. It would be an ideal project for an awsome wiki-sysadmin to > work > > on with Dogi and myself, but I *also* haven't taken the time to look for > one > > ^__^ > > > > Someone want to help with the wiki migration or find a volunteer who can? > > > > --Sww > > > > On Fri, May 29, 2009 at 12:24 PM, Sameer Verma wrote: > > > >> On Fri, May 29, 2009 at 6:47 AM, wrote: > >> > anyone know why the olpc wiki is responding so slowly? > >> > every new page i load is taking a really long time. > >> > > >> > paul > >> > =- > >> > paul fox, p...@laptop.org > >> > ___ > >> > Devel mailing list > >> > Devel@lists.laptop.org > >> > http://lists.laptop.org/listinfo/devel > >> > > >> > >> It gets really slow on pages with several images...maybe because the > >> wiki isn't thumbnailing anymore? > >> > >> Sameer > >> -- > >> Dr. Sameer Verma, Ph.D. > >> Associate Professor of Information Systems > >> San Francisco State University > >> San Francisco CA 94132 USA > >> http://verma.sfsu.edu/ > >> http://opensource.sfsu.edu/ > >> ___ > >> 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: Longer XO transformer power cord in the plans?
On Sun, May 31, 2009 at 03:16:53PM +1000, James Cameron wrote: 1. Earthing. The current design has no earth at the AC end, and is isolated in relation to the DC end. An earthed AC plug in some countries produces a more reliable and positive insertion and anchoring. All "travel adapters" (power outlet adapters) I've come across so far had no earthing so would be impossible to use (unaltered). Of course this wouldn't be much of a change as the current wall warts also don't fit any adapter I've seen at shops. At SugarCamp in Paris, quite a few people (including myself) had "custom" ones, i.e. with mechanic alterations. Personally, I feel comfortable making minor mechanic changes to an adapter, but I won't usually dare using a non-earthing adapter with a device having an earthed plug (unless I know for sure this is safe). Actually, if you are able to use a standard plug (e.g. IEC-60320-C5/C6) at the power supply end, above won't apply at all as it's usually easy to get a matching cable, no travel adapter needed. :) I hope future XO versions will still have the same broad power input specs as the XO-1. It's been very useful already (e.g. cable-only "car adapter", no voltage conversion or even voltage limit necessary). 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
