Re: using laptop charger

[NoiseEHC]

Thanks for all the answers, I will let you know whether my XO 1.75 will 
be destroyed by the Toshiba adapter... :)



On 11/12/2013 20:29, John Watlington wrote:

James is correct about 19V probably not working with an XO-1, but with an 
XO-1.75/4
you should be fine up to 24V.

When running with an input voltage higher than 13V, the battery charger on the
motherboard runs noticeably hotter. Still within spec at 19V and 45C 
ambient,
but you might notice the difference in case temperature near the DC input plug
if charging an empty battery.

Cheers,
wad

On Dec 11, 2013, at 3:09 PM, James Cameron wrote:


G'day Andrew,

There is a voltage above which the XO-1 will not charge, which had
been often encountered by people using solar panels.  Along would come
a cold sunny day, with a greater than normal voltage, and the charging
would stop.

I don't recall the actual voltage (Richard may remember), but I think
it was somewhere near 18V, and it varied slightly between laptops.

So it might work, or might not.

Instead of using a resistor, you might use two or three large diodes
in series, each of which will provide a "forward voltage" 0.6V drop.
Pick the diodes based on the maximum current 1.85A (usually double
that), and the power that will be released as heat; P = V x I, where V
is 0.6, and I is not to exceed 1.85A, so 1.11W minimum "power
dissipation".  Place them in a way that does not hold the heat in.

https://learn.sparkfun.com/tutorials/diodes

p.s. if you find one diode does what you need, then add another in
case of variation in the supply or laptop.  You might even add a
full-wave bridge rectifier instead of two diodes, that way the input
polarity won't matter.

On Wed, Dec 11, 2013 at 01:52:54PM +, NoiseEHC wrote:

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

--
James Cameron
http://quozl.linux.org.au/
___
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

using laptop charger

[NoiseEHC]

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.

[NoiseEHC]

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.

[NoiseEHC]

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.

[NoiseEHC]

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

Re: [Sugar-devel] Activity Central's Sugar related priorities.

[NoiseEHC]

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 

Re: x performance problem in webkitgtk

[NoiseEHC]

Just checked, build 12 fixed this. Thanks!

On 07/07/2013 21:14, Jerry Vonau wrote:

Think you ran into the same root cause as
https://dev.laptop.org/ticket/12718 might be fixed in 13.2.0-12

Jerry

On Sun, 2013-07-07 at 19:42 +0200, NoiseEHC wrote:

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 ' 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




___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: x performance problem in webkitgtk

[NoiseEHC]

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 ' 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

x performance problem in webkitgtk

[NoiseEHC]

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 ' 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

[NoiseEHC]

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

Re: compiling and running webkit2gtk on xo-1.75/os/candidate/13.2.0-9

[NoiseEHC]

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: compiling and running webkit2gtk on xo-1.75/os/candidate/13.2.0-9

[NoiseEHC]

On 27/06/2013 16:20, Daniel Drake wrote:

On Thu, Jun 27, 2013 at 8:08 AM, NoiseEHC  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

compiling and running webkit2gtk on xo-1.75/os/candidate/13.2.0-9

[NoiseEHC]

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: XO-3 Announcement?

[NoiseEHC]

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

[NoiseEHC]

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

[NoiseEHC]

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]

[NoiseEHC]

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
>   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

[NoiseEHC]

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: Turtles All The Way Down

[NoiseEHC]

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 NoiseEHC:
>> 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: [IAEP] Turtles All The Way Down

[NoiseEHC]

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 Kay  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

[NoiseEHC]

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: Turtles All The Way Down

[NoiseEHC]

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: The next four weeks

[NoiseEHC]

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 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
> 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

[NoiseEHC]

>> 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: The next four weeks

[NoiseEHC]

> 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

