some first impressions

[Guylhem Aznar]

On 8/11/07, Jameson Chema Quinn <jquinn at cs.oberlin.edu> wrote:
> I've archived this discussion on robotics/LED output, with some points of my
> own, on the wiki at
> http://wiki.laptop.org/go/Electrical_output.

Thanks a lot for the summary on the wiki.

A quick suggestion : if there is a serial port in the XO (according to
the boot message, there is one) maybe it could also be used.
rx/tx/gnd/vcc already allow a lot of fun stuff and experimentation.

By the way, if there are other beginners out there, who are a bit lost
in the wiki, http://wiki.laptop.org/go/Getting_started_programming is
a great page to get started.

There is too much information to read everything in one day, but so
far I have found the following documents very interesting: (I'm new to
python, but I know a little javascript)

http://wiki.laptop.org/go/Understanding_sugar_code
http://www.pygtk.org/dist/pygtk2-tut.pdf
http://www.ibm.com/developerworks/linux/library/l-sugar-olpc/index.html
http://downloads.egenix.com/python/LSM2005-Developing-Unicode-aware-applications-in-Python.pdf
http://wiki.laptop.org/go/DCON

This page however looks incomplete : turning the backlight back is
impossible with the current instructions:
-bash-3.2# cat /sys/class/backlight/dcon-bl/power
0
-bash-3.2# echo 1> /sys/class/backlight/dcon-bl/power
-bash-3.2# cat /sys/class/backlight/dcon-bl/power
0

I guess I will have to look for more information since the sugar gui
does it just fine.

Regarding the underlying gnu/linux system, to explore how it all works
together, my preferred method actually is ssh and console mode.

To do that, type alt+m to get a terminal, then passwd root and passwd
olpc to setup passwords for remote access.  This also let you use the
console on ctrl-alt-F1 (magnifier) or with chvt 1

Currently I am exploring a little more the fedora distribution, the
hardware support, and I am doing some benchmarking, especially for
power management stuff.

Last night I found that closing the screen turns off networking, while
keeping the mesh network (as specified), but does that until the
battery is fully depleted. Wow.

I wonder if a graceful suspend when there is say only 50% of battery
power left wouldn't be nicer to the users. Else, kids who come to the
same conclusion may prefer to fully turn off the laptop to have some
power left to read books/play games/whatever in the bus after school
etc. There should be a good equilibrium between the user own interest
(having some power left) and the community interest (keeping the mesh
network up)

Also I noticed SHM support has been compiled in, but /dev/shm in not
used. Is it by design? I couldn't find references on the wiki.

/var /tmp and similar files could certainly live there to save some
nand write cycles. Did that on the zaurus : you simply keep a tarball
of a clean /var in / (say /.var.tar) which you untar as soon as the
shm has been mounted. Before the shm is mounted, you keep a skeleton
/dev/shm/var so that  /var symlink is not broken and application which
may depend on the existance of the directories won't be confused.

Guylhem