using laptop charger
Hi! I am thinking about using my laptop's charger instead of the OLPC charger in the future as I move a lot and it's getting really tiresome to bring both chargers with me. The plan is to create a converter plug and use only the laptop's but it has different voltage levels. laptop: TOSHIBA part: PA3715U-1ACA model: PA-1750-24 output: 19V - 3.95A XO-1.75: DARFON model: BBOJ-C output: 13.5V - 1.85A So can I plug my XO to the TOSHIBA adapter? The page says that 11-18V needed, while the laptop's is 19V. Shall I use a resistor to drop the voltage or is it unnecessary? Power usage is not an issue to me. (BTW I will use the plug from the XO-1's charger, I guess that it did not change in the meantime.) Thanks, Andrew ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Activity Central's Sugar related priorities.
Hi! Took some time but finally set up my git account... 2 Journal This is probably the issue we have been most aware of. I've been thinking in the per activity datastore direction too and I think it's probably the best one. Though as you say that involves UI redesign and we would need to figure out compatibility with existing activities. (Please share the webkit code, I don't know if I'll have time to hack on it but I did think to write something like that at some point, it would be interesting to look at it if nothing else). I have put the ?latest? sources here: https://github.com/NoiseEHC/sugar-webkit-native It requires a yum install webkitgtk3-devel to be able to compile, unfortunately my XO-1.75 says that there are no more mirrors to try for mesa and libdrm dependencies so I could not try it under an ARM XO... (I did try it some time ago however it just stopped working.) You may also need to create a test2/bin directory as git does not include it... The code is full of static char buffers which should be fixed and it also crashes on an XO when you compile with webkit2gtk... We probably all agree that it would be awesome to have something that integrates well with Sugar and works transparently by reusing existing web technologies. I don't think that's easy to achieve though. It has been said in previous discussions that without the close integration between activities and system, Sugar would be just yet another suite of educational applications (and likely not the best of them). I very much agree and I think it's tricky to preserve that while moving to frameworks which are supposed to work everywhere. We could have started with something more web developer friendly and incrementally integrated it into the native Sugar platform, for example by redesigning the Journal in the way you described, and somehow adapting native activities to the new design. Instead we went for something targeted at the current Sugar developers with the idea of making it incrementally more web friendly. I have been on the fence on what was the best approach and I still am. Something to consider is that we barely have the resources to maintain the existing native code. I doubt, for example, that we would be able to ship a redesigned Journal. Consider also that the people most involved with this work has all a good knowledge of the Sugar platform but are not really web developers. I fail to see why would it be bad if Sugar would be just yet another suite of educational applications. Currently the close integration between activities and system consist only of 3 DBUS methods, 4 X properties, the Journal as a filesystem and the presence service (which is desugarized if I remember correctly, you have to use Telepathy directly?). In my opinion the single most important thing would be to allow developing sugar applications directly in the PC browser (like firefox or chrome). If that would work then you could just go to a web conference and after giving a presentation about sugar-web you could ask the attended crowd to help you in the workshop by converting just ONE/person python activity into a web one and you are done with the conversion in a day... Obviously it would not make converting Write/TurtleArt/Etoys/Scratch easy but at least the rest would be done. Now, if you go standard web, then you do not need the X properties, view-source is built into the browser (DBUS HandleViewSource) and DBUS SetActive can be done with webkitvisibilitychange event and timers. The only remaining thing would be handling the DBUS Invite. Collaboration would most likely need an OT library which should have a C implementation on the XO to have usable speed. The Journal simply can be implemented by the host application by providing either some standard file API implementation (like light-swift) or just providing a virtual page with links and POST. https://github.com/bancek/light-swift So if you already run a node.js server then probably it could host the activity's html files and could provide some virtual file GET/POST service in http://localhost/journal/directory.json - this is for file list http://localhost/journal/guidcomeshere - this is for GET/POST files My plan was to support http://localhost directly from sugar-webkit-native (instead using file:// to be able to OAuth) and query/update the journal from there too but it is simpler from node.js if you are running it anyways. You can also assume that web developers have node.js running on their dev machine or already know how to install it. If you forget for a while to have collaboration from web apps then the rest can be done in no time IMHO. So that was my $0.02. Obviously it can be too late to change plans but who knows. I have uploaded the source anyway so you can use it if you want. Regards, Andrew ___ Devel mailing list Devel@lists.laptop.org http
Re: [Sugar-devel] Activity Central's Sugar related priorities.
I have put the ?latest? sources here: https://github.com/NoiseEHC/sugar-webkit-native It requires a yum install webkitgtk3-devel to be able to compile, unfortunately my XO-1.75 says that there are no more mirrors to try for mesa and libdrm dependencies so I could not try it under an ARM XO... (I did try it some time ago however it just stopped working.) You may also need to create a test2/bin directory as git does not include it... The code is full of static char buffers which should be fixed and it also crashes on an XO when you compile with webkit2gtk... Ehem, the source should be in a directory called test2 so it matches the name in the .info file... That is why it requires a test/bin subdir... ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Activity Central's Sugar related priorities.
On 22/10/2013 21:21, Gonzalo Odiard wrote: So that was my $0.02. Obviously it can be too late to change plans but who knows. I have uploaded the source anyway so you can use it if you want. What I really don't understand is, if is all that easy why not be involved and help? The development of the web activities stuff was done in the open, mostly by two developers, manuq dnarvaez. Then everyone who wanted help, could do it. Say now how should be done, is useless at least. Talk is easy... as always, the devil is in the details. But you already know that, if not would not talk about unconstructive criticism Gonzalo You are right. The problem is that my views are exactly the opposite of the decided path to take. I do not help developing because I totally oppose the current path, meaning that I do not believe that it can work. All the easy talk can be useful later *if* they decide to change paths. Or it will just remain an interesting viewpoint, but at least I tried. So while you are right about the Talk is easy part as well, I could only help developing by finishing the native webkit app (because I believe in it), which would be totally wasted (parallel) effort. Actually that was the plan but then I run out of time and realized that the official project went a different direction anyway. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Activity Central's Sugar related priorities.
On 07/10/2013 18:41, David Farning wrote: Activity Central supports the recent HTML5 + JS work that is going into sugar .100. It has the potential to take the OLPC vision to any device which runs a browser while simultaneously *increasing* the potential activity *developer* *pool* by several orders of magnitude. This is an excellent area for community lead research. Activity Central will be doing activity side work to test the viability of the framework for client deployments. No, it won't... It already happened when Bryan Berry moved OLPC Nepal's lessons from EToys to Flash, then to HTML5 and there were not any more contributors. I mean, there are much more JS developers, so if you pay them you can get cheaper talent, but there will be not too much more contributors IMHO. The problem is that the current HTML5 work goes into a direction which I am not sure that needed by anyone other than existing Sugar developers. It all boils down to this simple question: If you are a potential contributor wanting to develop some educational activity (not a framework but some concrete lesson or stuff usable in a lesson!!!) then which one would you use? 1. A HTML5 + JavaScript activity model called Sugar Web Activity, which reaches 2-3 million children? (lets call it SWA) 2. A HTML5 + JavaScript activity model called HTML5 + JavaScript, which reaches 1 billion children? (lets call it WEB) I have not seen any compelling reason why would a potential contributor (software developer from a developed country who has/likes children) choose option 1 instead of 2... Now I will not give you constructive criticism as that would allow answering that I should not tell others what to do and it would be getting old... Instead here is some nonconstructive criticism: Some months ago I wanted to create a sample activity to present my point but I have run out of time so unfortunately I cannot show it to you. It would have been a Google Drive backed game with shared state (so the same as a typical shared activity in Sugar) called Scrabble what I try to port to SWA. It uses the following things which are trivial to use on the WEB but cannot be found in SWA: 1. Sign in. There is no authorization API in SWA so using anything than the local journal is problematic. Using Google's OAuth authentication from a file:// protocol is impossible so if you want to support existing code then you have to serve the activity from http://localhost... https://developers.google.com/drive/about-auth 2. Datastore. There is no way to access the Google Drive if you cannot authenticate. I do not see why would anyone use a new JavaScript lib which accesses only the journal when they are already familiar with some WEB technology. Like WEBDAV or the OpenStack's SWIFT API. http://docs.openstack.org/api/openstack-object-storage/1.0/content/storage-object-services.html Or simply using POST for uploading: https://developers.google.com/drive/manage-uploads 3. Collaboration. Using the Google Drive Realtime API is dead simple. It is the most missing feature from SWA BTW. https://developers.google.com/drive/realtime/ I have looked at several open source Operational Transformations libraries but did not have time to test their performance on an XO... 4. Using WebSockets for simple tasks. The autosaving can be implemented by the almost standard webkitvisibilitychange event (but you have to compile webkit with the appropriate parameters) and standard timers. Activity startup is simplified with per activity data store (POST-ing to the same server is the default on the WEB). I think it eliminates the communication with Sugar so no need for WebSockets... 5. Android port. There already exists a multi-platform technology called PhoneGap. It can target 100-200 million children so it can be called option 3 if you want... It can become obsolete as HTML5 provides more and more of its features though. http://phonegap.com/ So as I see you either create a framework which mimics Sugar and no web developer will use it or create a framework which implements what a web developer is already using or at least tries to somehow emulate it. So the web developer does not have to modify his/her code and will consider porting his/her application for a smaller platform. Of course that would require OLPC/Sugarlabs to run free OpenStack/OAuth/OT servers for contributors otherwise everybody will go with Google APIs which cannot easily be emulated on an XO machine... But as this discussion already happened and I have already written enough now, I just finish here. (In the following link you can replace the phrase Per Activity Data Store with Standard WEB Storage to be relevant...) http://lists.sugarlabs.org/archive/sugar-devel/2010-June/024589.html Thank you for your attention! Andrew ps: Now to say something constructive as well, some more words about the Journal. Recently I was watching one of Walter Bender's talks where he was
x performance problem in webkitgtk
Hi! Now that I am developing a HTML editor application, noticed a performance problem on xo1.75 latest (32011). The symptom is that text selection is very-very slow in the editor. You can test it by opening a long page from wikipedia in epiphany, selecting some text with the mouse then pressing shift+up or shift+down. Looking at 'top -d 0.3 -p pid of x' shows that while the browser is thinking about the selection, the X process consumes all CPU, then the webview is updated. The same does not happen if you just scroll the webview. I have installed firefox and it does not have the same problem either. Could you test it on XO-1 and XO-1.5, please? I think fixing this problem is quite important as it practically makes all text editing web applications unfeasible on the XO... Thanks, Andrew ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: x performance problem in webkitgtk
Just tested with WikipediaEN that it does not happen on 21021 (12.1.0) so it is a regression. On 07/07/2013 18:53, NoiseEHC wrote: Hi! Now that I am developing a HTML editor application, noticed a performance problem on xo1.75 latest (32011). The symptom is that text selection is very-very slow in the editor. You can test it by opening a long page from wikipedia in epiphany, selecting some text with the mouse then pressing shift+up or shift+down. Looking at 'top -d 0.3 -p pid of x' shows that while the browser is thinking about the selection, the X process consumes all CPU, then the webview is updated. The same does not happen if you just scroll the webview. I have installed firefox and it does not have the same problem either. Could you test it on XO-1 and XO-1.5, please? I think fixing this problem is quite important as it practically makes all text editing web applications unfeasible on the XO... Thanks, Andrew ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Need some information about the stark reality in deployments
Hi! Could somebody from OLPC or some big deployments answer these questions please? 1. As I understand, deployments stuck on old builds. What it the most popular version? I guess it is GTK2 based. 2. Is there a plan to deploy newer versions? If so what is the roadmap? I ask this as I want to target my PhoneGap port to target the largest amount of children so it can have some impact. It can include backporting the code to GTK2 if necessary. Thanks, Andrew ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
compiling and running webkit2gtk on xo-1.75/os/candidate/13.2.0-9
Hi! I have written a native webkit gtk application for HTML5 applications (native so it does not require python), and today I tried to compile and execute it on the xo-1.75 laptop. My experiences can help fixing the issue that webkit2gtk crashes on the laptops as sugarlabs people reported it here: http://lists.sugarlabs.org/archive/sugar-devel/2013-May/043188.html So first I have installed xo-1.75/os/candidate/13.2.0-9/32009o2.zd Then I did *sudo yum install gcc make webkitgtk3-devel* This installs gtk3-devel as well and updates a lot of packages. After this the laptop became unusable, could not start Browse, and trying to switch to the Gnome desktop made the laptop stuck in start. The second time I did a reinstall and did yum from the Gnome desktop but my program could not be compiled because of *undefined reference to _glapi_tls_dispatch in libgl.so* So I had to make a *sudo yum update* which updated a lot of packages and my program finally started. If I compile with webkitgtk1 then it runs, with webkitgtk2 it crashes. The crash (SIGSEGV) happens in *glXCreateContext in /lib/ligBL.so**.1** * As I do not really understand all those package things, it seems to me that the compiled webkit2 references OpenGL libraries while webkit1 does not. Could we just switch it off somehow while compiling the XO image? Thanks, Andrew ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: compiling and running webkit2gtk on xo-1.75/os/candidate/13.2.0-9
On 27/06/2013 16:20, Daniel Drake wrote: On Thu, Jun 27, 2013 at 8:08 AM, NoiseEHC noise...@gmail.com wrote: which updated a lot of packages and my program finally started. If I compile with webkitgtk1 then it runs, with webkitgtk2 it crashes. The crash (SIGSEGV) happens in glXCreateContext in /lib/ligBL.so.1 As I do not really understand all those package things, it seems to me that the compiled webkit2 references OpenGL libraries while webkit1 does not. Could we just switch it off somehow while compiling the XO image? We pull in webkit packages from Fedora, we don't compile them for XO. So fixing this bug will require a proper investigation into the crash you have found. Daniel Now I looked at the source of webkit2gtk and it seems that opengl support is compiled into the library or not, so if OPENGL is specified then it will call into libGL.so and will crash. Maybe we should not lie about 3d support? What is the status of OpenGL support on the xo-1.75 and xo-4? I have read the email about writing an open source driver for the xo-4 but does it imply that there is no official binary driver from Marvell? (I know that XO-1 and xo-1.5 will not support 3d.) So I will stick to webkit1... On the other hand, going native is clearly the way to go, as it launches in 2-5 sec (usually ~3), while Browse launches in 13 sec on my xo-1.75... ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: compiling and running webkit2gtk on xo-1.75/os/candidate/13.2.0-9
So I will stick to webkit1... On the other hand, going native is clearly the way to go, as it launches in 2-5 sec (usually ~3), while Browse launches in 13 sec on my xo-1.75... Just curious, what do you mean by going native? I am porting PhoneGap to the XO. It is very similar to the sugarlabs GSoC web-activity project, but unlike that mine does not use python so probably it will make sense using it on the XO... On the other hand the code will be open source so they will be able to use it but I will not hold my breath. BTW, why 3d is not supported on the XO? Does not Marvel have a GLES driver for the xo-1.75 and xo-4? Or are those SoCs only supported on windows? ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-3 Announcement?
Secondly, and probably more importantly, neither of the aforementioned assumptions are really true with Android. I've yet to hear the argument that pupils absolutely need to use Android (or iOS for that matter) based devices today because that's what they gotta know tomorrow. Plus there frankly speaking aren't too many apps focused on education (regardless of for learning or administration) available for Android today (https://market.android.com/apps/EDUCATION?feature=category-nav). I had a tough time finding German ones when I recently tested the Samsung Galaxy Tab 10.1 and the number of Spanish ones seems relatively small as well (and don't even get me started on Quechua, Aymara, Dari or Amharic). In combination with the absence of many years of Microsoft lobbying this gives Android vs. Sugar a much smaller pull factor than in the previous Windows vs. Sugar situation. You know, I have heard this there are no educational apps for Android thing so many times that I think that I should clear the situation a little. Even when Charbax interviewed some OLPC employee about the XO-1.75 he said those exact words. Now the dire situation is that there are almost no educational apps for any platform at all. What is needed are those hundreds of little apps for *every* lesson which can be used in a class. We do not have any (except the Nepali stuff which was converted from e-toys to HTML5). Now what Bryan Berry could tell you is that no matter how good a platform is if there are no developers to hire. Another common question is this what are the technical advantages of switching to Android thing, even Walter Bender asked exactly this in this list. It is also totally irrelevant because there are not any. I mean in everything provided by both Sugar and Android, the Android version is better or faster, but it just does not justify the switch. The real question is not where are the applications but rather who will write those applications which does not exists? How many Sugar developers are there? Probably several hundreds? How many Android developers? Millions? HTML? Tens of millions? So instead you should justify that developing a marginal platform which will have no developers to hire is so much better than Android or HTML5 that it is worth all the time spent on it. Clearly nobody justified it and frankly I cannot see it either. Note that I do not want tell you what to do. Now I do not even want to tell you what not to do. I am just trying to show you a viewpoint nobody seems to consider. Because in the end you will have to hire developers to write those hundreds of little apps since no contributor will spend time on those booring problems. Contributors like writing platforms so that others can write those boring apps. Just my $0.02 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Android on XO-1.75
I am doing it. It got stuck since when I have received the machine github was down for a long time (was hacked or something). After that I decided to wait for Android 4.0 and just yesterday was I able to download all the source. Since I have already did a half-finished XO-1 port I can tell you that you can expect a first boot in a month... On 2011.11.23. 21:57, Rafael Ortiz wrote: Hi Devs I'm just wondering what's the actual state of Android on the XO-1.75?. Are there any docs or info about how to install it ?. Are there any plans for it on the near future?. Thanks and cheers. ___ 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: XO-1.75 B1 units - this is how they look
Do you have any prototypes with touchscreens? Or have you dropped the idea? On 2011.07.29. 21:18, Martin Langhoff wrote: CL2 and CL2A, B1-stage engineering prototypes, just arrived in Miami and Boston http://dev.laptop.org/~martin/xo1.75-b1-look/ If you want one, you know what to do... :-) http://blog.laptop.org/2011/07/25/new-xo-1-75-contributors-program-test-our-new-prototypes/ cheers, m ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-1 touchpad once more [Devel Digest, Vol 64, Issue 28]
The newer builds are close to unusable. That is one of the reason I do not use them. (The other is that the gamepad does not work and it kills the XO-1 as an ebook reader...) On 2011.06.15. 14:09, Martin Langhoff wrote: On Wed, Jun 15, 2011 at 2:28 AM, Yioryos Asprobounitis mavrot...@yahoo.com wrote: However, I do not think that is not a big issue if newer builds indeed make it worse. If you think newer builds make it worse, and can help us keeping track of it in detail, yes, we need and want your help. But your testing of a different OS means you have a different stack from what we ship. Can you test with a recent 11.2.0 dev image? Maybe running it from an SD card to preserve your internally-installed OS... cheers, m ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: OPENPAD tablet designed for children
I do not see why is it so specially designed for children. On the other hand I would buy instantly an unbreakable Android tablet with a dual mode screen (Pixel Qi like) which is water-proof (not only spill-proof) so it could be washed under the tap. I would not even miss the USB and SD slots if it would be completely sealed so the only IO would be through bluetooth (assuming wireless charging)... On 2011.06.01. 22:37, Frederick Grose wrote: See http://www.sbwire.com/press-releases/sbwire-94821.htm ___ 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: [IAEP] Turtles All The Way Down
No. OOP is overhyped anyway... It only helps for namespacing, and
primitive values where encapsulation works. Since children will not make
reusable libraries mostly I think there is no point making things more
complex as they already are. BTW I did not find the second version more
readable but it can be only me.
On 2011.05.24. 19:11, C. Scott Ananian wrote:
On Fri, May 20, 2011 at 11:09 AM, Alan Kayalan.n...@yahoo.com wrote:
Smalltalk actually got started by thinking about a way to make a child's
Logo-like language with objects and pattern matching that could express its
own operating system and environment.
It is very tricky to retain/maintain readability (so the first Smalltalk was
also an extensible language not just semantically but syntactically).
With a tile language, this is really worth thinking about, since using tiles
suggests ways to extend both the form and the meaning of the tiles.
I've written a follow-up post, musing on the readability aspect Alan
mentioned above:
http://cananian.livejournal.com/64330.html
Is it worth trading a very simple and direct syntax like:
var Point = {};
Point.x = 0;
Point.y = 0;
var Point3D = Object.create(Point);
Point3D.z = 0;
for the more readable:
Class(Point, {
has: {
x: {is: ro},
y: {is: rw},
},
})
Class(Point.ThreeD, {
isa: Point,
has: {
z: {}
},
})
at the cost of introducing additional complexity into the object
creation process. The complexity is in a library, so the base
language is kept small -- but it's still more turtles thrown onto the
stack that you have to understand.
Returning to Alan's point about tiles -- the nice thing is that you
could define a custom tile for the Class() syntax above, with
pretty selectors to help you select parent class, slot attributes,
etc. But perhaps it's better just to keep the conceptual model small
-- then you don't need fancy GUI widgets to help you out.
For a more concrete example, you might want to read through:
https://github.com/cscott/TurtleScript/blob/beeba5c138d88af40297f93689ecbe7721724819/crender.js#L333
starting at line 333 or so. That's a widget library written in
Simplified JavaScript/TurtleScript which uses prototype inheritance
extensively. You can do clever things like swipe the implementation
of a function from a totally different class; see how we do multiple
inheritance around line 661. Is the Joose syntax an improvement?
--scott
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: Turtles All The Way Down
Okay, it seems that I made the wrong questions (as always) and while got perfectly good answers, I did not get the knowledge I wanted to have... So it seems that I am looking this from the perspective of software development and you see it as research. While I can totally accept that research is interesting and cool, I would like to define a working usable closed subset of the problems you want to research, to have a finished product which can be put into the hands of children _now_. So the real question is what the goal is? I thought that it is part of the googleization effort and so it would become a Browser based MegaTurtleArt or something like that. But now it seems that it is some research into self contained systems or whatnot. My thinking is this: A browser based editor written in SimpleJS which can graphically edit a subset of SimpleJS programs (the subset which can produced by the editor). Editing the editor code can be done differently than editing the loaded programs (or not at all). If the user learned the generated SimpleJS then she can edit the source of the editor with a text editor and save as a new activity (btw she can look the source of the editor graphically if she wants). Objects can be edited through a name/value editor which saves the object to the object literal in the loaded SimpleJS source. The editor does not save state, it just runs the loaded program after loading just like TurtleArt does. It should have a TurtleArt and Scratch importer as well. Now my proposal has the advantage that it does not need a runtime, the source *is* SimpleJS. Since the editor cannot be modified with itself, it cannot be destroyed, no undo needed. The generated SimpleJS (or the AST in the blocks) can be undo-d. Since it does not want to save state, the generated SimpleJS must not be obfuscated with passed in context (and neither your editor source is obfuscated). Because only the source is saved, it must not use the macro system but it has to simply parse different AST into blocks by some pattern matching (and this is similar to flattening + or ). This pattern matching must be built into the editor source and cannot be extended, the user can only extend via functions (like JS programming, wow :). So it is just a matter of finishing the editor and adding a turtle. Note that it seems that I am looking at this program as to a user interaction problem because I find it hard to design a TurtleArt with touch interface and so it is an interesting problem for me. You seem to find more interesting the turtle column thing. I really do not want to tell you what (not) to do but the question is whether this turtling down have so much pedagogical value to worth the added complexity? So the real question is what the goal is? On 2011.05.20. 20:02, C. Scott Ananian wrote: 2011/5/20 NoiseEHCnoise...@freemail.hu: 1. Why do the bytecode stuff? JS seems to be a perfectly good code representation to me and it can be run much faster compared to a naive bytecode interpreter or compiler written without the resources of the Chrome/V8 team. It's true. As described in my blog post, the VM work was an experiment to see how far down the turtles could go. As the Klein VM and other examples have shown -- pretty far down! Even if you end up running the language in the fast V8 VM, you might want to have a version with somewhat lower performance which is 99.9% view source-able. But I really should be concentrating on the higher-level stuff at the moment. 2. Why do you want to serialize the stuff? Is not it enough to serialize just the JS code + screenshot and on load run it? It relates to the desire to be able to do prototype-style development, where you modify existing objects to create new functionality. (Think etoys.) Once you've got a bunch of user-modified objects floating around, you have to start thinking about how to save/load them. 3. Why is the pervasive undo necessary? Only for debugging? That relates to the goals of Sugar, leaking through into TurtleScript. It's actually pretty easy to screw up your VM pretty badly if you can actually access it down all the way to the bottommost turtle. Once you've done this, it would be nice to be able to recover gracefully -- or at least, more gracefully than toss the saved image and restart. Supporting cheap snapshots of the system image is one way to do this. BTW cool project, that is exactly what I wanted to do, now I do not have to... :) Oh no! That's the opposite of my intended goal in talking about this stuff -- at some point I badly need other people to adopt the ideas and carry on with the implementation, as I'm unfortunately still a single-core human. --scott ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Turtles All The Way Down
How does it compare to this? http://waterbearlang.com/ On 2011.05.20. 15:30, C. Scott Ananian wrote: I've done a little more work on Turtles All The Way Down, which I (very briefly) discussed at EduJam. I actually wrote a garbage collector in TurtleScript for TurtleScript on Sunday. Brief writeup here: http://cananian.livejournal.com/64140.html and exhaustive mind-numbing detail here: http://cscott.net/Projects/TurtleScript/ No actual turtles yet! I'm going to have to fix that soon. --scott ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Turtles All The Way Down
Okay, I finally read through all the text and run the samples. What is not clear to me: 1. Why do the bytecode stuff? JS seems to be a perfectly good code representation to me and it can be run much faster compared to a naive bytecode interpreter or compiler written without the resources of the Chrome/V8 team. 2. Why do you want to serialize the stuff? Is not it enough to serialize just the JS code + screenshot and on load run it? 3. Why is the pervasive undo necessary? Only for debugging? BTW cool project, that is exactly what I wanted to do, now I do not have to... :) On 2011.05.20. 15:30, C. Scott Ananian wrote: I've done a little more work on Turtles All The Way Down, which I (very briefly) discussed at EduJam. I actually wrote a garbage collector in TurtleScript for TurtleScript on Sunday. Brief writeup here: http://cananian.livejournal.com/64140.html and exhaustive mind-numbing detail here: http://cscott.net/Projects/TurtleScript/ No actual turtles yet! I'm going to have to fix that soon. --scott ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: The next four weeks
Cool! What I do not get is this: what is the goal? Having an environment running on Android which can run the same XO bundles which are run by XO-1.x? If the Sugar API has to be changed (adapted for some technical reason) would you fork all activities? Thanks, NoiseEHC On 2011.04.12. 19:56, C. Scott Ananian wrote: On Mon, Apr 4, 2011 at 6:09 PM, C. Scott Ananiancsc...@laptop.org wrote: I've posted a four week plan for XO-3 software exploration at http://cananian.livejournal.com/62667.html Briefly: April 4-8: Android The report on the first week of work is now up at: http://cananian.livejournal.com/62756.html Basically -- yes, I can see how Sugar-on-Android can be done. No major blockers, but the build chain and packaging issues will be an initial annoyance. --scott ___ 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: The next four weeks
Hi Scott! The IAEP thread if I am not mistaken is this: http://lists.sugarlabs.org/archive/iaep/2011-February/012522.html When last time I proposed similar things on the mailing list all I have got were: 1. Do not tell others what to do! 2. CADT 3. I want others to drop all sugar code now! 4. People unsubscribed from the list because of me. (At least it was a good excuse I guess...) So congratulations, you have *way* better communication skills that I will ever have, your thread was fascinating to read. In the meantime I personally changed my preferences regarding this Sugar rewrite on Android, and now I see how stupid was I. The problem is that there is no need to rewrite stuff on Android when there is a much more easier, cross-platform thing exists and it is HTML5!!! (I have even tested chrome's speed on an XO-1 and it is totally acceptable.) When I skimmed over the activities in the Sugar Activity Store :) I realized that there are not too many of them. Most of the activities fall into the following 3 categories: 1. Small activities which can be easily rewritten. 2. Big activities which are ported to Sugar (etoys, scratch, write). 3. GCompris. A lot of them. 4. It can be that Uruguay and Peru created a lot of stuff I do not know about and I am stupid. So I clearly cannot see the need for invisible perfect compatibility because 2-3 are already ports so they must be ported anyway, and 1. does not contain that much activities to warrant such amount of work in my opinion. But you know, I will not tell you what (not) to do... ;) What you do not seem to take into consideration are these: 1. Activities should move to a per activity storage model (like Android does) otherwise your compatibility layer will not work too well. 2. The Sugar HIG will result in pathetic touch controlled applications, even if the problems can be fixed by the excellent suggestions of Gary C Martin (here: http://lists.sugarlabs.org/archive/iaep/2011-February/012556.html). Okay, actually I think that you totally understand 2. so I just do not get what your point with invisible compatibility is... Good luck anyway, NoiseEHC BTW, in the next 4 weeks I will rewrite Sugar to HTML5... :) On 2011.04.05. 0:09, C. Scott Ananian wrote: I've posted a four week plan for XO-3 software exploration at http://cananian.livejournal.com/62667.html Briefly: April 4-8: Android April 11-15: Chrome/ChromeOS/NativeClient April 18-22: Get down dirty with mesh April 25-29: Yanking legacy Sugar codebase into the future May 2-6: in Uruguay to present results and discuss all this w/ Sugar folks in person I'll be posting more about each project as I dig into them; there are also threads on IAEP where I've discussed all these topics before, so they shouldn't come as too much of a surprise. There are other ideas out there, and I'm not going to *finish* any of these investigations in a single week. Feel free to ask questions and suggest other projects -- although please read the existing discussions first if you can. In order to actually get work done w/o endless distraction, I'll probably try to avoid getting into lots of details for projects other than the one I'm currently focusing on. --scott ___ 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: The next four weeks
The Journal and Portfolio are really important part of Walter's vision of Sugar. They will be system services, with strong enough modularization to allow multiple competing implementations. I know how that will work in web/nativeclient model. I'm not certain how that works on Android yet; hopefully by the end of this week I'll have some better ideas. It has already happened: http://lists.sugarlabs.org/archive/sugar-devel/2010-June/024589.html Now what I do not get is why everybody insist on having a central data store like it would be the only option to implement Journal? My solution would be just having per activity data store, activity launcher just launches the activity which shows the available data objects in an activity specific way. The activity launcher can then store the launched activity in a journal or the activity can update the journal on save as... or new... but those would be just links. Also the journal could do full text search if the activity implements the supporting text crawler. Now with HTML5 the journal would be links, on Android see the linked message for information. So why is the current central data store better that this proposal? Why does everybody chase a general versioned data store implementation (which is impossible to create in my humble opinion)? What is a Portfolio? ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: The next four weeks
What is a Portfolio? http://www.gse.harvard.edu/news/features/mi08012002.html -walter Thanks! So it seems that the portfolio is the (maybe child selected) subset of the Journal. Am I right? How is it addressed in the current Sugar implementation? If it is not then is there a specification of it somewhere? What my real question is how is it different from a children owned web page, or a publish at facebook button? ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: NOW: OLPC Contributors Program Mtg (#olpc-meeting, 3PM EDT, Apr 1)
Are there any news whether the touch screen enabled 1.75 XO prototype will be available to the contributors program? If yes when can we expect them to be available? ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-1.75 progress
OLPC Engineering had a trip to Taipei for the XO-1.75 motherboard bringup last week. The 1.75 machine lives in the same industrial design (display, case, batteries) as the XO-1/XO-1.5, but uses an ARM system-on-chip from Marvell -- the Armada 610/MMP2. Now that is good news. Two questions: 1. Here (under Tech Specs) http://bit.ly/bdr0Cz it specs the 10 tablet with an ARMADA 168. Why did not you go with that processor? Would not that be cheaper? 2. What happened to the bigger display and the touch panel plan? As I see on the pictures the machines have the old 7.5 display. Thanks! ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-1.75 progress
Okay, I will rephrase my questions maybe I will get a real answer to them: 1. Is there any reason why do you use the latest and greatest Marvell SoC instead of an old (and maybe cheaper) one? Like the tablets on the Marvell product platform page do? 2. There were plans for touch screen and bigger display for the XO 1.75. What happened to those plans? Do you use the XO-1 case because there is what you have now, or because those plans were scrapped? Thanks! On 2010.11.11. 12:49, Ed McNierney wrote: Two questions: 1. Here (under Tech Specs) http://bit.ly/bdr0Cz it specs the 10 tablet with an ARMADA 168. Why did not you go with that processor? Would not that be cheaper? That's a Marvell product platform page, not OLPC's. 2. What happened to the bigger display and the touch panel plan? As I see on the pictures the machines have the old 7.5 display. Again, those are Marvell pictures, not OLPC's, and Marvell has lots of other folks interested in building their tablets. In fact, the world is full of 7 16:9 tablet folks. But the most pertinent answer is that we're talking about XO-1.75 right now, which is a laptop. An OLPC-3 tablet is a long way away and it's not really useful to discuss/speculate on it now. We're working on XO-1.75. - Ed Thanks! ___ 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: Announcing the OLPC OS 10.1.2 final release!
Hi! I just had a little time to try 852 on the XO-1 and there were some bugs I have found. I am not sure whether anybody will fix them ever but here they are nevertheless: 1. When the screen is rotated 180 degrees the PgUp and PgDn game keys are not rotated. 2. The control panel does not remember the unchecked state of the Radio On checkbox. 3. There is something terribly wrong with suspend (most likely the EC code). Sometimes it just switches off the closed laptop. After I boot it there is plenty of power in the battery so it is not a low power situation. It happens regularly that after the XO-1 wakes up to reduce the back light brightness it cannot go to sleep again. I think that it is the EC code because the blinking power led sometimes has an erratic rhythm (with a closed laptop). 4. The geode driver still has the mode select bug described here: http://lists.laptop.org/pipermail/devel/2010-September/029875.html Not sure whether there was a point reporting this list though. Thanks, NoiseEHC On 2010.08.31. 3:00, Chris Ball wrote: Hi, I'm very pleased to announce build os852 as the final 10.1.2 release build for XO-1 and XO-1.5 laptops. Here are its release notes: http://wiki.laptop.org/go/Release_notes/10.1.2 Instructions for installing the release on an XO can be found at: http://wiki.laptop.org/go/Release_notes/10.1.2#Installation Many thanks to everyone -- testers, translators, documenters, developers and others -- who contributed to this release! As I mentioned when announcing that this release would happen, being able to release 10.1.2 for both XO-1 and XO-1.5 at the same time was enabled by a group of volunteers who created XO-1 Fedora 11 builds: our particular thanks to Daniel Drake, Bernie Innocenti and Steven M. Parrish for their work towards this release. - Chris. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Announcing the OLPC OS 10.1.2 final release!
5. Missed that the camera led blinks when the laptop is in a suspended state so probably something wakes up the laptop. But why does it touches the camera is beyond my understanding. On 2010.09.21. 16:02, NoiseEHC wrote: Hi! I just had a little time to try 852 on the XO-1 and there were some bugs I have found. I am not sure whether anybody will fix them ever but here they are nevertheless: 1. When the screen is rotated 180 degrees the PgUp and PgDn game keys are not rotated. 2. The control panel does not remember the unchecked state of the Radio On checkbox. 3. There is something terribly wrong with suspend (most likely the EC code). Sometimes it just switches off the closed laptop. After I boot it there is plenty of power in the battery so it is not a low power situation. It happens regularly that after the XO-1 wakes up to reduce the back light brightness it cannot go to sleep again. I think that it is the EC code because the blinking power led sometimes has an erratic rhythm (with a closed laptop). 4. The geode driver still has the mode select bug described here: http://lists.laptop.org/pipermail/devel/2010-September/029875.html Not sure whether there was a point reporting this list though. Thanks, NoiseEHC On 2010.08.31. 3:00, Chris Ball wrote: Hi, I'm very pleased to announce build os852 as the final 10.1.2 release build for XO-1 and XO-1.5 laptops. Here are its release notes: http://wiki.laptop.org/go/Release_notes/10.1.2 Instructions for installing the release on an XO can be found at: http://wiki.laptop.org/go/Release_notes/10.1.2#Installation Many thanks to everyone -- testers, translators, documenters, developers and others -- who contributed to this release! As I mentioned when announcing that this release would happen, being able to release 10.1.2 for both XO-1 and XO-1.5 at the same time was enabled by a group of volunteers who created XO-1 Fedora 11 builds: our particular thanks to Daniel Drake, Bernie Innocenti and Steven M. Parrish for their work towards this release. - Chris. ___ 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: Announcing the OLPC OS 10.1.2 final release!
It is more problematic than that. 1. When the Radio is checked (on) after boot I see the 3 mesh networks and the XO-1 can see other access points. 2. When the Radio is unchecked (off) then I see neither mesh networks nor other access points. 3. Setting on-off seems to work and the checkbox shows the correct setting. 4. However if I make it unchecked (off) and restart then after booting I can see 3 mesh networks but no other access points. Closing and reopening the laptop scans no access points (I do this because there is a lack of 'rescan' button anywhere). If I manually switch the radio off then on it starts to work. So it seems that the disabled setting only disables the radio halfway on boot and the control panel sees it as a working radio... On 2010.09.21. 21:24, Hal Murray wrote: noise...@freemail.hu said: 2. The control panel does not remember the unchecked state of the Radio On checkbox. Is the problem that it doesn't remember or that it gets things backwards? I remember getting confused in that area. To me, the description of the checkbox seemed backwards from what it was doing. (But it did something and remembered what it was doing.) http://dev.laptop.org/ticket/10317 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Update for geode driver
Just two questions: When I ported Android to the XO-1, I had to fix a bug in the original geode driver. The problem was that the Linux frame buffer driver uses a memcmp (in fbmem.c, in function fb_set_var) which compares the whole length of the fb_var_screeninfo structure and the last reserved[5] fields are never initialized. So the memcmp mostly fails and the chipset's video mode set routine is called every time. In the case of the geode driver it reinitializes all the registers of the display processor what causes a visible flicker on the screen. Because Android uses the FBIOPUT_VSCREENINFO ioctl to flip surfaces it caused endless flickers what I had to fix. Now the questions are: Was it fixed meanwhile in the Linux kernel (I did this Android hach a year ago)? Are you planning to fix this for the XO-1 since most likely it causes the flickers at suspend? On 2010.08.15. 4:12, Bernie Innocenti wrote: El Fri, 13-08-2010 a las 10:35 +0800, Huang, FrankR escribió: Bernie, You can git clone the lastest code from freedesktop for geode driver to use. The most outstanding rendering bug has been fixed. And some performance patch has been applied. I tested the driver on the XO-1 and couldn't spot any rendering bug neither in Sugar nor in Gnome, with full acceleration enabled and no quirks needed in xorg.conf. However, a long-standing bug is still there: setting Option NoAccel 1 makes the driver segfault during startup. Thank you very much for taking the time to do this neat work, Frank! (pls forward my notes the geode list, I'm not subscribed) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Killing activities when memory gets short
We used to do that, the problem is that we don't control our platform as Google controls Android and you need to make sure that resources that need to be specific of each child process aren't shared (dbus and X connections, etc). I'm personally more interested in reducing the amount of resources we need to start activities (which is quite insane right now), but sharing more of those resources sounds like a good idea to me. Since I spent quite a bit of time analyzing the Python runtime here is my conclusion, maybe it will make wasting all that time less painful. First, most of the memory consumed by an activity is the process heap. While the Python runtime and native libraries are shared among processes, the heap is not. Even if you fork processes it will not work because reference counting will dirty the shared pages and my instinct tells me that just loading a Python source file will reference almost all the shared pages because they are mostly used to store already loaded modules. What I finally did not do is to actually check the hypothesis that most of the heap is filled by strings which are the identifiers in the loaded Python modules. My goal was to somehow make identifiers constants and just readonly-mmap them into the process (replace the pathetic .pyc loading mechanism). Note that my plan was just a little subset of the .jar - .dex converter. Second, Python has a special memory manager which works with buckets so there are separate heaps for different object sizes. Somehow this special memory manager is turned off in release mode and it uses the standard C heap for some reason. Either it is a bug or just it turned out to be faster (more work was put into glibc) I do not know, but handling the linked free list can dirty shared pages as well or I am just mistaken... Third, the fact that Python is a dynamic language does not help any prefetching or memory sharing. I am not too convicted either that this dynamic nature is used at all in the Sugar codebase but you know I cannot program in Python and frankly I do not feel the need to learn another language. Just now, at my age of 34, I finally gave up and learned LISP (more specifically clojure) and I hope that it will be the last programming language I will have to learn (other than assembly languages of course)... :) Now this point is interesting because if you thought that the Dalvik VM could run the Sugar codebase via Jython then it just will not work. The Dalvik VM just cannot load .jar files and Jython just generates them on the fly because of the dynamic nature of Python. Fourth, moving Python (theoretically) to a GC environment (instead of reference counting) also would not work if the GC is compacting because it would also dirty the shared pages. So a mark and sweep nonmoving GC with separately stored visited bits is the only feasible solution. Now guess what the Dalvik VM does? For more info (45 min + questions): http://www.youtube.com/watch?v=ptjedOZEXPM So *my* conclusion is that solving this sharing problem is *very* hard. I am not sure that simply translating all activities from Python to Java would take more time. Another interesting thing is that meantime the unladen-swallow project progresses (just more slowly than planned). Their plan is to make it the default Python runtime so if it will happen (I cannot comment on that) then the Python VM will use even more memory (though it will be faster) so Sugar will be even less interesting on the myriad of low spec cheap ARM tablets which will flood the market soon. I think that is all I can say about this subject so I just finish it here. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Killing activities when memory gets short
Sugar has a similar mechanism. From the Low-level Activity API docs: org.laptop.Activity.SetActive(b: active) Activate or passivate an activity. This is sent when switching activities, there is only one active activity at a time, all others are passive. A passive activity must immediately release resources like sound, camera etc. Also it should prepare for being killed without warning at any time in the future (see OOM) by auto-saving to the datastore. The issue is that it's hard to estimate how many Sugar activities actually do this, because until now they usually have not been killed (*). Might be an interesting test - just randomly kill activities from Terminal and see if they resume correctly ... Maybe good activities could volunteer to be shut down first. Or bad activities would have to beg to live a little longer. Might just take an entry in the activity.info file. It will not work, because the application startup time is horrible on the XO. The Dalvik VM goes a lng way to have fast application startup and to share most of the memory among applications (the Zygote process does this). Actually that was the exact thing I tried to do with the Python VM. Just at the exact time when I started to hack Python I have seen the Google I/O video about the Dalvik VM and thought that duplicating that work would have been a waste of time. So if you wanna fix the Python VM, good luck, but you know it is already been coded... :) Without fast activity startup, killing activities will be a horrible user experience. Maybe not that bad as a totally unresponsive XO though. (*) Apple seems to have foreseen this developer psychology issue and actually killed all apps in the first three iterations of its iOS. So apps had to implement this state saving if the user was to be able to continue after leaving an app. Would be interesting to know how many Android apps actually implement it. All of them. If an Android application does not implement it correctly then there will be big problems while switching apps and while navigating among application screens. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Keep confusion -- round N+1
After making tests [1] in deployments for start new vs. resume we concluded that the way activity starting works on the iPhone would probably work well in Sugar, too [2]. Hehe, this is exactly the thing you would get with per-activity datastores. Guess what, Android does this too. :) Not to mention that an object chooser for pictures could be totally different from an object chooser for ftp sessions for example. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: F11-0.88 os260py
I have just installed it onto my XO-1 (C1 model with the old style touchpad) without anything plugged into it. It seems to work but the suspend/resume is interesting. Sometimes it goes to suspend but after that I cannot wake it up except with the screen rotation button. I press the button and the XO draws a lot of rotated images (10-20) and then it stops. After this I can wake up the laptop when it suspends again by the touchpad or keyboard. What is interesting is that sometimes when it wakes up the screen backlight dims for a fraction of the second. Is it the normal behavior? I mean it seems that the hardware suspended before the backlight could be dimmed. What is the expected behavior? Another strange thing is that when I use Read to read a pdf file and rotate the screen 90 degree then the top of the screen (toolbar) gets black or garbage and when I move the mouse cursor over that area it redraws the toolbar with some garbage. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: F11-0.88 os260py
Yes, I talked about automatic suspend. However the WLAN was not connected to any access points and it seems that Bernie talked about dropped wireless connections in the release notes as far as I know. Paul Fox wrote: noiseehc wrote: I have just installed it onto my XO-1 (C1 model with the old style touchpad) without anything plugged into it. It seems to work but the suspend/resume is interesting. you're referring to automatic suspend, in the presence of wireless? i think bernie understated this bug in the release notes. the wlan driver on the 2.6.31 OLPC kernels is very broken right now. your symptoms don't shock me. (though i've never tried the rotate button when the system has hung.) (if, on the other hand, you have automatic suspend disabled, then perhaps something else is going on.) paul Sometimes it goes to suspend but after that I cannot wake it up except with the screen rotation button. I press the button and the XO draws a lot of rotated images (10-20) and then it stops. After this I can wake up the laptop when it suspends again by the touchpad or keyboard. What is interesting is that sometimes when it wakes up the screen backlight dims for a fraction of the second. Is it the normal behavior? I mean it seems that the hardware suspended before the backlight could be dimmed. What is the expected behavior? Another strange thing is that when I use Read to read a pdf file and rotate the screen 90 degree then the top of the screen (toolbar) gets black or garbage and when I move the mouse cursor over that area it redraws the toolbar with some garbage. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel =- paul fox, p...@laptop.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: OLPC/Marvell Press Release
It was already discussed to death on the mailing lists. (The threads derailed very fast so there was almost no discussion about important things like the feasibility of a future Sugar - Android transition.) http://lists.sugarlabs.org/archive/sugar-devel/2009-June/015369.html http://lists.laptop.org/pipermail/devel/2009-December/027058.html My advice is not to mention Android on these lists because every time somebody talks about Android, God kills a kitten, or something like that... :) James Zaki wrote: On the tablet topic... I'm now wondering what it will take for the potential of Android developers to be harnessed? (Assuming it will be a good thing) Android Emerges as Big Rival to iPad http://online.wsj.com/article/SB10001424052748703630304575270761658543340.html?mod=WSJ_business_whatsNews From the article... Without applications, the device itself means nothing, said Barry Lam, chairman of the contract laptop manufacturer Quanta Computer http://online.wsj.com/public/quotes/main.html?type=djnsymbol=2382.TW Inc., during a recent investor conference. Google's Android operating system, as it did in smartphones, is emerging as the most potent alternative to Apple's technology. The tablet trend is clearly going toward Android, said Jack Kang, director of technical marketing for Marvell Technology Group http://online.wsj.com/public/quotes/main.html?type=djnsymbol=MRVL Ltd. ... Regards, James Zaki 2010/5/27 Ed McNierney e...@laptop.org mailto:e...@laptop.org Folks - Below is the text version of the press release OLPC and Marvell issued this morning, announcing our agreement to work together on the tablet-based efforts we've been calling XO-3.0 and Marvell has been calling Moby (both previously announced). The link takes you to the same document with a few pictures. We're just starting this cooperation, so there are things we don't know yet, but the release pretty well covers what we do know. I think it's important to recognize that our goal with Marvell is to work with them to make a family of tablet products possible, not all of which will be OLPC products. That's something new, and potentially confusing, but we think it can really help us both broaden the community working with us, and help drive our own product costs down by increasing volumes. In some of the press interviews around this release, there's discussion of the goal of introducing something at CES 2011 (in January). That's important to Marvell, but that device will certainly not be an XO-3.0 and probably won't be an OLPC product at all. But it's one of the steps along the way. Remember that this cooperation is intended to help our goals as well as Marvell's goals, so some of the things announced from the partnership won't be things directly pertinent to OLPC's product plans. As we've previously announced, our XO-1.75 product, bringing a Marvell ARM-based motherboard to the current XO-1 laptop platform, is the next product release in our efforts to provide ARM-based, lower-power devices to achieve our mission. - Ed http://www.prnewswire.com/news-releases/one-laptop-per-child-and-marvell-join-forces-to-redefine-tablet-computing-for-students-around-the-world-95007559.html One Laptop per Child and Marvell Join Students Around the World Marvell and OLPC Empower Education Industry to Revolutionize the Classroom Experience through Advanced, Affordably-Priced Tablets CAMBRIDGE, Mass. and SANTA CLARA, Calif., May 27 /PRNewswire-FirstCall/ -- One Laptop per Child (OLPC), a global organization whose mission is to help provide every child in the world access to a modern education, and Marvell, a worldwide leader in integrated silicon solutions, have agreed to jointly develop a family of next-generation OLPC XO tablet computers based on the Marvell? Moby reference design. This new partnership will provide designs and technologies to enable a range of new educational tablets, delivered by OLPC and other education industry leaders, aimed at schools in both the U.S. and developing markets. Marvell is also announcing today it has launched Mobylize, a campaign aimed at improving technology adoption in America's classrooms. The new family of XO tablets will incorporate elements and new capabilities based on feedback from the nearly 2 million children and families around the world who use the current XO laptop. The XO tablet, for example, will require approximately one watt of power to operate (compared to about 5 watts necessary for the current XO laptop). The XO tablet will also feature a multi-lingual soft keyboard with touch feedback, enabling it to serve millions more children who speak virtually any language anywhere in the world. The device is also decidedly constructionist in
Re: New keyboard layouts
Could you just put UP to the place of ?, put ? to the place of RIGHT, and put RIGHT to the place of UP? I am not THAT old to understand what is so cool about that hjkl vi arrangement and I guess no children will either. I feel that moving just one more key from its 101 key standard position cannot suck more that the current arrow key arrangement... Walter Bender wrote: On Wed, Apr 28, 2010 at 12:24 PM, Tiago Marques tiago...@gmail.com wrote: I was just looking at the layout again and just noticed the new arrow keys placement. That is a very awkward placement. Is that definitive or can you do something like shorten the shift key to accommodate the UP arrow? I suppose that would be another hard sell for deployments against netbooks with the regular placement of keys. Best regads, Tiago We debated this one. A shorter shift key would be difficult to type on. We opted to emulate the hjkl vi arrangement. -walter On Wed, Apr 28, 2010 at 5:15 PM, Tiago Marques tiago...@gmail.com wrote: I must ask, what's the default behavior of function keys in the new layout? Fn changes them to F keys, or are they F keys without Fn pressed? Tiago On Wed, Apr 28, 2010 at 2:49 PM, Mikus Grinbergs mi...@bga.com wrote: The following are the keyboard layouts and legends for these new keyboards. Much thanks to Walter Bender for developing these given a bad set of constraints. http://wiki.laptop.org/go/OLPC_English_Non-membrane_Keyboard There may be users who wish to plug in an external keyboard. Such external keyboards often have function keys grouped in sets of four. Such grouping places F5 at the beginning of a row of four keys, and places F6 in the middle of a row of four keys. Suppose users might be pressing the key for 'frame' more often than the key for 'search'. Should the 'frame' function be assigned to the F5 key, since on external keyboards the F5 key might be easier to locate ? mikus ___ 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: New keyboard layouts
But how can it be that not misplacing the ? key (pressed rarery) is more important than misplacing the UP key? I mean that not only it is incompatible with normal keyboards (even laptop keyboards) but with human thinking as well? (Before you ask, I have a LOT of experience with the C-64 keyboard. Both the cursor keys and both the joystick emulation keys suck.) Paul Fox wrote: noiseehc wrote: Could you just put UP to the place of ?, put ? to the place of RIGHT, and put RIGHT to the place of UP? I am not THAT old to understand what is so cool about that hjkl vi arrangement and I guess no children will either. I feel that moving just one more key from its 101 key standard position cannot suck more that the current arrow key arrangement... please don't misunderstand -- the intention of the arrow key arrangement never had the goal of recreating hjkl. if that had been the goal, we could have put the arrows _on_ h, j, k, and l, and used the Fn key to produce them, which is how those vi commands came about in the first place: http://en.wikipedia.org/wiki/File:KB_Terminal_ADM3A.svg obviously, compatibility with a 35 year old terminal is uninteresting. the real goal was to not misplace the ? key. paul Walter Bender wrote: On Wed, Apr 28, 2010 at 12:24 PM, Tiago Marques tiago...@gmail.com wrote: I was just looking at the layout again and just noticed the new arrow keys placement. That is a very awkward placement. Is that definitive or can you do something like shorten the shift key to accommodate the UP arrow? I suppose that would be another hard sell for deployments against netbooks with the regular placement of keys. Best regads, Tiago We debated this one. A shorter shift key would be difficult to type on. We opted to emulate the hjkl vi arrangement. -walter On Wed, Apr 28, 2010 at 5:15 PM, Tiago Marques tiago...@gmail.com wrote: I must ask, what's the default behavior of function keys in the new layout? Fn changes them to F keys, or are they F keys without Fn pressed? Tiago On Wed, Apr 28, 2010 at 2:49 PM, Mikus Grinbergs mi...@bga.com wrote: The following are the keyboard layouts and legends for these new keyboards. Much thanks to Walter Bender for developing these given a bad set of constraints. http://wiki.laptop.org/go/OLPC_English_Non-membrane_Keyboard There may be users who wish to plug in an external keyboard. Such external keyboards often have function keys grouped in sets of four. Such grouping places F5 at the beginning of a row of four keys, and places F6 in the middle of a row of four keys. Suppose users might be pressing the key for 'frame' more often than the key for 'search'. Should the 'frame' function be assigned to the F5 key, since on external keyboards the F5 key might be easier to locate ? mikus ___ 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 part 2 text/plain 129 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Impact of changing default Screen depth on other XO Apps
Since you can only blit pictures on an X server and cannot get a direct pointer to the video memory, I do not know what your problem is. You can just allocate a 32 bit offscreen buffer in the address space of your application and blit it via the X server to the 16 bit video memory (draw). The XO-1 has bit depth converter hardware so it will not be slower in theory. Note that you cannot use the video overlay for this because it has only YUV and RGB-565 modes on the XO-1 and there is a bug in X that the overlay will be garbage after a suspend and it was not fixed last time I checked. (I have told that I would fix it but because I could not figure out how to compile stuff for the XO-1 - like recompiling the kernel and the X server - I did not fix that.) If you need it then I could search for the code I have used but it would take some time... shivaprasad javali wrote: Hi All, We are developing an Activity for the XO. During development we ran into an issue with the default screen depth on the XO. Our application assumes that the screen depth is 32 and does all the draw math. But as the screen depth on the XO is 16 we had to do constant 32 bit- 16 bit conversions which really hit performance. So we put in script to run after installing our activity which changes the default screen depth on the XO from 16 to 32 bit. I wanted to know how much of an issue this would be for other activities running on the XO. Would they be adversely affected by this change? Thanks Shivaprasad ___ 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: Impact of changing default Screen depth on other XO Apps
Now I could not find the code I have used but here is the latest version of the game I started developing for the XO-1. (The development stalled because the xv bug in the Geode driver.) https://docs.google.com/leaf?id=0B6XMYp250cOmZDhmOWNjMTQtMjNlNy00NDc0LTlhMmItNGI3M2NhMGFmNmVmhl=en The trick is that you can develop xo_bubble_town on Windows and you can compile the xo2d directory on the XO (copy the pictures there). I could not find the first version which did not use xv but basically you have to use XShmCreateImage instead of XvShmCreateImage and use XShmPutImage instead of XvShmPutImage in xi2d/XOHardware.cpp. Now if you are already using those then we cannot help you without you posting your code I am afraid... HTH shivaprasad javali wrote: We are allocating a 32 bit buffer and then using the X server calls to blit it to the 16 bit screen. Even this is slowing down the application as the draw in the application is very intensive. We commented out parts of our draw code to find out the part which was slowing it down and found that the blit to the 16 bit screen ( using X server calls) was responsible for a large chunk of the slowdown. When we changed the screen depth the performance of the activity increased dramatically. I was worried if some other activity on the XO making the opposite assumption and optimizing their draw code for a 16 bit screen and then suffering because we changed the default depth. Thanks Shivaprasad 2010/1/27 NoiseEHC noise...@freemail.hu mailto:noise...@freemail.hu Since you can only blit pictures on an X server and cannot get a direct pointer to the video memory, I do not know what your problem is. You can just allocate a 32 bit offscreen buffer in the address space of your application and blit it via the X server to the 16 bit video memory (draw). The XO-1 has bit depth converter hardware so it will not be slower in theory. Note that you cannot use the video overlay for this because it has only YUV and RGB-565 modes on the XO-1 and there is a bug in X that the overlay will be garbage after a suspend and it was not fixed last time I checked. (I have told that I would fix it but because I could not figure out how to compile stuff for the XO-1 - like recompiling the kernel and the X server - I did not fix that.) If you need it then I could search for the code I have used but it would take some time... shivaprasad javali wrote: Hi All, We are developing an Activity for the XO. During development we ran into an issue with the default screen depth on the XO. Our application assumes that the screen depth is 32 and does all the draw math. But as the screen depth on the XO is 16 we had to do constant 32 bit- 16 bit conversions which really hit performance. So we put in script to run after installing our activity which changes the default screen depth on the XO from 16 to 32 bit. I wanted to know how much of an issue this would be for other activities running on the XO. Would they be adversely affected by this change? Thanks Shivaprasad ___ Devel mailing list Devel@lists.laptop.org mailto:Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: OLPC hardware: what if there was an SDR modem / chipset?
i've been doing some research and found a couple of companies with SDR R.F. front-end ICs. one is 40nm and is so tiny that it will only cost about $2, mass-produced. also thanks to being in 40nm, the speed of vs i repeat. all those can be replaced with _one_ i repeat _one_ single solution, costing roughly... $12, if that. Was the first $2 a typo or maybe I do not get something? ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Android, OLPC, and native hosting
Are you aware the XO ships a full Smalltalk IDE? You know, like VisualAge which later became Eclipse? It's hidden in the Etoys activity, but (surprise!) it's a kids laptop. Because someone will break your arms if you port Etoys to Android. Now I understand. The software is designed for learning. *That* is what Sugar was created for, which is not at all what Android was created for, as you claimed when starting this discussion. Another Straw Man argument. What I said was Android OS solves exactly the same *problems* Sugar has been created to solve. You know while you have noticed correctly that Android was created to be a phone OS and Sugar was created to be a learning OS (not too that hard to notice though), they had almost the same *problems* to solve. Because they had different goals they did not solve exactly the same problem set (it was an exaggeration in my sentence) but close (self hosting dev tools and local communication are the main differences). ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Android, OLPC, and native hosting
For the other people talking about IDEs: an usable IDE is not a text editor. Of course. What I do (and most other productive programmers I know do) is use the window manager (gnome, kde, awesome...), xterms, a webbrowser, etc, to make a LIDE: loosely integrated dev environment. I've led various large programming teams -- all the top-quality and top-productivity programmers had long since abandoned Eclipse and similar TIDEs (tightly integrated DE). I've used varios TIDEs over the last 10 years, Eclipse one of them. They have all been inferior to the gnome/emacs/xterms/gitk setup I use now. Yeah, the Real Men Do Not Debug argument... Have you considered the possibility that those top-quality programmers abandoned IDEs because they do not play well with UNIX makefiles and mixed language projects or because they just love emacs macros or because debugging on UNIX sux? How is it applicable for developing a simple Activity is beyond me so please enlighten me. Another (optional) question is why did you left out gdb from the list? All your code is perfect because you are a top-quality programmer who do not make mistakes because of emacs or what? I started on the C64 too, and you'll find others on this list have similar and deeper chops than that. The point stands, however, TIDEs are not needed, and in many many cases not optimal. You may try to call them a valid stepping-stone in the learning, but you will need to bring some solid proof. BTW, when I program for the XO, I do it on an XO, with additional rpms (git, emacs...). My only cheat is that I use an external keyboard. You know I do not argue that IDEs are an absolute necessity to develop code because even I can develop without IDEs, like the endless suffering I had to enjoy while fixing some kernel bugs. What I am saying is that I *do not want* to develop without IDEs. Probably because I am not a member of the Real Men Do Not Debug Club or I am not one of the top-quality and top-productivity programmers, I do not care. What I do care is that because of the lack of IDEs for Sugar development you can only choose from the members of the very exclusive Real Men Do Not Debug Club. Of course if we limit ourselves to the people who can be productive without IDEs then of course IDEs are not a necessity. You really did not had to type so much to show this tautology to me. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Android, OLPC, and native hosting
2009/12/29 NoiseEHC noise...@freemail.hu: me. Another (optional) question is why did you left out gdb from the list? All sorts of things run on the 3/4 xterms i use. valgrind, gdb, python -m pdb, tail -f /path/to/log, ipython, ps_mem.py, psql, git commands... And if all those tools would be integrated into an IDE then it would be bad is not it? Or do you think that it is impossible to do? All your code is perfect because you are a top-quality programmer who do not make mistakes because of emacs or what? You seem to be reading things that I do not write. My code is not perfect. I debug plenty with various mechanisms. There is no problem here. Okay, next time I will write sarcasm/sarcasm tags. like the endless suffering I had to enjoy while fixing some kernel bugs. What I am saying is that I *do not want* to develop without IDEs. Ok, then that is *your personal preference*. Not The End of the World, not the Betrayal Of The Children. See, finally we are on the same page. First, it can be the personal preferences of a lot of people but because you have excluded them you will never know. (And simply *that is my point*!!!). Second, the End of the World, Betrayal Of The Children (I like this wording) argument was yours in that sarcasm Android kills children by not allowing to develop core applications on the XO /sarcasm thread. (BTW it was not yours personally, the *plural you* was intended here.) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Android, OLPC, and native hosting
to do this you would have to declare one specific variation of these tools as the 'One True Way' and eliminate all the others. the advantage of a loosly coupled IDE is that one component can be replaced by something else without having to change/loose all the other things. and the advantage of a loosly coupled IDE is that one component can be replaced by something else without having to change/loose all the other things. Bingo! As soon as git was working, I switched fulltime to it (and dragged my team with me ;-) ). When valgrind is of use, I use it. When one of the weirdo PHP debuggers is needed, I use it. You are wrong. The advantage of LIDE is that you do not have to create those TIDE components (like the one for git what you used for the example). You know writing all those integrated components takes a lot of time and requires GUI designer skills so usually no Open Source Software makes this last step (as the git people did not do it). So your mutual back patting fails because of the following (but it is not that interesting, just here for completeness): 1. Usually IDEs are modularized so there is no 'One True Way' just swappable components. 2. Even if you has to replace something (for example drop CVS for GIT) then you can just continue to use your IDE and only use the command line just for GIT. 3. The simple fact that you have to develop from the command line just shows how *pathetic* *the* *tooling* is in the OSS world, not that how powerful your LIDE is. Now, as I said the above was not that interesting. What is interesting to me is this: 1. I have started the subthread by proposing that *maybe* it would be a good thing to use an operating system which has good tooling. 2. Somehow you managed to turn this thread into a quest against IDEs in general. 3. You use the fact that the tooling is just pathetic in the OSS world to show that it would be a bad thing to use an operating system which has good tooling. Got it. Wait! Can it be that I missed something about this 3. item? Or this IDE thing is maybe the biggest Red Herring in this thread? ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Android, OLPC, and native hosting
Actually, no. The .class - .dex compiler consumes an enormous amount of memory, so it is out of the question at least for now. How much is enormous ? A laptop/tablet is likely to have more than a smartphone... With hundreds of classes in a .jar to convert it uses some 256M, with thousands it uses more than 1GB... (Likely it will be optimized in the future though.) Another problem is that those development tools use such native APIs which are not supported by the Android NDK (Native DevKit). So either those tools (like the java runtime or the make program) should be ported to the NDK (but why waste so much effort on this?) or the development environment should be installed in the system image. The latter one just wastes flash and probably opens up some nice security holes. However what I do not get is why would it be good for an education project if it would be self hosting at all? As I see an education project's main goal is to support creating quality educational resources (like curricula) cheaply, is not it? You can't deny kids the ability to create their own activities (applications, whatever) Pippy is an example of a simple way to introduce kids to activity programming in python, allowing them to easily create and share activities. You can still create applications with http://code.google.com/p/android-scripting/ With the existing tools it is true that children cannot create the same quality applications what is possible with the Android SDK environment (even if we include a ported Etoys, TurtleArt and Karma), but they could create and share applications with the currently existing tools so what is the problem? The problem with self hosted activity development is the nonexistent development environment rather than the limited functionality. Even if the compilers will be ported to the Android NDK, Eclipse will never be ported so programming Android on the XO-3 (or XO-1.7) will be just as painful as programming Sugar with Pippy today. A much more simple solution would be just shipping a full fledged Linux PC to every school and let children log into it with VNC. So the ~3% of children who can become programmers would be able to develop the same applications (with Eclipse) what we can and the rest of the children would just use some simplified environment like scripting... ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Android, OLPC, and native hosting
Ahem. With XO-1.5, I feel that I AM shipping a full-fledged Linux PC to every child. Since when did it take more than a GB of RAM and 4GB of disk to host an IDE ? My point still stands: until Android supports its own development tools, you are turning it's users into second class citizens. Ahem. So you have installed Eclipse under Sugar and somehow developed and debugged a Sugar application what is nice... Wait! You did not! So if we just ignore your Straw Man argument (you know what I have said that you need GBs or RAM to run the dx optimizer tool, not the IDE), the problem is still there that you only can run an usable development environment on a full Linux distro and you cannot even develop Sugar applications with it. For the other people talking about IDEs: an usable IDE is not a text editor. The whole problem stems from the simple fact that you think that an IDE is just a text editor. While it is possible to develop applications even with ed (I used mcedit myself), I would rather poke my eyes out than to try to develop anything with Pippy again. What you do not want to recognize is that you are excluding a lot of developers who do not want to waste their time because of the lack of IDEs. In other words: because of resource constraints you have not made contributing code easy so you have resource constraints now. ps: And please stop this who started developing code in more painful environments race. I myself created several world records on the c64 some 15+ years ago so I know exactly what was the norm at that time. But somehow I do not think that I can waste 10x the required time just because there were not more productive development environments existing then. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-3 super-o-fficial
Actually, I would argue that an operating system that doesn't natively host its development tools is not appropriate for OLPC's target audience. Self hosting is not an absolute requirement. You just have traded an existing, usable developer environment (like Eclipse) for the possibility of children to modify all the code. BTW the children cannot even modify all the code because they cannot compile the Linux kernel or Python itself for example. So you effectively just defined the code modification treeshold a little bit lower than is possible in Android. The price you pay for the resulting scripting language choice is excessive memory consumption, slow execution and painful developer experience. Here is a cost-benefit analysis from an outsider (me): 1. Because all of Etoys, Turtle Art, Scratch and JavaScript/HTML codes are modifiable by children, there is not too much to win by having a modifiable shell. Simply I do not get why would it be so good to let children mess with the Journal or the Shell (Frame) code. For looking into the inner workings of some code there are a lot of other possibilities. 2. What you do not seem to understand (probably because you are all experienced Python/GTK programmers) is that programming in Python/PyGTK is just painful. Especially in Develop. With one eye looking to the code and with the other looking at the documentation of Python, the documentation of PyGTK, the third reads the documentation of GTK (for the missing parts), the fourth looks at the Log Viewer since there is no other debuggers... Contrast this with the simple fact that when I type a dot in Eclipse then magically it shows me all the possible members and methods with parameters and documentation. Now that is what I call discoverability, sorry but Python does not cut it. Since I did not see any documentation shipped on the XO machines I cannot even imagine how will those children understand code without an internet connection... What is sure that I have not seen any activities made by children yet. 3. You could invest an enormous amount of work into making Sugar a less painful development environment (especially on a native host) but what is the point? When you will have a working IDE with a working debugger and a working profiler the world will have already moved farther ahead of you. Just to give you a little perspective: the last time I used Java was more than 10 years ago and I have never used Eclipse. However when I have downloaded Eclipse and the Android SDK I could run, debug and modify my first application in 10 minutes. All this is maintained by paid OHA member employees and you know OLPC Sugarlabs do not have the same resources combined to catch up with that. So from my viewpoint native hosting is not an absolute requirement but just a tradeoff does not worth making. ps: Note that I am not telling you to drop everything and start rewrite Sugar in Java (because it would be kinda stupid) but dismissing a convergence plan with a simple O RLY? seems a little bit short sighted to me. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Android, OLPC, and native hosting
Does Android not host its development tools because it doesn't run the X Window System? Since X already runs on most of the hardware that Android does, that wouldn't be too hard to remedy -- and would benefit the whole Android community. Actually, no. The .class - .dex compiler consumes an enormous amount of memory, so it is out of the question at least for now. However what I do not get is why would it be good for an education project if it would be self hosting at all? As I see an education project's main goal is to support creating quality educational resources (like curricula) cheaply, is not it? ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-3 super-o-fficial
I hadn't looked closely enough to see the detailed licensing. But I'd seen the news stories about Google cease-and-desists to the guys making improved free versions. Is a useful fully-free version readily available, as a practical option? The guy bundled the not free Google applications in the improved Android OS version. The c-a-d was about those applications. Once those were removed it was OK (those apps can be copied over from the unimproved OS though). (This is mostly off-topic for OLPC, unless there's a plan to try Android on XO hardware, which might be amusing. 20,000 apps and an active developer base might be an attraction, versus the hundred or two Sugar apps.) I have already done this but unfortunately I got stuck when I could not make the wireless working neither could I connect my XO to the PC to debug. You know, Android OS solves exactly the same problems Sugar has been created to solve just it is faster, uses less memory, much prettier, has an usable developer environment and has the backing of several hundred millions of dollars and of course several order of magnitude more developers. I have to admit that I do not see any more reasons other than these why OLPC should switch on the long term. (When I mentioned it on the Sugar list of course this idea has not met with much support... :) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-3 super-o-fficial
What: Sugar / Android What is the same: Application complexity: Simple (Activities) / Simple (Activities) Data storage: Ditch filesystem (central Journal) / Ditch filesystem (app specific SQLite storage) UI: Simple (ugly) / Simple (cool) Computer experience of target audience: Low (children) / Even lower (stupid adults included) Application install: .xo bundle / .apk bundle Application isolation: Bitfrost / total app isolation Security: protects users from activities (because they are children) / protects users from applications (because it can cost money to call numbers, and users are ignorant) Programing language: High level (Python) / High level (Java) What Android does not solve: Collaboration: mostly works / Android only collaborates through the web, probably some local Wave server should be included Write: there is / there is only Google Docs Read: there is / everything should be converted to html Open platform: Everything modifiable inplace (just no children do that) / Only scripting on Android Integration with XS: in process / none (that is a BIG problem) What Sugar does not solve: There is no usable development environment, no documentation, few developers. The programming environment is not discoverable by people who are not already pro programmers in Python and Linux. Ugly, slow, eats a ton of memory. Cannot be used by keyboard. Activities cannot work together. See, I did not lost my mind. Merry Christmas! Stanley Sokolow wrote: I'm with Bert. What problems has Android solved that Sugar was created to solve, in your opinion? On Thu, Dec 24, 2009 at 6:04 AM, Bert Freudenberg b...@freudenbergs.de mailto:b...@freudenbergs.de wrote: On 24.12.2009, at 12:59, NoiseEHC wrote: You know, Android OS solves exactly the same problems Sugar has been created to solve O RLY? - Bert - ___ Devel mailing list Devel@lists.laptop.org mailto: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: Booting squashfs from olpc.fth
You probably need to do a dcon-unfreeze as well. \ OLPC boot script unfreeze dcon-unfreeze u:\android\initrd.img to ramdisk u:\android\kernel to boot-device root=/dev/ram0 console=tty0 androidboot.hardware=xo1 to boot-file boot Sebastian Silva wrote: Hello I'm trying to boot into Trisquel like you would boot SOAS. My problem is with making the olpc.fth file currently i'm trying with the following \ Boot script for SD Boot \ created from http://wiki.laptop.org/go/Custom_bootloader ro boot=casper rootdelay=1 splash console=ttyS0,115200 console=tty0 fbcon=font:SUN12x22 to boot-file sd:\boot\vmlinuz to boot-device sd:\boot\initrd.img to ramdisk unfreeze boot But the kernel does not seem to load as it freezes... Let me know what other data I can give to help me debug this. Thanks -- Sebastian Silva Colectivo FuenteLibre http://blog.fuentelibre.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: os33 - video regression ?
To the best of my knowledge Flash has never supported the XVideo extension. The reason for this is that Xv scales YUV data and Flash uses RGB data. Now could this be converted and scaled absolutely, but Adobe has decided they are not going down that road. Xv can blit both YUV and RGB data to the overlay. I do not know why do not they support Xv but this cannot be the reason... ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Candidate paper cut bugs for a new 8.2.x release?
Hi! I do not know what was the conclusion about this _completely hypothetical_ case but does fixing the Geode VGA driver match the paper cut criteria? Since I am porting (very slowly since 2 months ago I did not know anything at all about the Linux boot process for example) Android to the XO-1 there were some display errors. Android uses FBIOPUT_VSCREENINFO to flip (and not blit!!!) between two frames in video memory and without a patched Geode FB driver it causes a very awful flicker since the Geode FB driver turns off the video output then sets params then turns on the video output. Similar flicker can be seen on the XO when Sugar wakes up from a frozen DCON so possibly my fix would be applicable here as well. If fixing the driver is desirable then probably I could fix the other Geode driver bug, the video overlay fuckup during wakeup. My little question is this: does anybody know how and where the sleep happens? Is the video output turned off in the FB or the X driver? Is the FB driver used at all when the X driver takes control? ps: The attached file is not a patch but a VERY ugly fix for trying... :) Of course I will create a normal patch which can be pushed upstream but only if it is needed... Martin Langhoff wrote: In the _completely hypothetical_ case that I had some time and chance to spin a 8.2.x release aimed at fixing the paper cuts[1] and low-risk bugs that hinder XO-1 deployability _today_ in the field - have *you* got any candidates? Tell me about them :-) I am specially hoping to round up bugs that have patches that have been tested in the field. So low low risk stuff that makes life easier and better for those that really matter: kids and teachers in the field. No promises for now, but I sure want to find a way to do this. Daniel's piled up a few good patches I am aware of, but I am sure there are more (from him and others). cheers, martin 1 - https://wiki.ubuntu.com/PaperCut geode_fix.tar.gz Description: application/gzip ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: kernel debugging
Somehow every time I asked about debugging in these forums I have got no answer at all. Now I have a weak feeling that Linux developers are real programmers who do not use debuggers. I hope it is not the case... :) 2. I looked into using the USB port with gadget support. I am attaching the kernel config if you are interested in. I have compiled amd5536udc.ko, g_serial.ko and g_android.ko as modules (so I can look at error messages while doing an insmod). (Kernel 2.6.29, g_android.ko would enable debugging via USB with the adb - Android debugging bridge.) If I do not insmod amd5536udc.ko, then both g_android.ko and g_serial.ko bark me about missing usb_gadget_register_driver symbol. If I do insmod amd5536udc.ko then both modules bark about (No such device) error. What is not clear whether this amd5536udc.ko is usable at all because I am booting the XO-1 from an USB stick so can the AMD southbridge be used for both host and device at the same time? What device does it need? I succeeded compiling kdb into the kernel, and I have an USB keyboard (and successfully realized what must be compiled into the kernel) so I can press the Pause button to break into the debugger. However when I exit kdb crashes the machine so this way I cannot debug the g_android.ko driver. I would appreciate some answer to any one of these questions: 1. What is the Pause button on the XO keyboard? (And which is the SysRq?) 2. If there are no such buttons then how can I change the required button? Is it wired into the kernel or to kdb's keyboard handler? 3. It happened that one of the hardware in my room had a FTDI usb to serial converted. I pluggeg it into the XO-1 and insmod usbserial.ko then insmod ftdi_sio.ko and both worked. However I do not have a /dev/ttyUSB... entry. It can be that because the system does not run udev or similar it does not automatically create /dev entries? If so then how can I do this? (I see that the init srcript uses mdev -s) Another issue is that this serial stuff will be loaded much later than kernel start so if I define console=/dev/ttyUSB0 in the kernel parameters and the device will be created later then will Linux pick up the device at that time? It seems that if I use mdev -s then /dev/ttyUSB0 appears. What I found is that in the hardware I pulled the FTDI converter had a cable similar what I just needed so I plugged the cable into my PC's motherboard, its plug into the serial cable, the serial cable's plug into the FTDI bridge and the bridge into the XO-1. Then I started getty ttyS0 or something similar and nothing happened. Exactly how could I test the setup? ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Disk layout for XO-1.5
Once BTRFS is mature, yum learns to snapshot-upgrade-or-revert and we switch to that combo, we will be able to retire olpc-update, the symlink trees and the fancy overlays. Do you have a prediction (I mean an educated guess) about when will BTRFS be mature? What I heard last time that they had to change the on disk layout so I do not know why do you seek for example firmware support for BTRFS. (I am really just interested in some roadmap.) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
kernel debugging
Hi! Recently I have started porting Android-x86 to the XO-1 and unfortunately hit a wall. I know that it can be done since somebody already booted it but the hard drive crashed in his laptop and he had no backups... The porting progresses a little bit slowly because I know almost nothing about Linux but at least it is some motivation to learn it. My problem is that I cannot debug the kernel nor see its debug output because the XO-1 does not have a standard serial port. 1. I have read this page: http://wiki.laptop.org/go/Serial_adapters What is not clear to me is whether I should buy the converter which is on the picture (I did not get one in my XO's box) or shall I fabricate one or shall I request one from OLPC? Will it be good for XO-1.5? What is another option would be buying one of these: http://wiki.laptop.org/go/Serial_adapters#Third_Party_Adapters What is not clear that how will I fabricate a cable which connects those adapters to the XO? 2. I looked into using the USB port with gadget support. I am attaching the kernel config if you are interested in. I have compiled amd5536udc.ko, g_serial.ko and g_android.ko as modules (so I can look at error messages while doing an insmod). (Kernel 2.6.29, g_android.ko would enable debugging via USB with the adb - Android debugging bridge.) If I do not insmod amd5536udc.ko, then both g_android.ko and g_serial.ko bark me about missing usb_gadget_register_driver symbol. If I do insmod amd5536udc.ko then both modules bark about (No such device) error. What is not clear whether this amd5536udc.ko is usable at all because I am booting the XO-1 from an USB stick so can the AMD southbridge be used for both host and device at the same time? What device does it need? 3. It happened that one of the hardware in my room had a FTDI usb to serial converted. I pluggeg it into the XO-1 and insmod usbserial.ko then insmod ftdi_sio.ko and both worked. However I do not have a /dev/ttyUSB... entry. It can be that because the system does not run udev or similar it does not automatically create /dev entries? If so then how can I do this? (I see that the init srcript uses mdev -s) Another issue is that this serial stuff will be loaded much later than kernel start so if I define console=/dev/ttyUSB0 in the kernel parameters and the device will be created later then will Linux pick up the device at that time? 4. Of course the 3. point will not work that easily since I have only one serial cable and that has a plug and a receiver so it cannot link the two receivers on the ends. Will I have to use a null-modem cable or what? It also turned out that my new computer does not even have a serial port outside so I will have to buy a serial adapter anyway. What would be much simpler if I could just somehow make the USB connection work. What I think that there is no standard cable which has 2 Type A plugs at both ends but it seems that if I tear down the surrounding metal ring from the Type A receiver then it can be plugged into the Type A receiver on the XO-1 and it has the correct wires in the correct position (since the connector has to be flipped to fit into the receiver). Is it correct? Can somebody help me with any solution? (One would be enough...) I have attached the files if somebody wants to look at them. I use make iso_img TARGET_PRODUCT=xo1 TARGET_BUILD_TYPE=debug to build files then copy from out/debug/target/product/xo1 the files initrd.img, ramdisk.img, kernel and system.img into /boot in the usb drive (also olpc.fth). It uses the source from: http://code.google.com/p/android-x86/wiki/GetSourceCode android-xo1.tar.gz Description: application/gzip ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New F11-for-XO1 build is available and needs testing
I copied both files to a usb drive then booted with holding the esc key. Then 'copy-nand u:\os3.img' then it copied and I got back the firmware prompt. It did not bark about wrong crc or something like that. Then I switched the XO-1 off then switched on and all I can get is a Boot failed error message. Reimaging with 802 works so it is not a hardware fault. How could others run this stuff? Steven M. Parrish wrote: I have taken over creating builds for the XO1 from Daniel, and have created a new build of F11 for the XO1. This build OS3 includes the pretty boot animations, and also replaces olpcsound with csound. I would apprectiate testing and feedback. I will have another build out early next week as well. Builds can be downloaded from http://dev.laptop.org/~smparrish/xo-1/builds/ The usual cautions apply: this is development code, there will be bugs. Installation instructions: use copy-nand to install os3.img with os3.crc. Steven = Steven M. Parrish - gpg fingerprint: 4B6C 8357 059E B7ED 8095 0FD6 1F4B EDA0 A9A6 13C0 http://tuxbrewr.fedorapeople.org/ irc.freenode.net: SMParrish @ #fedora-kde, #fedora-devel, #fedora-olpc, #sugar ___ 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
dev.laptop.org expored
dev.laptop.org uses an invalid security certificate. The certificate expired on 2009.06.06. 16:03. (Error code: sec_error_expired_certificate) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: A1 Motherboard specs diagram
There are no free 3D drivers. I have heard nothing to indicate that there are likely to be soon. I would be surprised if OLPC were to ship the proprietary drivers, though I cannot speak for them. Then please test the xvideo extension with sleep/resume. I assumed (wrongly) that there was some way to stretch-blit bitmaps to the video memory on X (as the Geode video processor is clearly up to this rescaling task). Unfortunately it turned out (or I am mistaken) that the only way to scale animations is to use the xvideo extension. However it is unusable on the XO-1 because of this bug. If the XO-1.5 will not have working OpenGL out of the box then probably it would be wise to have the only usable X feature for games in a working condition. http://dev.laptop.org/ticket/9307 ps: If somebody could prove me wrong in that X is not a clusterfuck and can do strectch blits then I would be happy... ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: A1 Motherboard specs diagram
You are mistaken. The Geode LX has a two scaler units, and neither can feed back to the main CPU. One of them is in the Geode Display Controller (not the DCON), and simply scales the entire screen to the output. The other is in the Video Controller, and can be used only for overlay scaling. Either way, the scaled output is never written to video memory. The Graphics Controller, which can manipulate video memory, does not contain a scaler. Yes, you are right, now I remember. Seems that somewhat the names of the multiple video units got mixed up in my head. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Bootloader question
The kernel init improvements will certainly bring 15 other seconds. Maybe some parallelisation of the sysvinit will save some time, say 5 seconds (low end estimation) Parallelization will not help at all if you are using JFFS2. The low level NAND driver that JFFS2 uses busy waits for I/O, and then JFFS2 is CPU-bound on the decompression step, preventing any useful concurrency. The busy-wait could be changed to an interrupt - if only someone had time to do the work and test it extensively. The decompression is going to be CPU bound no matter what you do, so the only option is to arrange for the important files not to be compressed (thus increasing the NAND footprint). Hi Guylhem! What I have been told: The busy waiting happens because there is no scatter-gather support in the NAND driver so the interrupt rate is high and it is faster to busy wait than to context switch. Probably it would help to interrupt for large IO and busy wait for small IO but it needs testing. I promise you that if you happen to make the required efforts to speed up booting then I will finish my fixed LZO decompressor code. It would make reading compressed files actually faster, just I am not a Linux kernel developer so integrating that with Linux would be your job. BTW why the doctors cannot just close the lid and open when needed? ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Fwd: The XO-1.5 software plan.
The 1GHz C7 is still a slow cpu, as it seems from reviews of similar netbooks: http://www.notebookreview.com/default.asp?newsID=4352 For most tasks it is slower than an 600MHz Celeron M and that's not exactly fast. Does anyone more familiar with the hardware have any idea of how fast it is when compared to the Geode? From my measurements of the Geode and the very limited documentation of the C7 I can speculate that the integer unit can have similar speed to the Geode clock-by-clock (but can have a better branch predictor and faster movsb/movsd implementation) and probably the floating point unit is better integrated so floating point code does not block the integer unit like on the Geode. So if we do not consider the 3d unit or the probably better flash hardware (scatter-gather support) it will have exactly the same speed on similar clock speeds but of course it can go more than 2x faster. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Fwd: The XO-1.5 software plan.
Please, always use reply-all. Answers inlined where I have an answer. Tiago Marques wrote: On Sat, May 16, 2009 at 6:42 PM, NoiseEHC noise...@freemail.hu mailto:noise...@freemail.hu wrote: The 1GHz C7 is still a slow cpu, as it seems from reviews of similar netbooks: http://www.notebookreview.com/default.asp?newsID=4352 For most tasks it is slower than an 600MHz Celeron M and that's not exactly fast. Does anyone more familiar with the hardware have any idea of how fast it is when compared to the Geode? From my measurements of the Geode and the very limited documentation of the C7 I can speculate that the integer unit can have similar speed to the Geode clock-by-clock (but can have a better branch predictor and faster movsb/movsd implementation) and probably the floating point unit is better integrated so floating point code does not block the integer unit like on the Geode. So if we do not consider the 3d unit or the probably better flash hardware (scatter-gather support) it will have exactly the same speed on similar clock speeds but of course it can go more than 2x faster. And the memory should also help, it should be enough. But still, IMHO Xfce would still be a better fit, especially since these laptops go to places where things being snappy is almost a requirement. I do not think that the memory speed is a bottleneck on the XO-1. The problem is that the Geode is an in-order processor and an uncached memory read block the processor for 25 clocks. It will be the same on the C7 unless it has a Core2 Duo category speculative memory prefetcher but of course I doubt it... BTW the faster memory will not hurt either. What about random write performance of the flash memory this time? That will be a show stopper if it's below at least 0.5MB/s. But that would be hard without cache for the flash. The 0.5 MB/s came mostly from the zlib compression code. With LZO the Geode could compress 10MB/sec so it would have been a big help in write performance but the conclusion from most of the developers was that the biggest win would be having per inode compression setting (like not compressing zip and jpeg files) but of course nothing was implemented. BTW I have a half-made asm zlib decompressor what I have left rotting since it became impossible to debug (hallowed are gcc developers and the holy UNIX command piping, gcc generates 1 line of debug info for a whole asm block). I have another half-made asm decompressor for LZO but it seems that the creator of LZO f***ed up the code and it has unused opcodes so I tried to actually document the LZO compressor but my efforts stalled since kernel developers were fired from OLPC (I will not integrate such code to the kernel that is sure). The conclusion is that if the XO 1.5 will use a normal filesystem then compression will not be supported so flash write speed will not be a bottleneck. As for Gnome/Xfce/KDE, whatever, how are you considering that older students guess where F1-12 are? Are any changes planned for the keyboard stamping to accommodate this change in direction or are you taking that as part of the learning process? I do not know so reposted to devel. Best regards, Tiago Marques ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Fwd: The XO-1.5 software plan.
Sorry, should have explained myself better, as I was also talking about memory speed and not size, this time. Ahh, if you wrote about memory size then never mind my comments. :) Thing is, most flash controller implementations are crap, and it will probably be the case with the one in Gen 1.5. I'm quoting 0.5MB/s in *random writes* to the file system, nothing to do with compression. Most decent SSDs can write at last 1MB/s with some topping 2MB/s, in random patterns, sequential is about 150MB/s+. Sequential is not the problem when using SD cards or most USB drives, random writes is, when you're trying to have an OS on it. The best drives around, from Intel, can do 20+MB/s in random writes. Most SSDs on the market are based on J-Micron controllers that can do, at most, 0.04MB/s in random writes. This causes the system to frequently stall when some app is performing heavy writes to arbitrary locations. Random reads are mostly very fast with every type of flash you can get. http://www.anandtech.com/storage/showdoc.aspx?i=3531p=25 http://www.anandtech.com/storage/showdoc.aspx?i=3531p=25 0.5MB/s in RR should be enough to avoid most stalls. I hope that Mich Bradley will educate us but it seems to me that the hidden eraseblock handling can be the problem with those devices (and if it is true then compression will not help it either). It seems to be that some tests are required with physical hardware, a paper processor will not be enough... :) Are there any plans using UBIFS? ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: ffreep support on Geode LX (XO-1)
I have just tested it on my XO and the Geode DOES NOT support the ffreep instruction. It could explain the halting shutdown when it stalls with a signal 15 (which happens to be SIGILL) and only continuing it when I switch to the other console (as I reported in [1]). So fixing it and creating a 803 is absolutely necessary IMHO. [1] http://lists.laptop.org/pipermail/devel/2009-May/024356.html Sascha Silbe wrote: Hi! While trying to use sugar-jhbuild on DebXO (Debian on XO-1), I encountered several programs that crashed with SIGILL, apparently during execution of ffreep. While the AMD Athlon Processor x86 Code Optimization Guide [1] claims that although insufficiently documented in the past, [ffreep] is supported by all 32-bit x86 processors, the AMD Geode LX datasheet [2] doesn't list ffreep. As ffreep was added to gcc 3.4 [3] and Build 801 seems to use 4.3.0, I'm wondering whether it has been patched/configured in some way to avoid this issue or whether the processor actually supports it and something else on my machine is broken. [1] http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/22007.pdf [2] http://www.amd.com/files/connectivitysolutions/geode/geode_lx/33234d_lx_ds.pdf [3] http://gcc.gnu.org/ml/gcc-patches/2002-11/msg01386.html CU Sascha ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel __ Information from ESET NOD32 Antivirus, version of virus signature database 4052 (20090504) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: ffreep support on Geode LX (XO-1)
please file a ticket at dev.laptop.org, with details on how to reproduce the ffreep issue using build 802. (if it's only reproducible with debxo (unclear from what's been written so far), then the priority (and the fix) will likely be very different.) I cannot reproduce it reliably so I do not know what should I file as a bug. What I have seen with 800 (months ago) can be seen here: http://wiki.laptop.org/go/Image:Xo_freeze_on_shutdown.png I think that it is sure that at least some parts of the 80x versions contain some code compiled with illegal instructions. the failure to switch to the UL-warning screen during shutdown is a secondary effect of whatever it is you're seeing, and if reproducible should have a second ticket filed. On Windows if there is a debugger installed and a program crashes then Windows asks if I wanna attach a debugger. Can something like this be done on the XO? Or shall I always run it from a debugger? If so then how can I do it? Or can I create a crash dump file somehow? It happens quite regularly but I cannot give your instructions. Do not you experience it? paul Sascha Silbe wrote: Hi! While trying to use sugar-jhbuild on DebXO (Debian on XO-1), I encountered several programs that crashed with SIGILL, apparently during execution of ffreep. While the AMD Athlon Processor x86 Code Optimization Guide [1] claims that although insufficiently documented in the past, [ffreep] is supported by all 32-bit x86 processors, the AMD Geode LX datasheet [2] doesn't list ffreep. As ffreep was added to gcc 3.4 [3] and Build 801 seems to use 4.3.0, I'm wondering whether it has been patched/configured in some way to avoid this issue or whether the processor actually supports it and something else on my machine is broken. [1] http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/22007.pd f [2] http://www.amd.com/files/connectivitysolutions/geode/geode_lx/33234d_lx_ds.pdf [3] http://gcc.gnu.org/ml/gcc-patches/2002-11/msg01386.html CU Sascha =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel __ Information from ESET NOD32 Antivirus, version of virus signature database 4059 (20090507) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Ambient light sensing via LED response
But why do you say you would need 1 mV accuracy ? Bright sunlight is far stronger than the light sources he used. I am not an engineer so forgive me if I am saying something stupid, but is not the goal to switch off the backlight if and only if there is no difference between the switched on and switched off state? I mean that this implies that you have to measure the mV at a light level when you cannot see the difference (what can be a much fainter light than the sun). ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: plz test Build 802 + Firmware Q2E41 = Candidate Release 8.2.1
A small amount of testing would be very good, yes. We don't expect any changes to be visible outside of the firmware and battery charging (behavior should be better in the presence of batteries with extremely low charge), but we should double-check that everything looks normal. Seems a little strange, I do not remember seeing this before (but it can be that I just did not watch other upgrades). 1. Inserted the USB stick, did a 4 button update with the power plugged in (and then left the stick inserted into the XO). 2. The machine rebooted without pretty boot (the little man with the dots). I could see the linux boot messages with the 1L-X logo on top and that is the strange thing. Then it asked for my name (as in first boot). 3. Then I shut down, and started to see if there was pretty boot. It restarted immediately after talking about the firmware and then updated the firmware. (I have no idea how could it work if the kernel would depend on a feature in the new firware.) 4. Then it started with pretty boot and works not (except the wireless needs the same canceling and then manual connection as I reported hundreds of times). Now wireless does not work with my PRE-N Belkin router (WPA) as usual. When it connects automatically then it throws up the password dialog and no matter what I do it will not connect and shows me the password dialog repeatedly. What I have to do is to cancel the dialog and click the AP icon when it does not blink. Then it accepts (and remembers) the given password. What I did is to look at the suspend/resume process by pressing the power button and what I noticed that after a suspend the XO looses the connection to the AP and it does the exact same thing as after a power up. So after every resume I have to cancel the dialog and connect manually. Another thing is that after extended use the shutdown process halts halfway and I have to press Alt+2 to continue. It then shows the shutdown graphics and then the XO switches off. (It is also a long standing bug.) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: plz test Build 802 + Firmware Q2E41 = Candidate Release 8.2.1
As I understand 802 differs from 801 only in the firmware. Is it true? Shall I test 802 if I have been using 801 for a long time? Will anybody fix kernel/X errors if I report them? Holt wrote: The build is now signed so you don't even need a developer key: http://wiki.laptop.org/go/Friends_in_testing Helping us test WPA (WPA2 especially) would be most useful, since these wifi connections sometimes fail as much as 20% of the time, when Release 8.2.0 seemed to fail only ~10% of the time. And of course try: http://wiki.laptop.org/go/1_hour_smoke_test Please help us clean up Release Notes on the way! http://wiki.laptop.org/go/Release_notes/8.2.1 Recap -- all you should need are these 2 files burned onto a USB stick: http://download.laptop.org/xo-1/os/candidate/802/jffs2/os802.img (233MB) http://download.laptop.org/xo-1/os/candidate/802/jffs2/fs.zip (155K) Follow the usual procedure (http://wiki.laptop.org/go/USB_update), grab Activities from your XO's Control Panel later, and Buzz (IRC Live Chat) if you get stuck: http://forum.laptop.org/chat Thanks! --Holt ___ 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-devel] [IAEP] 3D engine uses in a no-nonsense GUI (was: XO Gen 1.5)
I think most of those effects can be just as easily be done by the 2D engine (like what the Geode has). Of course it would need a LOT of coding, like killing the stupid X driver model with the X server process, using a compositing windows manager, rewriting GTK+ to use some form of retained rendering mode (like a super optimized Cairo library with some scene manager functionality) and finally fixing all of those GTK applications which became buggy because of this rendering change. Oh yeah, almost forgotten that moving to OpenGL would need just the same amount of work. So not only would it chew trough the XO 1.5's battery like crazy but it would not run on the XO 1.0 so does it really worth that effort? Martin Langhoff wrote: On Tue, Apr 21, 2009 at 1:42 PM, Martin Dengler mar...@martindengler.com wrote: Imagine if it actually looked like the demo: http://www.sugarlabs.org/index.php?template=gallerypage=media_01 Exactly my thoughts. There are a couple of things we have to be mindful of as we step into the wild 3D world... - memory footprint -- those smooth transitions count on having various full-screen buffers, one for each screen you might want to slide smoothly into. - batery burn -- the OpenGL API was originally designed for high end workstations, and has some battery-depleting features such as a hi-res timer event that triggers all the time and prevents sleep The iPhone uses these smooth UI tricks (to a fantastic effect), and its battery life is a fraction of every other phone -- I'd say that the 3D niceness is part of the reason why. cheers, m ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] [IAEP] 3D engine uses in a no-nonsense GUI (was: XO Gen 1.5)
Actually, GNOME 3.0 is moving into that direction (requiring OpenGL): http://lwn.net/Articles/327845/ Hehe, seems like that I have just invented Clutter... :) More seriously, it seems that Sugar just runs ahead of Gnome and reinvents almost everything which will be created by Gnome people (or will not be created since that article was just a plan). Do you feel comfortable that your efforts will not go into Gnome 3.0, or is there something I do not know about? Journal = GNOME Zeitgeist Karma = Clutter minus the OpenGL acceleration Sugar = social desktop etc ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: #9307 NORM Not Tri: 100% reliable way to test a DCON creates the wrong colors bug
I am not sure if anybody reads the OLPC trac anymore but this demo can show us a DCON bug which probably should be fixed in the gen 1.5 version. Since the program reproduces the bug in 100% of the time, I wish you good debugging. (If it turns out to be just an X bug then I do not know whether it will be fixed ever so never mind.) Zarro Boogs per Child wrote: #9307: 100% reliable way to test a DCON creates the wrong colors bug -+-- Reporter: NoiseEHC | Owner: jg Type: defect |Status: new Priority: normal | Milestone: Not Triaged Component: x window system | Version: Mass Production Hardware Keywords: | Next_action: never set Verified: 0| Deployment_affected: Blockedby: | Blocking: -+-- Run the attached program from the Terminal activity on an XO which has 801 and has power saving activated and wait until first the screen dims and then until the animation stops. After you wake the machine the colors will be wrong. Repeat 3 times to get back the good colors. Now if it a DCON bug then you should probably fix it before gen 1.5 comes out. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO Gen 1.5
But this should improve with VIA now having employed Harald Welte of gnuviolations.org fame to help them move forward in the open source world. They have released their drivers and some manuals for their GPUs now. So no 3D just yet, but then that's not exactly a regression compared to the geeode video either. Details of Harald's VIA related OSS releases can be seen at the link below including links to various HW programming manuals. I do not know. I tried to download the specification to their processor and gave up after seeing the massive registration and request forms required. It is clearly ridiculous. If somebody has the spec please put it onto the wiki, please. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO Gen 1.5
Hi! I would like to ask these questions from OLPC staff: Does this also mean that people who already own XOs will find that new software is going to require a computer more powerful than they currently have? I thought that that was something that was going to be specifically avoided. This is going to be a hard trap not to fall into, although several of the primary activities (Browse and Write) are based on desktop products that are not necessarily aimed at low-power or embedded systems, so I don't know if things will actually be any different. What about the integrated 3D support? Are you planning to support OpenGL? In that case there will be a very wide performance gap (like 3D acceleration vs no 3D acceleration)... Also it seems that this machine will be on par with current Netbooks. Are you planning to sell it through normal distribution channels? (As I am interested in theat still no Netbook has the display or the indestructible design my XO has.) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: rotate button sucks on the XO
in any case, so far i've heard no good argument against rotating the touchscreen to match the screen. it may not be the most convenient way to use or hold the laptop, but it would be better than the current situation where screen rotation makes the touchpad almost completely useless. The question remains whether we make it rotate to match the closed ebook mode or match the rotated opened-like-a-book mode. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: rotate button sucks on the XO
Jordan, thanks for the info. I only started to use the XV overlay because I had this little hope that somehow I could get a pointer to a hardware buffer to avoid blitting the data but as I see it now the LX driver simply copies the overlay data to the hardware buffer so I could just use simple X surfaces as well speedwise. Is it true? Could you please answer those question from my earlier message? (copied here): A little question to Jordan Crouse or anybody else who can answer. Here Jodran told me that the Geode can do XV flipping: http://lists.laptop.org/pipermail/devel/2007-May/005208.html It can be that he either did not reflect to that one part of my message or I am just too stupid to make it work. So what I do not see in the XV documentation is how to allocate two xvideo frames and flip between them? What this code currently does is allocating one frame and doing XvShmPutImage. Because its speed depends on the size of the xvideo frame I think it does blittting (copying) and not flipping (switching). So how to do flipping? ps: Actually I would need 3 frames for triple buffering but I would be happy even with 2 frames. Jordan Crouse wrote: Benjamin M. Schwartz wrote: Jordan Crouse wrote: NoiseEHC wrote: 2. An Xvideo RGB overlay displays the big nothing (black) while the screen is rotated. Indeed - XV is purposely turned off when the screen is rotated (or at least, not displayed): The LX hardware supports rotated blits, right? So in principle, rotated XV could be added to the driver if someone cared sufficiently...? Absolutely - and as a special bonus, the LX groks how to rotate YUV data natively, so both YUV and RGB video can be rotated. Jordan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
What to expect from developers, are there any left? (was Re: rotate button sucks on the XO)
p...@laptop.org wrote: but like david, i think that currently neither olpc nor sugarlabs is going to foster or champion their use: olpc has no resources for s/w development, and as far as i can tell, sugarlabs is targeting other h/w platforms just as strongly as the XO -- and other platforms don't have these screen issues. Witch the recent disbanding of the development team I simply cannot see what will happen to the XO development. I mean that 8.2.1 will be released and 9.1.0 is dropped but what I do not understand is what will happen with all the development for 9.1.0? What I heard is that those will be pushed upstream (whatever that means) but it is not clear if reporting bugs or talking about button layouts on the game pad will result in a new software release or is just a waste of time. What I mean is that should I also subscribe to some Fedora devel list (note that I do not know sh*t about linux development, packaging or anything like that) to keep informed or what? Currently I am writing a nice activity which teaches kids what to do when alien spaceships attacks Earth and it will take some time to finish. What should I do next? Can some insider comment on these issues please? ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
What to expect from developers, are there any left? (was Re: rotate button sucks on the XO)
Sorry, I wanted to post it toplevel. p...@laptop.org wrote: but like david, i think that currently neither olpc nor sugarlabs is going to foster or champion their use: olpc has no resources for s/w development, and as far as i can tell, sugarlabs is targeting other h/w platforms just as strongly as the XO -- and other platforms don't have these screen issues. Witch the recent disbanding of the development team I simply cannot see what will happen to the XO development. I mean that 8.2.1 will be released and 9.1.0 is dropped but what I do not understand is what will happen with all the development for 9.1.0? What I heard is that those will be pushed upstream (whatever that means) but it is not clear if reporting bugs or talking about button layouts on the game pad will result in a new software release or is just a waste of time. What I mean is that should I also subscribe to some Fedora devel list (note that I do not know sh*t about linux development, packaging or anything like that) to keep informed or what? Currently I am writing a nice activity which teaches kids what to do when alien spaceships attacks Earth and it will take some time to finish. What should I do next? Can some insider comment on these issues please? ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: rotate button sucks on the XO
p...@laptop.org wrote: noiseehc wrote: The question remains whether we make it rotate to match the closed ebook mode or match the rotated opened-like-a-book mode. there's no good answer to this, because there's no way to make it do the right thing automatically. the lid switch can't be used, because by definition the laptop isn't really in ebook mode when you're trying to use the touchpad. there's no way for the laptop to tell that the screen is flipped around, which is what's needed. user configuration might be possible, but frankly, i'd just default it to match the opened mode. i've gotten used to (in almost-ebook mode) moving my finger opposite to the direction i want the pointer to move, and i never rotate the screen in that mode precisely because of the rotation issue. so it would be a win just to have the finger-to-pointer relationship be predictable, even if it's not right. +1 The question remains who will code it though :) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: What to expect from developers, are there any left? (was Re: rotate button sucks on the XO)
Daniel Drake wrote: It is unlikely that you (as a user, rather than a deployment) reporting bugs to OLPC will result in another software release *direct from OLPC* (such as 8.2.2), because development of 8.2.x is mostly discontinued and will really only be driven by deployments. Have you read? http://wiki.laptop.org/go/Future_releases It may not answer all your questions but it is the most concrete documentation that I have seen so far. I have already read that page and was aware of those issues. Unfortunately it does not answer my questions. In terms of reporting bugs, the process of upstreaming everything basically means that OLPC is no longer the distributor and that bugs should be reported directly to the people who are more responsible for the them. My main problem is that knowing who is more responsible requires knowing linux more that I am comfortable with (I am a Windows developer). Here are just 3 examples to show my point: 1. Today I noticed that my simple program can crash the whole sugar desktop and the X server. Shall I report it to somewhere? I do not even know where to look for log files to attach to a bug report. Also if nobody will fix it (I cannot fix it that is sure...) then why should I care? Does it mean that if no deployment will bark that the desktopX can be crashed then it will not be fixed ever? 2. I can reliably (100%) trigger the cannot connect to WPA and the dialog asks for a password endlessly bug but unfortunately I do not know how to debug that thing. To tell you the truth I do not even know where to look for the code of NetworkManager (somebody told that this can be the problem) and even if I knew it usually I cannot compile downloaded linux code for some arcane reason beyond my understanding. So for example in this situation what should I do? Is this NetworkManager part of some linux distro, or is it an XO thing? If it is part of fedora, who should I report bugs to? 3. Okay, I have forgot the third one... :) Note that I am totally aware that these things are not your responsibility, I would just like to have some answers from somebody. If the solution is installing some distro then I will do it, the big question is that which one will be the official one? What would you do if you ran Ubuntu on your main computer but some of the buttons on your keyboard were not working correctly? You would file a bug with Ubuntu, who would hopefully either fix the problem on their own back, or help you to report the issue to the developers of the related package (which would likely be one of the X.org input components, in the case of keyboard troubles). Frankly, if some of my buttons would not work in Ubuntu I would simply format the machine and install Windows. :) Work with the relevant upstream component. In this case, you are working on a sugar activity, so develop it as a platform-neutral activity at sugarlabs.org, and work with sugarlabs' standard processes of getting activities included in distributions. This is not an activity in the strictest sense, it is more like a library which shows what the XO hardware can do in animation. After that probably I will use the lessons learned to optimize GCompris and PyGame because currently they look like Powerpoint presentations... So the whole point is to work fast on a physical XO hardware. Of course if somebody will tell me that the XO is a dead thing and OLPC will cease then I will reconsider wasting my time. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: What to expect from developers, are there any left? (was Re: rotate button sucks on the XO)
I don't know what your simple program does, but it sounds like it could be a Sugar bug. You should file a ticket at dev.sugarlabs.org. If it is not related to Sugar, we'll try to pass the report along to the proper place. http://dev.sugarlabs.org/ticket/465 It does sound like NM. Look at ~/.sugar/default/nm There is still an engineer at OLPC looking into WPA on the latest builds. Reported here, no answer: http://lists.laptop.org/pipermail/devel/2009-February/023504.html I just would like to know if testing is worthwhile or just wastes my time. Thanks anyway! ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: What to expect from developers, are there any left?
p...@laptop.org wrote: Cannot comment on the first part, I have no idea how this linux distro development thing goes... this is a much simpler question: there's a lot of work going on in sugarland to help activity writers. since activities are released independently, the distribution aspects that affect XO base s/w aren't really an issue. http://sugarlabs.org/go/ActivityTeam I have already answered this to Daniel Drake. Can some insider comment on these issues please? you may be overestimating a) the number of insiders, and b) their stash of undisclosed information From my point of view every linux/sugar developers are insiders in this project especially fedora developers. Do they all have an XO by now or OLPC just missed it? . paul =- paul fox, p...@laptop.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
rotate button sucks on the XO
Hello! Just today I have noticed some things about the rotate button (which is below the directional buttons on the display part): 1. When the screen is rotated the mouse does not so if I turn the XO to be able to read letters, I cannot navigate with the mouse. 2. An Xvideo RGB overlay displays the big nothing (black) while the screen is rotated. If somebody will fix it to be usable then it would be a good idea to program the rotate button so that holding pressed for 2 seconds would turn on-off the backlight (color to mono and back). ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: rotate button sucks on the XO
p...@laptop.org wrote: while i can understand the frustration when something that seems simple and obvious doesn't work, starting wout with sucks probably isn't the best way to get people to listen to your issues. From my experience, it is the most straightforward way to get some reply to my mostly arcane questions... :) I am sorry if I offended people. how do other people feel about this problem? are there any good reasons to _not_ make the touchpad rotate with the screen? (i actually think this might be an almost, but not quite, trivial addition to the grab key daemon i mentioned to the list last week. matching the touchpad orientation to the orientation of the screen initially would be the tricky part -- if they were out of sync, it'd be a real drag.) Unfortunately I do not have enough linux programming experience to do this otherwise I would have been already done that. noiseehc wrote: Hello! Just today I have noticed some things about the rotate button (which is below the directional buttons on the display part): 1. When the screen is rotated the mouse does not so if I turn the XO to be able to read letters, I cannot navigate with the mouse. 2. An Xvideo RGB overlay displays the big nothing (black) while the screen is rotated. If somebody will fix it to be usable then it would be a good idea to program the rotate button so that holding pressed for 2 seconds would turn on-off the backlight (color to mono and back). is this simply to make the backlight controllable from ebook mode? because shift-increase and shift-decrease (or is it ctrl?) accomplish this pretty simply now. Yes, it would be just for the ebook mode. I think it is a more sane proposition than for example overloading the power button with extra functionality. paul =- paul fox, p...@laptop.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: rotate button sucks on the XO
Aaron Konstam wrote: On Sun, 2009-03-01 at 17:06 +0100, NoiseEHC wrote: Hello! Just today I have noticed some things about the rotate button (which is below the directional buttons on the display part): 1. When the screen is rotated the mouse does not so if I turn the XO to be able to read letters, I cannot navigate with the mouse. You can navigate but in a sense sideways. Movng the arrow up makes it go up. But relative to the text it is wrong. Yeah, just if I turn the laptop to read the text then it is a little bit impossible to hit anything with the cursor... ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: rotate button sucks on the XO
Eben Eliason wrote: This whole argument, I feel, is fruitless. That's just my opinion, of course. The touchpad isn't readily accessible in handheld mode, and was never made to be. I'll continue to suggest that the cursor simply be automatically hidden in handheld mode, and that a simple means for taking full advantage of the handheld buttons which are present be made available to activities in a standardized way. This argument rests on the wrong assumption that the user can only rotate the screen in handheld mode. Of course the user can open the laptop as a book and read it rotated while using the touchpad with one of his thumbs. A suggestion for how this standardized system might work is laid out rather clearly at http://wiki.laptop.org/go/Browse#Handheld_Mode. I'd very much like to see an API for the press and press-and-hold states of these buttons so that activities could take advantage of it easily I have read this page but it does not talk about screen rotation at all. Unfortunately (last time I checked) most of the activities are handling keyboard focus badly and they usually need some help with the touchpad to focus to their scrollable area. In handheld mode it means opening the screen a little bit as david Lang has just said. A footnote is that this latter touchpad usage conflicts with the one I have talked about halfway on this page, just imagine it :) ps: I would like to hear a similarly interesting conversation about the xvideo surface and X11 driver, please! ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: OS/X11 support for XO-1 hardware?
If you need it for some game then here is how to do it: attached. A little question to Jordan Crouse or anybody else who can answer. Here Jodran told me that the Geode can do XV flipping: http://lists.laptop.org/pipermail/devel/2007-May/005208.html It can be that he either did not reflect to that one part of my message or I am just too stupid to make it work. So what I do not see in the XV documentation is how to allocate two xvideo frames and flip between them? What this code currently does is allocating one frame and doing XvShmPutImage. Because its speed depends on the size of the xvideo frame I think it does blittting (copying) and not flipping (switching). So how to do flipping? ps: Actually I would need 3 frames for triple buffering but I would be happy even with 2 frames. Chris Marshall wrote: With the spin-off of Sugar development to sugarlabs, it is nice to see the development continued. However, it seems that the OLPC layoffs and refocus has scuttled the work to complete some OS and system software support for the XO-1 hardware features. For example, I have been waiting for the video scaler support to allow for adjustable display resolutions on the XO. Among other things, it would allow programs that don't understand a 1200x900 but only 6x4 display to work at a more usable resolution where the graphic elements and text/fonts are consistent and visible to the naked eye... It would allow for much improved video performance since you could play back a 320x240 video on the full screen at considerable CPU savings. I had thought this capability would be coming with the Fedora 10 move in 9.1.0. With that release now scuttled, I'm wondering more generally, are these pieces being picked up anywhere? Would it make sense to have an 8.2.2 release involving the move to Fedora 10 but pretty much the same as 8.2.1 otherwise? --Chris ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel xvscale2.tar Description: Binary data ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
testing 8.2.1 - 800
I had some time lately and tested the latest signed release. I have reimaged (with 4 button pressed start) my XO and after that installed activities via olpc-update and some yum mc/gcc/make/X11-devel/Xv-devel. I did not copied my developer key to /security this time. The extreme power management is unchecked (the default setting). 1. While doing some yum list something on the virtual console my XO freezed and only could restarted by holding the power button for 5 secs. Nothing was written to the console (but it was the 2. console). The file what yum generated stopped abruptly halfway. 2. The wireless works as it did with 763 or something (I have never installed 767). It cannot connect to a Belkin PreN with WPA (100% displays the password dialog and no matter what I type into it the machine just redisplays the dialog). After I cancel the dialog then I can just click on the AP and it connects 100%. I do not really remember how did it work last year but it seems that I no longer have to wait until the XO stops scanning mesh networks (and it does not seem to stop it anyway). 3. After using the XO for 2 hours while developing some XVideo using applcation and closing the lid several times and stealing some unprotected wifi to browse the web (I was waiting in a hospital for 2 hours), I finally shutdowned the machine and it freezed with libertas: tx watch dog timeout. After I pressed the power twice to sleep and wakeup, the shutdown continued, displayed the shutdown screen and the the XO switched off. The error message was uploaded here: http://wiki.laptop.org/go/Image:Xo_freeze_on_shutdown.png So it is a regression since the old image was not used to crash or freeze during shutdown and the wireless seems to be just as broken as it was (probably the suspected network manager race condition what I was speculated lately). ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 9.1 Proposal: Top five performance problems
The Geode X drive copyes every bit of data to the command ring buffer by using the CPU so that is sure that those almost no CPU cycles thing is at least a bit stretch... :) According to Jordan Crouse it will not be better but he was not too concrete so in the end I am not sure what he was really talking about, see: http://lists.laptop.org/pipermail/devel/2008-May/014797.html Benjamin M. Schwartz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Erik Garrison wrote: What about changing the kind of visual feedback we give. Instead of pulsing icons what about icons with a string of dots beneath, a progress bar, flashing, or another kind of overlay feedback which requires fewer visual changes (frames) and/or could be overlaid on top of existing icons without calculating a new animation for every icon? We have GPU-accelerated alpha compositing on the XO, so we could do the current animation using almost no CPU cycles. It's just a question of figuring out how to access that compositing. As far as I'm aware, no effort in this direction has been made. I don't know if composite here requires the use of Composite in the window manager or not; my knowledge of X is minimal. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkkCPQAACgkQUJT6e6HFtqSlSwCfVrZfVFFUqbwgBuLJCckGmHDc S40An2vtXMot6/rz9YmceB38geDaQhH4 =aOse -END PGP SIGNATURE- ___ 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: 9.1 Proposal: Top five performance problems
Could you be a bit more specific, please? What did you mean when you talked about that moving a little bit more of the driver to kernel level would not help? (This was the mentioned thread I had with Bernie.) Also could somebody enlighten me why we does not use DirectFB? Is it because of there are not enough developers or because it is not technically sound? Jordan Crouse wrote: On 25/10/08 00:00 +0200, NoiseEHC wrote: The Geode X drive copyes every bit of data to the command ring buffer by using the CPU so that is sure that those almost no CPU cycles thing is at least a bit stretch... :) According to Jordan Crouse it will not be better but he was not too concrete so in the end I am not sure what he was really talking about, see: http://lists.laptop.org/pipermail/devel/2008-May/014797.html Indeed - many CPU cycles are used during compositing. There is a lot of math that happens to generate the masks and other collateral to render the alpha icon on the screen. The performance savings in the composite code comes from not having to read video memory to get the src pixel for the alpha operation(s). That performance savings is already available in the X driver today. Jordan Benjamin M. Schwartz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Erik Garrison wrote: What about changing the kind of visual feedback we give. Instead of pulsing icons what about icons with a string of dots beneath, a progress bar, flashing, or another kind of overlay feedback which requires fewer visual changes (frames) and/or could be overlaid on top of existing icons without calculating a new animation for every icon? We have GPU-accelerated alpha compositing on the XO, so we could do the current animation using almost no CPU cycles. It's just a question of figuring out how to access that compositing. As far as I'm aware, no effort in this direction has been made. I don't know if composite here requires the use of Composite in the window manager or not; my knowledge of X is minimal. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkkCPQAACgkQUJT6e6HFtqSlSwCfVrZfVFFUqbwgBuLJCckGmHDc S40An2vtXMot6/rz9YmceB38geDaQhH4 =aOse -END PGP SIGNATURE- ___ 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: 9.1 Proposal: shutdown menu
In the old builds I could initiate a shutdown and close the lid and the XO just finished the shutdown. In the new builds when I close the lid the shutdown halts because of suspend (I think, can be mistaken). Could it be a little bit more clever about when to suspend? Or is it what you are referring with (this will need to interact with lid-close in a sensible manner.)? [EMAIL PROTECTED] wrote: this feature has been discussed on the list(s) earlier, but i'm not sure of its status. i'd like to make sure it gets on the table. (and it just came up in dan's ethiopian report.) currently it is much easier to crash the laptop (by holding the power button down) than it is to shut it down cleanly. while the journalled filesystem (currently) can recover from this on the next boot, application writes in progress might not. pushing the power button on the laptop should present a menu or dialog allowing shutdown. as a strawman UI, the pushing the button should result in a simple dialog that looks like: The laptop will suspend in 5 seconds. Shutdown | Suspend Now | Cancel (this will need to interact with lid-close in a sensible manner.) paul =- paul fox, [EMAIL PROTECTED] ___ 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: journal is hard (was Re: notes from the field - Mongolia)
We can do a little better than that, actually, by making it all one prompt. It can have a name field, already filled out with the best darn attempt at a name we can manage, a tag field (and perhaps even a list of popular tags as well, to apply to it with a click or a drag/drop), and buttons for [Erase] (Or [Don't Keep]?) and [Keep]. A little better solution would be if the words in the name would be treated as tags and if the save dialog would offer autocomplete for those tags. Tagging via the Journal could just set words to super tags so they would not be shown in the name but would be handled harder than soft tags in searching or in the proposed tag submenu thing. If the user would type in the tag via autocompletion then it should be treated as an explicit tag. I am not sure if you can understand it so here is another try from the opposite side: The problem with tagging is that it is painful to select something on the XO from a drop down menu (the list of available tags). (Note that developing Sugar on a Linux PC is cheating...) The whole notion of explicit tagging is also a nuisance and requiring tagging at save time is painful. So this proposal just tries to simplify the process from the user's perspective (and makes coding the Journal very very hard, but since somebody other than me will code it I do not care...). Autocompleting, not only tags but soft tags too, would result in that if the user is doing some project lately then the system would offer him the project's name since probably it would be used lately a lot. Also it could be used for filesystem paths as well but probably I should see that GNOME UI Hackfest video first. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 5 sec boot
can you do the hash as you copy it? it should be pretty close to free at that point (since the CPU is waiting for memory/flash access it can do the hash calculationwhen it would otherwise be stalled) According to my measurements the GeodeLX can fetch a new cache line (32 bytes) every 20-25 clocks. Unless you can do the hash 2 clocks/byte then you will only earn the looping time (assuming that the hashed blocks fit into the L1 cache). ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 5 sec boot
On Sun, 5 Oct 2008, NoiseEHC wrote: can you do the hash as you copy it? it should be pretty close to free at that point (since the CPU is waiting for memory/flash access it can do the hash calculationwhen it would otherwise be stalled) According to my measurements the GeodeLX can fetch a new cache line (32 bytes) every 20-25 clocks. Unless you can do the hash 2 clocks/byte then you will only earn the looping time (assuming that the hashed blocks fit into the L1 cache). is that speed reading from ram or from flash? DDR RAM, if neither the L1 nor L2 was hit. I did not measure raw NAND read speed, I do not even know how to begin with it. see: http://wiki.laptop.org/go/Geode_LX#Memory.2C_Cache_and_TLB ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 5 sec boot
When I will finally have some time (currently I am working even on weekends) I will finish my half made zlib decompression code. Where is that Security hash's code? Mitch Bradley wrote: Memory to memory copy: 500 MB/s Raw NAND FLASH read:20 MB/s Security hash: 4 MB/s So overlapping hash calculation with NAND FLASH read is of limited value, and trying to overlap anything with memory copy is almost certainly counterproductive. This discussion seem to be degenerating into a brainstorming session about an sub-problem that is pretty well under control (the firmware component of the boot time). I've been working diligently on that sub-problem for nearly 2 years now, and I think I have an excellent grasp of where the cycles are going and what can be done to improve it. The only significant opportunity at this point is to reduce the JFFS2 time, which will require either partitioning or abandoning JFFS2 for the boot files, or both. UBI+UBIFS is one workable approach in the context of a Linux-only machine. There are some others, such as Redboot partitions with a small boot partition and a large system partition, with various FS possibilities for the two partitions. The quickest path to a deliverable system would be Redboot + JFFS2 boot partition + UBI system partition. The rest of the fruit on the tree is solidly in the OS domain, encompassing kernel startup, userland startup/initscripts, X startup, and Sugar / application startup. I would encourage each of you to address the areas in which you have special expertise, and then to take action. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 5 sec boot
To what end? AFAIK the zlib decompression (both in OFW and in the OS) is not one of the primary problem areas. Changing fs read from CPU bound to IO bound would change a lot of things, for example the boot could utilize a little bit of more concurrency. Unfortunately we will only see its effect when the code is written (or we will see that it does not help). It is not a problem area but first there are projects which would gain on this speed (like etoys loading AFAIK), and second every speed optimization (like boot time and activity launch time) should take into consideration the faster reading speed (which is theoretical at this point). See, I am NOT suggesting that you should waste time on these nonproblems but I am not a Linux programming expert so I simply cannot help you at this time (finishing 8.2.0) so I spend my (currently not existing) time on these nonproblem projects. Where is that Security hash's code? The computation code is at http://dev.laptop.org/git?p=bios-crypto . It is based on LibTomCrypt. The specific hashes and signatures that we use are detailed in the Computation column of http://wiki.laptop.org/go/Firmware_security#Summary The security computation code has undergone an audit by outside security experts. Any changes to the core code would require an additional audit. Exactly which algorithm does the firmware use and how much data does it hash? Just out of curiosity... ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
5 sec boot
If you somehow missed it, there is possible to boot Linux in 5 seconds on an EeePC. http://uk.youtube.com/watch?v=s7NxCM8ryF8 Here is the paper: http://www.fenrus.org/plumbers_fastboot.ppt Could somebody explain me whether these results are applicable to the XO, and how far are we from it, please? ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: simple datastore replacement, take two
The Datastore can then provide two accessor functions: get_by_value(key) and get_by_reference(key). get_by_value() returns the contents of the file as a bytestring in memory. get_by_reference() returns the path to the metadata file, or another path linked (soft or hard) to that file. This provides all the needed functionality for large and small metadata entries. That sounds interesting. I guess that with a POSIX-like API implemented with FUSE we would get equivalent fucntionality? What is the plan on Windows compatibility of Sugar? I mean, is there a version planned which can run on Windows? I ask this because if there is a plan like this then probably you should forget everything FUSE related since it will be impossible to implement that on Windows as I barked about here (there is a lot of inlined text in the message): http://lists.laptop.org/pipermail/devel/2008-April/013330.html http://lists.laptop.org/pipermail/devel/2008-April/013345.html ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