[NoiseEHC]

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: NOW: OLPC Contributors Program Mtg (#olpc-meeting, 3PM EDT, Apr 1)

[NoiseEHC]

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

[NoiseEHC]

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: XO-1.75 progress

[NoiseEHC]

 > 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: Announcing the OLPC OS 10.1.2 final release!

[NoiseEHC]

  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: Announcing the OLPC OS 10.1.2 final release!

[NoiseEHC]

  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!

[NoiseEHC]

  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: Update for geode driver

[NoiseEHC]

  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

[NoiseEHC]

> 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

[NoiseEHC]

> 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

[NoiseEHC]

> 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

[NoiseEHC]

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: F11-0.88 os260py

[NoiseEHC]

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: OLPC/Marvell Press Release

[NoiseEHC]

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 



From the article...

"Without applications, the device itself means nothing," said Barry 
Lam, chairman of the contract laptop manufacturer Quanta Computer 
 
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 
 Ltd.


...



Regards,
James Zaki


2010/5/27 Ed McNierney 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 "constructioni

Re: New keyboard layouts

[NoiseEHC]

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  
> 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  
> 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  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: New keyboard layouts

[NoiseEHC]

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  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  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  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: Impact of changing default Screen depth on other XO Apps

[NoiseEHC]

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=0B6XMYp250cOmZDhmOWNjMTQtMjNlNy00NDc0LTlhMmItNGI3M2NhMGFmNmVm&hl=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 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: Impact of changing default Screen depth on other XO Apps

[NoiseEHC]

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: OLPC hardware: what if there was an SDR modem / chipset?

[NoiseEHC]

> 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

[NoiseEHC]

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

[NoiseEHC]

2009/12/29 NoiseEHC :
  

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  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  Android kills children by 
not allowing to develop core applications on the XO  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

[NoiseEHC]

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

[NoiseEHC]

> 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

[NoiseEHC]

> 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: Android, OLPC, and native hosting

[NoiseEHC]

>> 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

[NoiseEHC]

> 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

[NoiseEHC]

>
> 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: XO-3 super-o-fficial

[NoiseEHC]

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 
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: XO-3 super-o-fficial

[NoiseEHC]

> 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: os33 - video regression ?

[NoiseEHC]

> 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: Booting squashfs from olpc.fth

[NoiseEHC]

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: Candidate "paper cut" bugs for a new 8.2.x release?

[NoiseEHC]

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: Disk layout for XO-1.5

[NoiseEHC]

>
> 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

Re: kernel debugging

[NoiseEHC]

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: New F11-for-XO1 build is available and needs testing

[NoiseEHC]

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

kernel debugging

[NoiseEHC]

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: A1 Motherboard specs diagram

[NoiseEHC]

> 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: A1 Motherboard specs diagram

[NoiseEHC]

> 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

dev.laptop.org expored

[NoiseEHC]

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: Bootloader question

[NoiseEHC]

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.

[NoiseEHC]

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=3531&p=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: Fwd: The XO-1.5 software plan.

[NoiseEHC]

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 <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.

[NoiseEHC]

> 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: ffreep support on Geode LX (XO-1)

[NoiseEHC]

> 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: ffreep support on Geode LX (XO-1)

[NoiseEHC]

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: Ambient light sensing via LED response

[NoiseEHC]

> 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

[NoiseEHC]

> 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

[NoiseEHC]

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)

[NoiseEHC]

> 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: [Sugar-devel] [IAEP] 3D engine uses in a no-nonsense GUI (was: XO Gen 1.5)

[NoiseEHC]

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
 wrote:
  

Imagine if it actually looked like the demo:
http://www.sugarlabs.org/index.php?template=gallery&page=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: XO Gen 1.5

[NoiseEHC]

> 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: #9307 NORM Not Tri: 100% reliable way to test a DCON creates the wrong colors bug

[NoiseEHC]

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

[NoiseEHC]

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: What to expect from developers, are there any left?

[NoiseEHC]

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

Re: What to expect from developers, are there any left? (was Re: rotate button sucks on the XO)

[NoiseEHC]

> 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? (was Re: rotate button sucks on the XO)

[NoiseEHC]

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 desktop&X 
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: rotate button sucks on the XO

[NoiseEHC]

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

What to expect from developers, are there any left? (was Re: rotate button sucks on the XO)

[NoiseEHC]

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

What to expect from developers, are there any left? (was Re: rotate button sucks on the XO)

[NoiseEHC]

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

[NoiseEHC]

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

Re: rotate button sucks on the XO

[NoiseEHC]

> 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

[NoiseEHC]

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: rotate button sucks on the XO

[NoiseEHC]

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

[NoiseEHC]

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

rotate button sucks on the XO

[NoiseEHC]

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: OS/X11 support for XO-1 hardware?

[NoiseEHC]

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

[NoiseEHC]

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

[NoiseEHC]

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: Top five performance problems

[NoiseEHC]

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: Power.

[NoiseEHC]

> as a G1G1 user one annoyance of enabling power savings is the screen 
> dimming while I am reading a page. I thought this was supposed to be 
> improved, but I saw the same thing when I upgraded to 767 a week ago.
>
>
>   
+1

I did not try 767 but I have found it very irritating in 763.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: 9.1 Proposal: shutdown menu

[NoiseEHC]

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)

[NoiseEHC]

> 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

[NoiseEHC]

> 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

Re: 5 sec boot

[NoiseEHC]

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

[NoiseEHC]

> 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