Re: html5 codecs on 1.75

[Benjamin M. Schwartz]

On 02/02/2012 05:10 PM, Peter Robinson wrote:
> On Thu, Feb 2, 2012 at 8:05 PM, Sameer Verma  wrote:
>> Is this something missing on the Firefox end?
> 
> No, html5 video support was added in Firefox 4. I think you'll find it
> has firefox 3.6.x

This is not true.  Firefox has supported HTML5  (with Ogg Theora)
since version 3.5.  WebM support was introduced in 4.0.

--Ben



signature.asc
Description: OpenPGP digital signature
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: optimal font rendering settings for XO display

[Benjamin M. Schwartz]

On 01/25/2012 07:59 PM, Sridhar Dhanapalan wrote:
> What are the optimal font rendering settings for the XO's display?

Not sure about optimal, but on a clean build the defaults are:

Fonts are "Sans" and "Sans bold"
201 dpi
Smoothing = Grayscale
Hinting = Slight

I suspect these defaults are also the optimum.

> Should I set subpixel smoothing and hinting?

No.  Subpixel smoothing will only reduce quality when used on an XO
laptop.  Subpixel smoothing relies on the particular geometry of a
standard laptop display, and does not work on OLPC's Pixel Qi displays.

--Ben



signature.asc
Description: OpenPGP digital signature
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: XULRunner Version 1.9 Issue Reading Local Files With No Internet Connectivity

[Benjamin M. Schwartz]

On 01/11/2012 04:37 PM, anth...@evolutionindesignz.com wrote:
> With the OLPC laptop disconnected from the Internet, I try to startup 
> XULRunner and read local files using the browser tag like this:
>   http://localhost/myfile.html"; 
> autoscroll="true" flex="1"/>
> 
> With XULRunner 1.9, the screen remains blank, and the file is not 
> loaded.
> I installed XULRunner 8.0 on the OLPC laptop. I am not able to 
> replicate the problem with XULRunner version 8.0

Your diagnosis cannot possibly be correct.  There is no reason that the
version of Xulrunner should have any effect on this.  It is much more
likely that something else changed between your two tests.

You should stick with the installed version of Xulrunner and figure out
what the true bug is.

--Ben



signature.asc
Description: OpenPGP digital signature
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: OLPC Policies Question Concerning Upgrading Default Installed Software

[Benjamin M. Schwartz]

On 01/11/2012 05:21 PM, anth...@evolutionindesignz.com wrote:
> it is presumed that replacing XULRunner 
> 1.9.1.9 should not cause problems in browser functionaltiy.

That's an extremely dangerous thing to presume.  I "presume" that you're
actually going to test the browser extensively after performing the
upgrade to ensure that the upgrade doesn't break the browser.

> Are there 
> any other dependencies that we should concern ourselves with(assuming 
> that it is not against OLPC policies to perform the upgrade)?

The other activities that use Xulrunner (e.g. Wikipedia) are all very
similar to Browse, so the upgrade is unlikely to cause problems in one but
not another.

As for dependencies of the browser, you should check that you have not
caused a regression in plugin support, especially as relates to the Totem
and Gnash plugins.

--Ben



signature.asc
Description: OpenPGP digital signature
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: XO-3 Announcement?

[Benjamin M. Schwartz]

On 01/10/2012 06:28 PM, Richard A. Smith wrote:
> In case you missed my previous comment on 1.75 on devel@ the maximum 
> runtime power draw of the 1.75 is 5W. (Not including the extra 5W you 
> can draw from the USB port.)
...
> One difference between the XO-1.75 and XO-3 is that the XO-3 can _also_ 
> be powered by USB On-The-Go (OTG).

Cool.  This will allow some slightly insane but also possibly useful power
chaining.  For example, it might be a reasonable backup for when a child's
power brick breaks.

Obviously chains longer than 2 are an iffy proposition ... but might be
worth testing just to make sure they don't crash and/or burn.

--Ben



signature.asc
Description: OpenPGP digital signature
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Marvell 88W8388 and 802.11s

[Benjamin M. Schwartz]

On 09/12/2011 06:01 PM, Spencer Johnson wrote:
> How can one implement 802.11s into a wireless adapter? 

In software ("firmware") on the CPU.

http://wiki.laptop.org/go/88W8388#CPU

--Ben



signature.asc
Description: OpenPGP digital signature
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Sugar and GTK updates

[Benjamin M. Schwartz]

On 08/16/2011 11:49 AM, Kevin Gordon wrote:
> My concern is that feature creep, and with concurrent support dependency
> increases, it could make the footprint and hardware requirements so large
> on an XO-1, that it becomes untenable.
> 
> Has there been discussion as to when the development cycle might stop for
> the older XO-1's, (perhaps strawmanning in as F14 with .94), so that this
> innovation and progress can continue on the more modern platforms?

This is a reasonable concern.  I am just watching from the sidelines, but
I can tell you:

1.  IMHO builds running on XO-1 already have the flavor of "backports",
with XO-1.5 being the primary development target.  I don't think anyone is
delaying Sugar development due to XO-1 constraints.

2.  The system requirements (especially disk space) are affected more by
changes in Fedora than changes in Sugar.  A large amount of disk space is
taken up by files whose presence is unnecessary.  Customizing the build to
exclude these files takes significant human effort to execute and test
(see http://dev.laptop.org/ticket/4281), especially if the tradeoff is
different for XO-1 vs. XO-1.5.

3.  XO-1 support is likely to be dropped when deployments indicate that
they have lost any interest in upgrading them.

--Ben



signature.asc
Description: OpenPGP digital signature
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [Server-devel] [Sugar-devel] copy files to/from server

[Benjamin M. Schwartz]

On 05/17/2011 03:42 AM, Sridhar Dhanapalan wrote:
> How can XOs copy files to/from their Journal with a server?

The simplest solution is probably HTTP.  Set up a little local website
with an upload/download form.  Moodle, or even a generic CMS like Drupal
or Wordpress, would work, but the very simplest option is probably
something like

http://www.net2ftp.com/

combined with an FTP server on the same host (and configured for automatic
login on the local network).

--Ben



signature.asc
Description: OpenPGP digital signature
___
Server-devel mailing list
server-de...@lists.laptop.org
http://lists.laptop.org/listinfo/server-devel

Re: WebM format for Record

[Benjamin M. Schwartz]

On 04/09/2011 02:00 PM, Daniel Drake wrote:
> Ben, what are your thoughts on Theora vs WebM for Record? You
> mentioned at one point that Theora developers were considering
> focusing on the low-power arena (being displaced by WebM on the
> high-power high-res front), is that direction being taken?

Essentially, yes.  The WebM encoder (libvpx) has always been much slower
than libtheora because VP8 is much more computationally intensive than
Theora.  The libtheora devs have been working to expand this difference by
adding encoder speed optimizations.

The latest versions of libtheora (1.2 alphas, and maybe even more in SVN
head) contain a lot of work to speed up encoding.  I have recommended
several times that OLPC ship 1.2-prerelease libtheora in the default
build, due to the significant speed improvements.

> So encoding speed is quite a big deal

Indeed.  I don't see WebM as being a realistic option for Record until
OLPC gets WebM encoders in silicon, which will presumably be after XO-3.

--Ben



signature.asc
Description: OpenPGP digital signature
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Record activity performance

[Benjamin M. Schwartz]

Just so everyone knows, there have recently been major speedups in the
Theora encoder (libtheora), which is a bottleneck for Record performance.
 These speedups are available in version 1.2-alpha1, which (despite the
name) is the recommended version for all but the most conservative
applications.  It has zero known bugs and is ABI-compatible with all
preceding versions.

http://downloads.xiph.org/releases/theora/libtheora-1.2.0alpha1.tar.gz

I don't know how to get new versions of things into OLPC builds, but if
people are interested in Record performance this is probably worthwhile.
Version 1.2alpha1 at speed-level 2 should be faster and better than what
is currently in use.

--Ben



signature.asc
Description: OpenPGP digital signature
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [Sugar-devel] customizing olpc-os-builder image

[Benjamin M. Schwartz]

On 11/02/2010 05:13 AM, javed khan wrote:
> can anybody tell me how to accomplish  the following using olpc-os-builder
> 
> 1: install new fonts
> 2: change the keyboard layout and default language
> 3: change the boot animation

sugar-devel@ is not really the right mailing list for this question.  You
should ask on devel@lists.laptop.org (cc'd).  The people on that list are
more likely to know about olpc-os-builder.

I don't know anything about olpc-os-builder, but just by searching
wiki.laptop.org I found

http://wiki.laptop.org/go/Fonts#Installing_fonts
http://wiki.laptop.org/go/Tweaking_the_boot_animation
http://wiki.laptop.org/go/Customizing_NAND_images#Language




signature.asc
Description: OpenPGP digital signature
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Edit/audit wikipedia activity

[Benjamin M. Schwartz]

On 10/21/2010 12:06 PM, Martin Langhoff wrote:
> Unfortunately, there is a clear need to organise a facility to
> audit/edit the wikipedia snapshots we have and "repack" the archive.
> 
> Do we have any easy way to do this?

I'm the wrong person to answer this question, but the activity's archive
production system does already have support for an article blacklist (and
indeed many articles were excluded from the current bundles).  I don't
know who is in possession of this list, or exactly who took responsibility
for producing the most recent version.  Nonetheless, excluding articles is
"easy".

Actually editing article text is not something we have attempted AFAIK.
Ideally, I think, we would fix textual problems upstream as they are
discovered.  The most recent available snapshots for English and Spanish
are 10-14 days old, so this strategy does create a delay, during which
time things can continue to change.

In general, I believe that auditing wikipedia is a fool's errand.  There
are 3.5 million articles in English Wikipedia, growing by over a thousand
a day.   Spanish wikipedia has >650,000 articles.  If people want to
create snapshots containing only whitelisted articles, that's fine, but
many of the links will be broken and the amount of information will be
much reduced.

--Ben



signature.asc
Description: OpenPGP digital signature
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: SD/MMC cards, a year later

[Benjamin M. Schwartz]

On 08/18/2010 11:24 PM, John Watlington wrote:
> Nonetheless, we are going to try testing it with UbiFS and
> considering whether any durability improvement justify the
> increased price (now up to 2x) and built-in obsolescence of
> using raw NAND chips.

If it hits 2x in price, I guess you might be able to start benchmarking
against RAID-1 of two MicroSD cards.  RAID-1 gets you reliability,
repairability, and a 2x boost in read bandwidth.  I suppose that's only a
consideration if the Armada can support 2 (or 3!) SD controllers.

--Ben



signature.asc
Description: OpenPGP digital signature
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: XO 1.75 screen

[Benjamin M. Schwartz]

On 08/02/2010 08:54 AM, Bert Freudenberg wrote:
> Please, if at all possible, stay with a 4:3 ratio. It's easy to scale 
> content, but to redesign it for 16:9 is hard even for professionals (*).

For wide screens we'll probably want to follow Ubuntu Unity and put our
menu bar on the short edge.  Since the menu bar typically occupies the
long edge on 4:3 screens, the activity's real content area would then
experience a smaller difference in aspect ratio.

--Ben



signature.asc
Description: OpenPGP digital signature
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Activity packaging

[Benjamin M. Schwartz]

On 07/06/2010 11:51 AM, Bernie Innocenti wrote:
> Ok, I think the requirements for activity bundles could be:
> 
> 1) Support multiple CPU architectures
> 
> 2) Support multiple distros (and different versions of same distro)
> 
> 3) Centralized build cluster (submit one source package, get multiple
>binary packages)
> 
> 4) Support inter-bundle dependencies
>(e.g.: GCompris + voices, OOo4Kids + dictionaries)
> 
> 5) Support activity <-> OS dependencies (e.g.: espeak for Speak,
>squeak for etoys...)
> 
> 6) Work with any programming language (setup.py is python-centric)
> 
> 7) Easy to learn for activity writers without too much distro-hacking
> experience
> 
> 
> These requirements would fit well both rpm and deb, with OpenSUSE Build
> Service or their native build clusters.

I think you are missing an important requirement: installation without
elevated permissions.

--Ben

P.S. This cross-posting is getting ridiculous.



signature.asc
Description: OpenPGP digital signature
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: #10045 HIGH 1.5-sof: XO-1.5 Record audio/video are out of sync with each other

[Benjamin M. Schwartz]

On 05/13/2010 03:26 AM, James Cameron wrote:
> We discussed this briefly in team meeting this morning ... Record is
> writing an uncompressed stream to SD, before then compressing it in the
> "Save" step once the video recording is stopped.  (I could be wrong).
> 
> This means that no matter what the size of the buffer memory, if the
> data rate from the camera exceeds the rate at which we can write to SD,
> there will be skips once a recording is long enough to fill the buffer.
...
> So we determine the data rate by choosing height, width, and frame rate
> from the camera.  We determine the maximum rate according to the choice
> of SD media.

If I understand correctly, Record does compress the video on the fly.
It's the audio that it writes uncompressed to disk for later compression
and muxing.  I don't know at what quality it performs audio recording, but
it might be as low as 32 KB/s uncompressed.

--Ben




signature.asc
Description: OpenPGP digital signature
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Net died

[Benjamin M. Schwartz]

I have a XO-1.5 (C2 I think).  I logged out of my ssh account, closed  
it up, took it to the airport, turned it on, and it wouldn't find a  
wifi network.  Linux didn't see a network interface, or even try to  
load libertas.  OFW's wlan test fails because it doesn't find the card.

Maybe the card came unseated? Maybe this is a since-resolved  
manufacturing problem? My screwdriver is six time zones away, so I  
can't diagnose further right now.

--Ben

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

Re: The All-Singing, All-Dancing XCompMGR

[Benjamin M. Schwartz]

On Thu, 29 Apr 2010, Chris Ball wrote:
>> It also increased the speed of switching between windows.
>
> Agreed, and this seems like the strongest reason in favor of shipping
> it

Before you do, please verify that there hasn't been a regression in  
functionality.

1. Visibility
X Compositing makes it difficult for programs to work out whether they  
are visible to the user, and actions that rely on that information may  
not work.  I know that I have written several activities that use  
visibility to disable display functionality, in order to conserve CPU.  
  Sugar also checkpoints each activity on task-switch.  If xcompmgr is  
interfering with that switch detection, that could create a big  
speedup, at a cost in reliability.

2. Video
You'll at least have to test video playback, which was one of the  
sticking points with compositing on the XO-1.

3. VRAM
On the XO-1, there were concerns that compositing could run the  
machine out of video memory if many windows were open, leading to all  
sorts of issues.  That might still be an issue on XO-1.5, especially  
at 32bpp.  XO-1.5 is also far from immune to OOM issues, so memory  
pressure in general is a concern.

--Ben

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

Re: New keyboard layouts

[Benjamin M. Schwartz]

On Wed, 28 Apr 2010, Paul Fox wrote:

> part of the impetus for this keyboard is that it be more "normal", for
> use by older students, perhaps in non-sugar environments.

Sure.  I'm actually arguing that Ins and Del are no longer normal, and  
mainstream computers far more popular than the XO often don't have them.

>  > Getting rid of those keys frees up valuable space that can be used,
>  > for example to move += to the top row, replaced by ?, replaced by
>  > up-arrow.  No more hjkl.
>
> i'd far rather have as much of the punctuation in their correct places
> as possible.

I suggested this change in particular because it puts += much closer  
to its standard location.  Careful about "correct" though.  A few  
minutes on a UK keyboard may remind you that even countries with the  
same language have widely varying common layouts.

> if you watch /dev/input/eventN, where N is the right device for
> the keyboard, you'll get a KEY_FN code for the Fn key.  and if
> you use it to modify F1, you'll get KEY_FN_F1 instead of KEY_F1.

Interesting.  I don't know much about keyboard handling in X.  Maybe  
we were just mistaken, or maybe the problem is at the X layer.

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

Re: New keyboard layouts

[Benjamin M. Schwartz]

On Wed, 28 Apr 2010, 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.

> We debated this one. A shorter shift key would be difficult to type
> on. We opted to emulate the hjkl vi arrangement.

Keyboard layout is virtually the ultimate bikeshed painting problem  
... but here's my opinion anyway.

Ins and Del are Harmful.  You probably know Ins because when you  
accidentally bump it, your editor switches into "overwrite" mode, and  
every character you type deletes another until you figure out what  
happened and hit Ins again.  "Del" is the reverse erase that nobody  
wants.  Apple, and the XO-1, have eliminated Ins and relegated Del to  
Fn+Erase.  I recommend removing both.

Getting rid of those keys frees up valuable space that can be used,  
for example to move += to the top row, replaced by ?, replaced by  
up-arrow.  No more hjkl.

Some other notes:

1. fn is a bad key because software can't reuse it.  For example, on  
the XO-1 we tried to make fn+F1 send an F1 press to the activity  
(instead of going to the mesh view), but it was not possible because  
the fn key is treated specially by the keyboard microcontroller, and  
not forwarded to the OS.  There was no way to tell from software  
whether a user had pressed fn+F1 or just F1.

Accordingly, on new keyboards, OLPC should consider pushing this  
special handling into the software keyboard mapping as much as  
possible.  It's hard to see why fn+Spacebar needs to be a new keycode,  
and not just a series of standard up/down events.  The only tricky  
spot I can think of is PageUp/PageDown/Home/End.

2. We have a lot of redundant modifier keys.  fn, altgr, and hand-key  
could all be a single key, because they are never used together.  If  
the keyboard controller would turn altgr+left into Home (etc.), there  
should be no regression of functionality, even under windows.

--Ben

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

Re: [Sugar-devel] stopwatch activity

[Benjamin M. Schwartz]

On Tue, 27 Apr 2010, Sameer Verma wrote:

> I noticed something interesting with he stopwatch activity on the XO
> 1.5 C2 with build 120. When the XO goes into suspend, the clock stops
> display, but upon resume, will show actual time elapsed (clock keep
> counting).  "Mark" also works correctly, displaying the time when the
> "Mark" button is clicked, irrespective of the display.  I'm not sure
> what the behavior should be, though.

I think that's fine behavior.  Most stopwatches don't stop running by  
themselves, so I don't see why ours should.

> Should the activity prevent suspend?

My philosophy is that suspend should be _absolutely transparent_ to  
the user; i.e. its effects should not be detectable, in the same way  
that processor voltage scaling is undetectable.

This suggests that Stopwatch should inhibit suspend while it is  
visible onscreen.  I'm reluctant to do this, though, because it feels  
like an ugly hack.  The right solution would be for the suspend system  
to recognize that Stopwatch has a timer set to expire in 100 ms, and  
postpone suspend.

--Ben

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

Re: Adobe Flash 10.1 + AIR 2.0 on the XO

[Benjamin M. Schwartz]

I hate to reply twice, but

John Watlington wrote:
>  it has never been tested in court

This is a non sequitur.  A codec cannot be proved patent-free in a court.
 It can only be proved that some particular patent does not apply.  If
this is your standard, then buying licenses doesn't help, because a court
cannot prove that some other unknown company doesn't hold an applicable
patent.

> This becomes a real problem when we start asking hardware
> vendors to provide firmware supporting these "free" codecs.

If a vendor is too paranoid to provide firmware, then we can write our
own.  They just need to provide docs, or partial firmware source code,
under an NDA if necessary.  Documentation does not expose them to any
patent liability.

--Ben



signature.asc
Description: OpenPGP digital signature
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Adobe Flash 10.1 + AIR 2.0 on the XO

[Benjamin M. Schwartz]

John Watlington wrote:
> EVERY codec need licenses.   I know that the FOSS community
> thinks that Theora is unencumbered, but it has never been tested
> in court (there hasn't ever been anybody worth suing using it.)

Google, Opera, and Mozilla have all funded work on Theora and are
distributing implementations of it.  Over a hundred million copies.  All
three have performed internal legal analyses.  All three have concluded
that it is not a patent risk, and can be distributed royalty-free.
Really.  Theora and Vorbis are clear according to these three.

Other distributors include Red Hat, Novell, Canonical, and every other
Linux distributor.  Major video games like Ghostbusters and Chronicles of
Riddick use Theora and Vorbis.  So "there hasn't ever been anybody worth
suing" seems untrue to me.

> This becomes a real problem when we start asking hardware
> vendors to provide firmware supporting these "free" codecs.
> If they provide them, they then become a choice target for an
> infringement suit.

These codecs have been out for a decade.  No one has ever been sued.  No
one has ever been threatened with a lawsuit.  No one has ever claimed to
hold a patent that applies to any of them.

> In past jobs I've purchased codecs, and a large part of what is
> being purchased is indemnity against infringement lawsuits.

Really?  The MPEG-LA licenses explicitly contain zero indemnity.  I'm not
aware of anyone who actually provides indemnity for codec  patent
infringement.

--Ben



signature.asc
Description: OpenPGP digital signature
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Adobe Flash 10.1 + AIR 2.0 on the XO

[Benjamin M. Schwartz]

Tiago Marques wrote:
> I don't think H.264 needs licensed codecs but I'm not sure on that.

H.264 is at the top of MPEG-LA's list of codecs that require patent
licensing.  All the MPEG codecs are on the list, including MP3 and AAC.

If you don't want to buy a license, Theora and Vorbis (the Ogg codecs) are
basically the only game in town.
--Ben



signature.asc
Description: OpenPGP digital signature
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [Sugar-devel] RFC: change to XO sleep behavior

[Benjamin M. Schwartz]

Paul Fox wrote:
> now:
> in the new scheme, the idle sequence has changed:  after a
> fairly brief period of inactivity, the system will suspend,
> leaving the screen on.  (the user may not even know this has
> happened.)  assuming there is still no keyboard activity, a
> little later the screen will dim, and sometime after that,
> the screen will blank.

Why will the screen blank?  Why not just deactivate the backlight?  Is the
DCON's power draw sufficiently high that blanking the screen represents
real savings?

--Ben



signature.asc
Description: OpenPGP digital signature
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: New XO-1.5 10.2.0 build 112

[Benjamin M. Schwartz]

Mikus Grinbergs wrote:
>> ... there is only one way to make the system
>> reliable, and that is to implement power saving via Cpuidle.
> 
> My concern is that it might be difficult to "tune" Cpuidle to
> distinguish between "non-essential" processing (which could tolerate
> suspending) versus background activity whose completion the user is
> nevertheless awaiting (and which should preferably avoid suspending).

As far as I know it is impossible.  Daniel Drake, I think, put tremendous
effort into fixing our userspace, so that no non-essential wakeups occur
at all.  This, I think, is the best solution.

> I use ethernet rather than wireless.  Historically, my systems have
> suspended despite an ongoing (via ethernet) data transfer -- that's why
> at home (when my XOs are plugged in to AC) I disable suspend.  I am
> doubtful whether Cpuidle would consider the small amount of CPU
> processing involved with handling ethernet packet interrupts as
> exceeding whatever "idle threshold" it has been designed to recognize.

It doesn't have an idle threshold.  If the kernel were correctly
configured, bringing up your usb ethernet connection would automatically
prevent suspend.

--Ben



signature.asc
Description: OpenPGP digital signature
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: New XO-1.5 10.2.0 build 112

[Benjamin M. Schwartz]

Paul Fox wrote:
> how exactly do we think this is supposed to work?

Not to repeat myself, but there is only one way to make the system
reliable, and that is to implement power saving via Cpuidle.  Cpuidle is
integrated with the process scheduler and kernel timers, so cpu activities
(like responding to a ping) are never indefinitely delayed by sleep.  I
cannot imagine any userspace solution that is not susceptible to race
conditions of the type you describe.

--Ben



signature.asc
Description: OpenPGP digital signature
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: surprisingly early suspend

[Benjamin M. Schwartz]

John Watlington wrote:
> I'm under the impression that our desire to stay with a stock operating
> system is one of the big remaining limitations, but could be wrong.

My impression:
Linux is capable of the desired behavior in general, via the cpuidle
framework, which chooses to transition between sleep states based on the
transition latencies, system activity, and upcoming timer events.  Cpuidle
separates policy from implementation by using pluggable backends in the
form of cpuidle drivers that handle state transitions [1].  At present,
the only cpuidle driver in the kernel is the ACPI driver
(drivers/acpi/processor_idle.c).

I do not know whether the XO's CPU deactivation, DCON, and timed wakeup
system can be, or has been, mapped into an ACPI state.  If ACPI is
insufficient to represent the XO's behavior, then a new cpuidle driver
will be required.  I expect such a driver would be accepted into the
upstream kernel.  Writing it should not be hugely difficult, but I do not
have enough experience to provide a good estimate of the amount of work
required.

--Ben

[1] http://www.mjmwired.net/kernel/Documentation/cpuidle/driver.txt





signature.asc
Description: OpenPGP digital signature
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Video Chat, Video Editing and VOIP activities for Sugar

[Benjamin M. Schwartz]

Manusheel Gupta wrote:
> Dear friends,
> 
> 6 developers working at SEETA  will be spearheading the
> design and development of video chat, video editing and VOIP activities in
> Sugar starting Feb. 15.

Great!

> 1. Video Chat - Pidgin  (http://www.pidgin.im/)
> 3. VOIP activity - Shtoom (http://divmod.org/trac/wiki/ShtoomProject)

I think you'd be better off starting from Empathy
(http://live.gnome.org/Empathy), which already provides both features and
is built on the same communications platform (Telepathy) that Sugar
already uses.

> 2. Video Editor - PiTiVi  (http://www.pitivi.org/)

Yes. PiTiVi is the ideal starting point.

> Wish to have your feedback on issues, implementation strategies and external
> dependencies that we might have overlooked.

Definitely talk to the Telepathy developers (on their mailing list and
#telepathy on freenode).  They are very helpful.

--Ben



signature.asc
Description: OpenPGP digital signature
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: OLPC hardware: what if there was an SDR modem / chipset?

[Benjamin M. Schwartz]

Luke Kenneth Casson Leighton wrote:
>  if i want to write my own
> peer-to-peer 802.11 algorithms, doing an implementation e.g. of the
> Babel routing algorithm to run actually on the WIFI chip itself, can i
> do so, right now, _without_ being forced to sign a Marvell NDA?

The 88W8686 in the XO-1.5 is basically a dumb interface.  There isn't
really a WIFI "chip" that can run anything.  This means that yes, you
_can_ implement Babel as a first-class mesh implementation on the XO-1.5,
just by running it on the CPU.  This is unlike the XO-1, which used the
88W8388's built-in ARM core to handle mesh routing without waking up the CPU.

The ostensible disadvantage of mesh routing on the CPU (which, btw, was
tried with Cerebro on the XO-1) is that it prevents the CPU from sleeping
to save power.  According to the OLPC product plan, the next laptop is
supposed to be the XO-1.75, with an ARM CPU.  Given ARM's ability to do
fast suspend+resume, it's possible that running short tasks on the main
CPU (like forwarding one packet) would be just as efficient as running
them on some coprocessor.

So don't be discouraged from pursuing interesting routing algorithms.
Also, consider implementing them with the kernel's 802.11s stack.  802.11s
allows basically any routing algorithm as long as all nodes agree.

--Ben



signature.asc
Description: OpenPGP digital signature
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Android, OLPC, and native hosting

[Benjamin M. Schwartz]

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

We are trying to provide stepping stones.  One of those steps is the
Develop activity [1], which is a Sugar-oriented IDE for Activity
development.  Develop has been part of the Sugar plan from the very
beginning, with the first references in 2006 [2].  In my view, Develop is
by far the most important missing feature in Sugar.

I don't know much about Develop's current functionality, and I can't test
it this week.  I do think it's important that we get it working, polished,
and included by default.

--Ben

[1] http://wiki.laptop.org/go/Develop
[2] http://wiki.laptop.org/index.php?title=Old_Develop_activity&oldid=18516



signature.asc
Description: OpenPGP digital signature
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

XO-3 official

[Benjamin M. Schwartz]

http://www.forbes.com/2009/12/22/tablet-computer-negroponte-technology-cio-network-olpc.html

"It aims to make its tablet PC highly durable, all plastic, waterproof,
half the thickness of an iPhone and use less than a watt of power, despite
an 8-gigaherz processor. The price: an unprecedented $75."

Well, that's cool.

Deciphering OLPC press releases sometimes feels like I'm playing chess
with Picasso, and he keeps breaking the rules, and I can't tell whether
this is some kind of art or he's just cheating.

--Ben



signature.asc
Description: OpenPGP digital signature
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: 1.5 - gnome-packagekit?

[Benjamin M. Schwartz]

Walter Bender wrote:
> Slightly off topic, but reading between the lines, it seems there is
> something more fundamentally broken here. 5000 packages. The Apple app
> store adds that many new "apps" every week it seems. Why aren't there
> 5 million packages available instead of just 5000? 

Money.  The App Store is proprietary software.  You have to buy it, and
some of that money goes to the author.  People write apps because they
hope to make money from it.  In contrast, we are reliant on the charitable
motives of software engineers, which restricts us to some (particularly
noble!) subset.

Note that the incentive is not particularly to write _new_ software.  You
can duplicate the functionality of someone else's app and just hope to
grab a piece of the market for that function.  The incentive is also not
particularly to write useful software; it's to write software that someone
will pay for.

In terms of useful functionality provided, I suspect Fedora's repo does at
least as well as the App Store, and maybe a lot better.

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

Re: Wanted: List of Sugar activities for the XO-1.5

[Benjamin M. Schwartz]

I'd suggest Stopwatch

http://dev.laptop.org/~bemasc/StopWatchActivity-3.xo

--Ben



signature.asc
Description: OpenPGP digital signature
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Wanted: List of Sugar activities for the XO-1.5

[Benjamin M. Schwartz]

Samuel Klein wrote:
>> [ADD & UNSTAR]
>> VNC Launcher

Not sure what this category is for, but I feel like I need to put in a
plug for Watch Me [1].  VNC Launcher lets an XO copy its screen to a
non-Sugar client with VNC software.  Watch Me, wraps this process into a
pure Sugar form, so that XOs running Sugar can share their screens with
each other.

[1] http://activities.sugarlabs.org/sugar/addon/4205



signature.asc
Description: OpenPGP digital signature
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Camera saturation - image compression level

[Benjamin M. Schwartz]

Bastien wrote:
> - shots of the moon are often saturated: how to reduce the gain
>   of the camera?  Ideally one would like to do this manually...

I never figured out how to control the gain from software.

> - is there a way to take pictures with a higher resolution?  the 
>   default compression level doesn't produce great pictures.

Yes, sort of.  Last year I figured out a way to capture and reconstruct
the raw data from the camera using a higher quality demosaicing algorithm.
 The process is documented here:

http://lists.laptop.org/pipermail/devel/2008-February/011029.html

--Ben



signature.asc
Description: OpenPGP digital signature
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Importing images in Write documents makes file huge

[Benjamin M. Schwartz]

Philipp Kocher wrote:
> Is it possible to install an libabiword-olpc rpm of version 2.7.6 or newer?

Note that this represents a "flag day" change.  Users with version below
and above will not be able to collaborate, at least when trying to share
documents containing jpeg images.

--Ben



signature.asc
Description: OpenPGP digital signature
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: XO-1.5 slow disk writes

[Benjamin M. Schwartz]

Daniel Drake wrote:
> Today I tried to figure out why running "sync" often takes 5-10 seconds
> or longer. This slows down suspend, where all data is synced to disk.

On the XO-1, it was necessary to sync before suspend, because there was no
guarantee that a suspended laptop would reawaken any time soon.  On 1.5
(and even on XO-1 with newer software) we should have fully working timed
wakeups.  That means the kernel could set a policy of a "sync every 5
minutes", and wake up out of suspend in order to perform the sync.  This
is, IMHO, actually better than a "sync on every suspend" policy, because
it enables things like write combining that improve performance and reduce
flash wear.

Of course, getting sync to be very fast would also be nice.

--Ben



signature.asc
Description: OpenPGP digital signature
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Video decode and ARM in the XO-1.75

[Benjamin M. Schwartz]

If OLPC engineers will soon be selecting an ARM SoC for 1.75, one
criterion might be video playback performance, and possibly even playback
performance in Theora, given the hassles so far with MPEG-4.

If so, the two following pages may be of interest:
http://wss.co.uk/pinknoise/theorarm/
http://www.schleef.org/blog/2009/11/11/theora-on-ti-c64x-dsp-and-omap3/

According to these pages,
(1) A contemporary ARM Cortex A8 such as the one in the Beagle Board can
decode DVD-resolution Theora in real time in pure software.
(2) If XVideo or similar basic overlay acceleration is available, then the
CPU can decode 1280x720 "HD" video at 24 fps (i.e. 720p movie playback)
(3) If the chipset includes a TI C64x+, that chip can decode Theora at
640x360 at 24 fps, independent of the CPU.

These two software projects are in early development at the moment, but I
expect them to be stable, usable, and maybe slightly faster by next year.

Other things to consider are power usage during video playback (does the
DSP help?) and video-conferencing, which requires simultaneous encode and
decode.

--Ben



signature.asc
Description: OpenPGP digital signature
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [Sugar-devel] On Sugar 0.84 - status of the "Chat/collab leader" issue...

[Benjamin M. Schwartz]

Martin Langhoff wrote:
> On Tue, Nov 3, 2009 at 9:54 PM, David Van Assche  wrote:
>> moving to mission control 5 and letting go of the admittedly
>> antiquated sugar presence now
...
> If you play with a major component replacement
> 
>  - test it for scalability & stability over wifi before doing a lot of
> integration work

It's worth noting that moving from the Sugar Presence Service to Mission
Control 5 would not alter our network protocols.  This is purely a change
in how the client software is organized.  Neither regression nor
improvement in wireless network performance should occur.

--Ben



signature.asc
Description: OpenPGP digital signature
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [Sugar-devel] Terminal.xo patch: do not die if the cwd is gone

[Benjamin M. Schwartz]

Martin Langhoff wrote:
> use GNU Screen! :-) -- now that would be something: GNU Screen
> integrated with xterm.

Not to toot my own horn, but

GNU Screen + OpenSSH + Terminal.xo = ShareTerm :

http://lists.sugarlabs.org/archive/sugar-devel/2009-May/014165.html

Doesn't help you with persistence, though, unless you really want to leave
Screen running forever.

--Ben



signature.asc
Description: OpenPGP digital signature
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

XO-2 canceled, replaced by XO-1.75 and XO-3.0

[Benjamin M. Schwartz]

The ever entertaining Prof. Negroponte surpasses all expectations in his
latest performance:

http://www.xconomy.com/boston/2009/11/02/negroponte-outlines-the-future-of-olpc-hints-at-paperlike-design-for-third-generation-laptop/

The usual OLPCNews analysis at
http://www.olpcnews.com/people/negroponte/negroponte_xo-175_goes_arm_xo-2_is_cancelled.html

--Ben



signature.asc
Description: OpenPGP digital signature
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [Sugar-devel] On Sugar 0.84 - status of the "Chat/collab leader" issue...

[Benjamin M. Schwartz]

Martin Langhoff wrote:
> On Tue, Nov 3, 2009 at 2:41 PM, Gary C Martin  wrote:
>> Other activities that support some form of collaboration like Chat, Browse,
>> Etoys, TurtleArt, Arithmetic, Maze, Pippy, etc, etc, don't care who started
>> the activity first, or who goes away.
> 
> Are you positive about this? I don't meant to troll -- but I am seeing
> issues (with Chat for example) where if the leader goes, 3rd parties
> cannot join anymore.

That is remarkable, and worth investigating.  The Chat activity in
particular is designed to survive loss of the initiator, and has been
since the very first release.

One related issue is  http://bugs.sugarlabs.org/ticket/934 .  Once the
initiator leaves, the initiator can no longer re-join due to an issue in
the GUI.  That bug contains a patch, but it's unclear to me whether that
patch was ever applied.  Maybe Tomeu can clarify the situation.

--Ben




signature.asc
Description: OpenPGP digital signature
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: OOM conditions

[Benjamin M. Schwartz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Richard A. Smith wrote:
> Working the table at the Boston book festival I was reminded how painful the 
> OOM stuff is on a gen 1.

The OOM problem on Gen 1 is a True Kernel Bug.  The problem is that the
OOM killer just isn't working.  Almost all the time, it fails to kill
_any_ process, and instead just locks up the machine.

I believe Andres was able to connect via a serial port during one of these
events, and observed the kswapd process in an "uninterruptible sleep"
(a.k.a. "state D").  This should never happen.

There has been a significant amount of churn in the OOM system over the
past few years, and a number of bugs are known to have been created and
resolved.  To the best of my knowledge, no one has ever precisely
identified whether the XO's problem is due to one of them.

Until recently, there was no newer XO kernel with which to test.  It would
be worthwhile to observe the F11-XO1 builds' behavior at OOM, to see if
there has been an improvement.

- --Ben
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.11 (GNU/Linux)

iEYEARECAAYFAkrrwMsACgkQUJT6e6HFtqTW1gCdHsEpOD5djVFtq0k3h8z6BqvE
aC4An3Sp0c+lpwmkNBoxDNEct3z5bfe4
=/INZ
-END PGP SIGNATURE-
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Sharing files among several XO

[Benjamin M. Schwartz]

Bert Freudenberg wrote:
> The Distribute activity would be your best bet I guess. Where is it?

http://dev.laptop.org/~bemasc/Distribute-1.xo

Distribute is the barest prototype of a sharing activity, designed purely
as a proof of concept.  It is unmaintained, has essentially no user
interface, and is not available in any language other than English.  The
code is a simplified derivative of the hackish HTTP-based sharing system
from Read.

Any attempts to revive it are welcome.  This is the first time I've ever
heard of anyone even attempting to use it.

--Ben



signature.asc
Description: OpenPGP digital signature
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: tap-to-click feedback

[Benjamin M. Schwartz]

Daniel Drake wrote:
> Really I think the biggest issue is that they
> press it by accident while typing or making other motions and have no
> idea why the screen has changed significantly (they don't understand
> that it's because they clicked, or that their hand was near the pad).

Normally, Synaptics touchpads use logic that (1) ignores large-area
contact, assuming it's an accidental touch with the palm, and (2) disables
the touchpad while the keyboard is active.  If those measures are not in
place, there will be a problem regardless of tap-to-click.

I don't know where in the stack this logic lives.  If that logic is
already active, then it sounds like further measures are warranted.



signature.asc
Description: OpenPGP digital signature
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [Testing] first play with new XO 1.5 machines

[Benjamin M. Schwartz]

Martin Langhoff wrote:
> On Thu, Oct 22, 2009 at 11:51 AM, Daniel Drake  wrote:
>> 2009/10/22 Tomeu Vizoso :
>>> What would be more reliable in the under a tree use case: ad-hoc or
>>> mesh with a max of 1 hop?
>> Mesh, since everyone does their own beaconing.
> 
> That's my guess too. But the hard-to-answer question is "how much more
> reliable"? So we can answer "is it worth the big effort"?

There is only one way to find out.

Both Salut (Clique and Avahi) and 802.11 ad-hoc beaconing have complex
behavior in the face of unreliable connections.  I do not think we are
likely to be able to predict the result of their interaction.  That's why
OLPC has a testing team.



signature.asc
Description: OpenPGP digital signature
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [Testing] first play with new XO 1.5 machines

[Benjamin M. Schwartz]

Martin Langhoff wrote:
> I now realize we'd forgotten about Cerebro. If anyone is going to take
> the hard road, it may be a viable option -- did we ever have a clear
> plan of what it'd take to integrate it "fully" (where 'fully' means
> that things "just work" at least roughly to where they do on 8.2.1).

On the XO-1, the answer was "reverse-engineer the Libertas firmware,
recode Cerebro from scratch in C to run at the network layer, even when
the CPU is off, and write a new kernel driver that can interface with it".
 Now that XO-1.5 can no longer forward packets in suspend, reaching parity
is somewhat simpler.  It still requires, at a minimum, that someone
complete the abandoned Telepathy-Synapse connection-manager.

In short, it's a major engineering effort involving 802.11 and Telepathy.
 I would love for someone to take it on, but I haven't heard any noise
about it in months.



signature.asc
Description: OpenPGP digital signature
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [Testing] first play with new XO 1.5 machines

[Benjamin M. Schwartz]

Tabitha Roder wrote:
> No mesh:
> 
> Just checking this scenario I am a teacher and have just been handed 5
> XOs for my students. I am told you can have a child start writing a story
> and then have the other children join in to write together.

Yes.  This is really true, on the XO-1, right now.  On XO-1.5, it will be
different.  If you have 25 laptops instead of 5, it's different.  But for
5 XO-1's, this functionality works "out of the box".

> How does the teacher do this - in less than 100 words and not one word
> technical

0.  Users open their laptops and just wait.  If they look at the
Neighborhood View (accessible by pressing the circle button with lots of
dots on the keyboard) they should all eventually see each other on the
screen , represented by XO icons.
1. The starting user launches Write.  On the top of the screen, there is a
box labeled "Share With:".  The user selects "My Neighborhood".
2.  Other users see an icon for Write appear in the Neighborhood View, in
the colors of the person who started it.  They click it, and a Write
activity launches.  This is the shared session.
3.  The users are now editing a shared document.  They can all edit
independently (within a single document), and they can all see what each
other are writing.



signature.asc
Description: OpenPGP digital signature
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: XO-1.5 follow-on impression

[Benjamin M. Schwartz]

Mikus Grinbergs wrote:
> Was able to use the XO-1.5 (os32) at another location, connected 
> without a proxy.  

I don't quite understand this statement.  Were you connected to the XO-1.5
over the internet, using a technique like X forwarding or VNC?

> The principal user-perception experience where improvement would 
> still be welcome is video support.  Changes to the screen (e.g., 
> show/hide Frame) are not being done "smoothly".  And when viewing 
> "moving pictures", the currently scanty hardware acceleration (e.g., 
> ticket #9407) is noticeable.

In the case of a remote desktop session over the internet, video
performance is almost always limited by the network and protocol, not the
server hardware's rendering speed.



signature.asc
Description: OpenPGP digital signature
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [Sugar-devel] erasing the journal and config

[Benjamin M. Schwartz]

Sameer Verma wrote:
> So, here's my request. Can someone whip up an activity that does the 
> following:

In my view, this is not appropriate for an Activity.  Sugar Activities are
not for managing the system.  Also, as you noted, if Rainbow is active
then this is difficult or impossible, and this is deliberate.  Preventing
Activities from wiping your system is the #1 reason for Bitfrost.

> This makes me *very* curious. Shouldn't there be a way to erase the
> configuration and journal without having to reflash the whole image?

As you noted, it's trivial to do this at the Terminal.  Therefore, it is
also trivial to do it from the Sugar shell.  The obvious place for this
feature, to me, is in the Control Panel, under a label like "Erase
Everything" with appropriate warning text.

For lending libraries, a shortcut for this feature in a frame device or
under the XO-man might be appropriate.

--Ben



signature.asc
Description: OpenPGP digital signature
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: creating seperate dbus-tubes in a single instance of a shared actvity

[Benjamin M. Schwartz]

Creating multiple D-Bus tubes may or may not be a good idea in your case.
 Each D-Bus tube can support many simultaneous parallel transmissions,
because D-Bus provides a routed transport.  Every D-Bus object has an
interface and a path, which allows D-Bus objects to address each other
individually.  In this way, Gnome uses a single (local) session bus for
all your desktop D-Bus needs, and an activity can typically use a single Tube.

Within Sugar, there's not much incentive to use a single Tube with many
objects or many Tubes.  Outside of Sugar, the service type of a Tube is
used to determine which applications can connect to it, so each complete
"service" should get a single Tube, labeled with the service's well-known
name.

Eventually, this will be documented at

http://people.collabora.co.uk/~davyd/telepathy-book/

--Ben



signature.asc
Description: OpenPGP digital signature
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Faster Multicast [was Re: WatchMe-1, a VNC activity]

[Benjamin M. Schwartz]

Martin Langhoff wrote:
>  - can we use multicast frames... and get the APs speeds bumped up to
> do a "fast multicast" so as to not use up all the airtime?

This would be great... and I just realized that it might also be
tremendously beneficial for Telepathy-Salut.

Salut uses multicast for two things: presence (mDNS) and D-Bus Tubes (a
homebrew network protocol called Clique).  mDNS is a classic
multicast/broadcast system, where if you miss a packet, you just have to
wait for the next round.  Clique, however, is a "reliable multicast"
system, guaranteeing in-order delivery, etc.  In other words, Clique can
tolerate some packet loss, because it knows how to request retransmission.

My understanding is that APs use the basic rate for multicast because they
presume it is an unreliable transport, and the basic rate is the least
likely to drop a packet.  However, for Clique, it might actually be more
effective to use the highest available rate, even if it causes occasional
retransmissions due to loss.

I don't know how to test this, but I think there's a chance it could be a
big win.  Of course, in situations where the mDNS presence information
itself is overloading the network, there's not much we can do.

--Ben



signature.asc
Description: OpenPGP digital signature
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Disk layout for XO-1.5

[Benjamin M. Schwartz]

Richard A. Smith wrote:
> In the end we chose to use microSDHC cards.

For MP, will they be soldered down or on contacts?

I like this; I think it creates the potential for all sorts of interesting
hackery and upgrades.

--Ben




signature.asc
Description: OpenPGP digital signature
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Disk layout for XO-1.5

[Benjamin M. Schwartz]

Martin Langhoff wrote:
>> I would urge...
> 
> ...you are preaching to the ultra-converted, to the frustrated. I
> wasn't personally involved, but I know at least Wad & Mitch looked
> quite deep into this, and found no good offers. There is good evidence
> to trust them in hardware and low level firmware matters :-)

Indeed; I didn't mean to suggest otherwise.  If they have written off the
possibility of open disk controller firmware, I am sure they have made the
right decision.

--Ben



signature.asc
Description: OpenPGP digital signature
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Disk layout for XO-1.5

[Benjamin M. Schwartz]

Martin Langhoff wrote:
> On Wed, Aug 5, 2009 at 11:52 PM, Albert Cahalan wrote:
>> BTW, note that the flash disk itself is not certain to be
>> fail-safe in the face of powerloss. Neither the firmware
> 
> Sure. In practice it seems to be extremely safe, as wedged NAND is one
> thing we haven't seen in the field (or on our dev machines). And jffs2
> is designed to survive unclean shutdowns.

The XO-1.5 will not be using raw NAND, nor will it be running jffs2.
There will be a microcontroller (running uneditable proprietary firmware)
emulating a block device.  Firmware of this type is sometimes done well,
and sometimes done poorly, as regards atomicity.

I would urge OLPC to search for a device whose controller firmware can be
modified, but I suspect OLPC has already written off that possibility.

--Ben



signature.asc
Description: OpenPGP digital signature
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Disk layout for XO-1.5

[Benjamin M. Schwartz]

Mitch Bradley wrote:
> The filesystem is no longer internally compressed.  The current size for 
> the XO-1.5 system is 1.1 GB.

Interesting.

Build 767 had an ext3 version:
http://download.laptop.org/xo-1/os/official/767/ext3/xo-1-olpc-stream-8.2-build-767-20081001_1633-devel_ext3-tree.tar.bz2

Uncompressed, the tarball weighs 524 MB, less than half 1.1 GB.

"Every meg is precious, every meg is good."

--Ben



signature.asc
Description: OpenPGP digital signature
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [Techteam] XO-1.5 Kernel Update (i.e My Weekly Status)

[Benjamin M. Schwartz]

Paul Fox wrote:
> perhaps this should be obvious, but can it handle S-states as
> well?  because i believe that's the goal -- freeze the display
> and then go into S3.

I just stumbled across the Design Scenarios for Linux's Power Management
Quality of Service system, courtesy of Intel. [1]  Notable inclusion:

"""
# Platform Suspend
* you can put the system into S3 or S4, as a function of acceptable
wake up latency
* you can specify the delay in dropping into a suspend state as an
idle time out
"""

I don't know exactly what this means, if anything, but it sounds good.

[1] http://www.lesswatts.org/projects/power-qos/design-scenarios.php



signature.asc
Description: OpenPGP digital signature
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [Techteam] XO-1.5 Kernel Update (i.e My Weekly Status)

[Benjamin M. Schwartz]

John Watlington wrote:
> We have often discussed the need for an audio DCON.
> It wouldn't take much -- the amount of memory required
> for a second of playback/record could be included in
> the codec.
> 
> wad

My impression is that the codec does DMA to memory for recording and
playback.  If DMA works during CPU suspend, then it seems like playback
should "just work".  In fact, if the buffer's big enough, the interrupts
issued by the codec should be able to wake the CPU up in time to
refill/empty the buffer without a glitch.

The power domain charts for XO-1 and XO-1.5 don't quite tell me whether
the codec, amplifiers, northbridge, and southbridge are enough powered in
suspend for this to work.  I imagine not, though, so audio playback will
probably have to inhibit suspend in XO-1.5.  I do not think this will be
difficult to implement in software.

--Ben



signature.asc
Description: OpenPGP digital signature
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [Techteam] XO-1.5 Kernel Update (i.e My Weekly Status)

[Benjamin M. Schwartz]

Benjamin M. Schwartz wrote:
> Audio playback and recording don't use userspace timers, but they do
> generate a lot of interrupts.  If cpuidle does something even marginally
> sane with interrupt history, it should not go into a high-latency sleep
> state during sound playback or recording.  If it does, audio will skip,
> but the CPU will be woken up by every interrupt delivered from the sound
> card.  (It occurs to me that this probably should've happened for the XO-1
> too, but it didn't.  Maybe the EC is not handling those interrupts properly?)

On second thought, the Geode's audio codec was probably powered off along
with the CPU.  I imagine there's a way to use the kernel's Power
Management QoS to prevent this from happening, but I don't know the details.

--Ben



signature.asc
Description: OpenPGP digital signature
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [Techteam] XO-1.5 Kernel Update (i.e My Weekly Status)

[Benjamin M. Schwartz]

Chris Ball wrote:
> Hi,
> 
>> perhaps this should be obvious, but can it handle S-states as
>> well?  because i believe that's the goal -- freeze the display
>> and then go into S3.
> 
> Looks like no.

Oh? From looking at the code?  Do you mean that it can't, or that it
doesn't now?

>  We could invent a C-state that traps to SMI and goes
> to S3 except I hate this idea already.

I think there's a good argument that S3 with the DCON freeze is very
different from the classic notion of "suspend", and so warrants its own
designation.  More importantly, though, I don't think cpuidle is limited
to ACPI states.  I think you can plug in any "state" you like, if you have
code to enter and leave it.

--Ben




signature.asc
Description: OpenPGP digital signature
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [Techteam] XO-1.5 Kernel Update (i.e My Weekly Status)

[Benjamin M. Schwartz]

Richard A. Smith wrote:
> Benjamin M. Schwartz wrote:
> 
>>
>> To handle unpredictable interrupts, cpuidle uses recent history to
>> predict
>> the frequency of future interrupts, and then chooses processor states to
>> meet an associated latency requirement.  It seems likely to me that this
>> will avoid any need for a special idleness API.
> 
> How will it do with an app like acoustic measure?

I see what you're saying.  (This program proved a problem in the past
because it would use very little CPU while playing and recording sound,
resulting in idleness detection kicking in and turning off the CPU entirely.)

Audio playback and recording don't use userspace timers, but they do
generate a lot of interrupts.  If cpuidle does something even marginally
sane with interrupt history, it should not go into a high-latency sleep
state during sound playback or recording.  If it does, audio will skip,
but the CPU will be woken up by every interrupt delivered from the sound
card.  (It occurs to me that this probably should've happened for the XO-1
too, but it didn't.  Maybe the EC is not handling those interrupts properly?)

Hopefully, this shouldn't be a problem even if cpuidle is dumb, because
drivers can specify their latency requirements explicitly using
pm_qos_add_requirement().  During recording, the sound driver should set a
low enough interrupt latency requirement so that buffer overruns do not
occur.  cpuidle will then not enter states with too high an interrupt
latency.  I believe the HDA audio driver code already does this.

--Ben



signature.asc
Description: OpenPGP digital signature
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [Techteam] XO-1.5 Kernel Update (i.e My Weekly Status)

[Benjamin M. Schwartz]

Paul Fox wrote:
> benjamin m. schwartz wrote:
>  > cpuidle is already used by the kernel to select the ACPI state, but it is
>  > possible to add more states as well.  Therefore, it seems to me that the
>  > logical thing to do is to add the "frozen" state to cpuidle's menu.
> 
> perhaps this should be obvious, but can it handle S-states as
> well?  because i believe that's the goal -- freeze the display
> and then go into S3.

My impression is that this has never been done, presumably due to the
absence of a DCON on other ACPI machines.I know nothing about kernel
internals or suspend-resume, so I cannot comment intelligently on the
difficulty of supporting S3+DCON in cpuidle.

--Ben



signature.asc
Description: OpenPGP digital signature
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [Techteam] XO-1.5 Kernel Update (i.e My Weekly Status)

[Benjamin M. Schwartz]

Richard A. Smith wrote:
> In any case time based suspend is not where we want to go anyway.  We 
> need proper idle detection and some sort of API such that apps which 
> have a workload that idle detection is difficult can specify that they 
> need idle-suspend.

I'm repeating myself (I promise I'll stop) but the method for this in
Linux is "cpuidle".[1]  cpuidle is incredibly poorly advertised, but it's
a very good system.  It maintains a list of all available CPU states,
along with the latency to enter and exit them.  Because it operates inside
the kernel, mode selection can be made with full knowledge of any upcoming
timed wakeup requests from userspace.

To handle unpredictable interrupts, cpuidle uses recent history to predict
the frequency of future interrupts, and then chooses processor states to
meet an associated latency requirement.  It seems likely to me that this
will avoid any need for a special idleness API.

cpuidle is already used by the kernel to select the ACPI state, but it is
possible to add more states as well.  Therefore, it seems to me that the
logical thing to do is to add the "frozen" state to cpuidle's menu.

--Ben

[1] http://lwn.net/Articles/221791/



signature.asc
Description: OpenPGP digital signature
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Availability of XO-1.5 ATest-2 machines

[Benjamin M. Schwartz]

da...@lang.hm wrote:
> On Mon, 20 Jul 2009, Paul Fox wrote:
> 
>> chris wrote:
>>> Hi,
>>>
>>>> my understanding from watching discussions here was that when the
>>>> system went to sleep it powered down the display, because there
>>>> was no way to set a timer to wake the system up a little later to
>>>> then turn off the display.
>>>
>>> Your understanding is incorrect, I'm afraid.  We do not power down the
>>> display going into idle-suspend.
>>>
>> but to be clear, david's right that once the laptop's in this
>> state there's no way to turn off the screen automatically later
>> on -- the system must be re-awakened with user input, and then
>> put to sleep in one of the usual (power switch or lid) ways.
>> this is simply a limitation of current s/w.
> 
> is this just a software limitation? 

Yes. You can use the rtcwake command to set wakeup timers for the future
from userspace.  However, my impression is that this is only safe if the
timer is at least 2 seconds in the future at the time of suspend, due to a
potential race with the EC.

OHM could be modified to make use of rtcwake to, for example, wake up from
sleep after 30 minutes, turn off the backlight, and suspend again.  It
simply hasn't been done.

--Ben



signature.asc
Description: OpenPGP digital signature
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Availability of XO-1.5 ATest-2 machines

[Benjamin M. Schwartz]

Paul Fox wrote:
> but to be clear, david's right that once the laptop's in this
> state there's no way to turn off the screen automatically later
> on -- the system must be re-awakened with user input, and then
> put to sleep in one of the usual (power switch or lid) ways. 
> this is simply a limitation of current s/w.

I think this is one of several good reasons why moving to cpuidle would be
big win for XO-1.5  It solves the problem of managing wakeup timers, and
does it in a perfectly abstracted fashion, requiring no alterations to
userspace.  Adding wakeup timer management to "OHM" sounds like a big
pain, and yet another maintenance burden.

--Ben



signature.asc
Description: OpenPGP digital signature
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: A1 Motherboard specs diagram

[Benjamin M. Schwartz]

NoiseEHC wrote:
>> 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). 

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.

> 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

I agree, it would be valuable to fix this bug.

> ps:
> If somebody could prove me wrong in that X is not a clusterfuck and can 
> do strectch blits then I would be happy...

The only way X could do "stretch blits" on the XO-1 hardware would be to
interpolate on the CPU.

--Ben



signature.asc
Description: OpenPGP digital signature
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: A1 Motherboard specs diagram

[Benjamin M. Schwartz]

Carlos Nazareno wrote:
> Does that mean hardware acceleration of audio codec playback?
No.
From http://en.wikipedia.org/wiki/Audio_codec
"""
In hardware, the term "audio codec" refers to a single device that encodes
analog audio as digital signals and vice versa. This is used in sound
cards that support both audio in and out, for instance.
"""

> Will there be software support for this?
> 
> Also, according to the diagram, the A1 uses a Via VX855 media system 
> processor:
> http://www.via.com.tw/en/products/chipsets/v-series/vx855/
> 
> This chip has a built in Via Chrome9 (formerly S3 graphics brand) 3D
> accelerator. Does this mean we'll now have pretty good OpenGL hardware
> acceleration on the XO? :) -- Compiz Fusion for Fedora or Ubuntu on
> the XO! ;)

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.

> Also, the Via page mentions hardware decoding of certain video codecs.
> Will we see software support for any of these? (given that these are
> proprietary video codecs)

The authors of these codecs claim they are heavily patented.  In the past,
OLPC has refused to ship such codecs due to the patent issues.  I have
heard no indication that their position is likely to change.

> This has a power consumption of 3.5W which is significantly higher
> than the AMD 0.8-1.3W of the XO-1's AMD Geode LX 700. This is why I
> was asking about battery life -- it's a concern for using the XO with
> common tasks like as a mobile e-book reader.

The CPU should not be running if you are using the XO as an ebook reader.
 Fast suspend and resume is an integral part of the hardware design,
unlike any other x86 machine.  It seems likely that battery life will
suffer relative to an XO-1 if suspend/resume is disabled, which is why
suspend/resume should not be disabled.

--Ben



signature.asc
Description: OpenPGP digital signature
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Performance hit while working with screen depth 16

[Benjamin M. Schwartz]

shivaprasad javali wrote:
> My original question still remains unanswered. Is it acceptable for my
> activity to change the screen depth to increase its performance?

Acceptable to whom?

It's probably not acceptable to the hundreds of thousands of children who
currently have XOs running Sugar, because the Rainbow system will prevent
your activity from editing xorg.conf.  In fact, because the users in
Uruguay have been denied root access, they cannot change the screen depth
at all.

On the other hand, if this is for private deployment under your control,
then it's perfectly acceptable.

--Ben



signature.asc
Description: OpenPGP digital signature
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [Sugar-devel] poor man's mmap "sliding window" on Python 2.5.x

[Benjamin M. Schwartz]

Martin Langhoff wrote:
> On Tue, Jul 7, 2009 at 2:06 AM, Benjamin M.
> Schwartz wrote:
>> Is this (a) a kernel bug, (b) Python layering extra caching over mmap, or
>> (c) a misunderstanding of mmap on my part?
> 
> money is b

huh.  I looked through python's mmap implementation [1] and there doesn't
seem to be any caching or funny business going on.

I wonder if it could be over-aggressive caching somewhere in jffs2, in an
attempt to avoid repeatedly decompressing the same block.

--Ben

[1] http://svn.python.org/projects/python/trunk/Modules/mmapmodule.c

P.S. JFFS2 appears to support read-only mmap, which I presume is what
you're using.



signature.asc
Description: OpenPGP digital signature
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [Sugar-devel] poor man's mmap "sliding window" on Python 2.5.x

[Benjamin M. Schwartz]

Martin Langhoff wrote:
> Along the way, found that Python 2.5.x doesn't support an offset to
> mmap(), which at first blush makes re-mapping with a sliding window
> problematic.

Why is an explicit sliding window necessary?  Isn't the point of mmap that
you can access as you like, and the kernel will clear old caches if
there's memory pressure?

> On the XO-1, it's the difference of "churning through it" and slowing
> the whole OS to a crawl, and then inching towards a big OOM zap.

Is this (a) a kernel bug, (b) Python layering extra caching over mmap, or
(c) a misunderstanding of mmap on my part?

--Ben



signature.asc
Description: OpenPGP digital signature
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: The XO-1.5 software plan.

[Benjamin M. Schwartz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Chris Ball wrote:
> We have some good news:  OLPC has decided to base its software release
> for the new XO-1.5 laptop on Fedora 11.  Unlike previous releases, we
> plan to use a full Fedora desktop build, booting into Sugar but giving
> users the option to switch into a standard GNOME install instead.
> (This will mostly be useful for older kids in high school.)
> 
> I'm particularly happy about this plan because it will allow us to
> catch up with the awesome work present in the Sugar community's most
> recent release, Sugar 0.84, as well as merging the latest Fedora work
> and including GNOME into the mix for the first time.  The new machines
> will have 1GB of RAM and 4GB of flash, so we have enough room for both
> environments at once.

This raises an interesting question: should we still be using a compressed
filesystem?  On the XO-1, an uncompressed FS was essentially not an
option.  There would be almost no space left for users' files after the
uncompressed system files.  Unfortunately, this causes tremendous
slowdowns all over the system, as it causes reads from flash to (a) be
CPU-limited, and (b) compete with the rest of the system for CPU time.
Writes are even worse.

On the 1.5, we will have more space (so less need for compression), but
more system files, and also more CPU to handle it.  I think we should
remember to test the final images both with and without compression.

Of course, this equation gets still more complicated depending on whether
we have MTD or FTL flash.  Choosing a filesystem will be an interesting
exercise.

- --Ben
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.11 (GNU/Linux)

iEYEARECAAYFAkoO7LkACgkQUJT6e6HFtqTH/QCfYUitcwLq8bTF2E1g+rbwyfa8
t1sAoIcQ0FXXm16GlFriJ1A2n+Bv4Fe1
=v9fu
-END PGP SIGNATURE-
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Live from SugarCamp

[Benjamin M. Schwartz]

Rodrigo Padula de Oliveira wrote:
> Hello my friends.
> 
> How can I define groups in Sugar to share things?
> 
> Can I share an activity only for a specified group of XOs ?

"Groups" are a planned feature, but they have not yet been implemented.
What is currently implemented is an "invitations" system.  You can launch
an activity, then move to the Neighborhood (or Friends) view, select a
buddy, and choose "Invite [buddy name] to [activity name]".  In this way,
the activity will only be shared with the people you invite (and the
people they invite, etc.).

Unfortunately, invitations have not been very reliable.  If they do not
work for you, I would like to hear about this.

Additionally, Martin Langhoff has been working on creating a kind of group
structure using Moodle.  In his system, users can be formed into groups
using the Moodle web interface, and then users will only see other users
in their group in the Neighborhood view.  I do not know the status of this
work.

--Ben




signature.asc
Description: OpenPGP digital signature
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [Sugar-devel] Removing the 'Erase' options from activity righ click menu

[Benjamin M. Schwartz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

nout...@paiwastoon.com.af wrote:
> After
> our first deployment here in Afghanistan, we had to reinstall a lot of
> laptops because students accidentally deleted most of their activities.

I think this is a great example of why we need to make a no-regressions
XO-1 build with 0.84.  Among its many new features, 0.84 adds direct file
transfer capability, which means that if you delete an activity, you can
easily have a friend send it to you over the network.

It is abundantly clear that OLPC is not going to do this work for us.

- --Ben
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.11 (GNU/Linux)

iEYEARECAAYFAkn+blsACgkQUJT6e6HFtqRWDQCfQP3J5gyNA8KXg3ea2wTb0Ll9
4sQAniO2WPqjD6s3UpyB23h/g0RyHQZQ
=1OXc
-END PGP SIGNATURE-
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: CL1B power distribution

[Benjamin M. Schwartz]

John Watlington wrote:
>> the LED trick has the advantage of not requiring a change to the case,
>> just a single additional drive pin to be able to run it as a detector.
> 
> And where would you place said detector LED, without modifying the  
> case ?

While we're bikeshedding this to death, I'll put in my vote for reusing
the camera activity LED.  It's well isolated from other light sources, and
it's rarely on. Whenever the camera is off, it can be used a
photodetector.  To retain the security guarantee that the light is on when
the camera is on, it might be necessary to put a diode across the camera's
power supply, so that they can be reverse-biased together.

If only we could get another hole in the case.

--Ben



signature.asc
Description: OpenPGP digital signature
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Fwd: Gnash loves the Via C7

[Benjamin M. Schwartz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Rob Savoye wrote:
>   As of the 0.8.5 release, Gnash supports both XVideo an the MIT-SHM
> extension for better performance. It's just that these newer builds
> never seem to get built for the XO, although I drop binary snapshots as
> rpms on our http://www.getgnash.org site occasionally. To enable XVideo
> support of newer Gnash builds, just add "set XVideo true" in your
> $HOME/.gnashrc file. We added both of these over the winter because of
> the benefit to XO class hardware. It's not enabled by default as it's a
> new feature.

1. Does Gnash use XVideo for YUV->RGB, or only for scaling?

2. Has the problem of mouse interaction with Gnash-XVideo been resolved?
This would be extremely helpful for Tomeu's Gnash Activity work.

- --Ben
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.10 (GNU/Linux)

iEYEARECAAYFAkn13QAACgkQUJT6e6HFtqQuWACeMIN9vIo0HWoR5ML9F5UI05/8
2cgAn0Etnqksk3PMqxgxrxO7/ci+fyNb
=CuAm
-END PGP SIGNATURE-
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Fwd: Gnash loves the Via C7

[Benjamin M. Schwartz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Rob Savoye wrote:
> Benjamin M. Schwartz wrote:
>> The XO-1 has hardware-accelerated XVideo, including YUV->RGB and scaling.
>>  Are you talking about hardware acceleration for the internal stages of
>> video decoding, a la XvMC?  Tests on a 1.0 GHz C7-M (the processor in
>> XO-1.5) indicate that software-only rendering should be fast enough to
>> play DVD-resolution video and audio.
> 
>   Sorry, I wasn't quite clear, it's the existing XO hardware that has
> problems with streaming video when done entirely via software. A 1.0Ghz
> C7 is fast enough for software rendering of streaming video, but 400Mhz
> seems to be a threshold for software rendering of networked video. Both
> the C7 settop/NetBook I have here have Unichrome support (OpenGL), which
> helps for "YouTube".

OK... but "entirely via software" is Doing It Wrong.  With XVideo accel,
the XO-1 is perfectly capable of playing back YouTube videos at full
speed.  Observed performance is only awful because Gnash isn't using
XVideo, so YUV->RGB and scaling are being done in software.  If we built a
special-purpose "YouTube plugin" using gstreamer (with the patent-problem
decoder elements...) we would have full-speed video instantly.

For more evidence try olpc.dailymotion.com.  Those videos are
Vorbis+Theora at YouTube resolutions... and they decode beautifully on the
XO-1, because they're sent through the correct pipeline.

- --Ben
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.10 (GNU/Linux)

iEYEARECAAYFAkn1154ACgkQUJT6e6HFtqT4mACgkuWrEv1En3CPXIj8slqb8SGy
IXUAn2u/+XaVLvI6PbAaXdomCrlQxJo2
=EII8
-END PGP SIGNATURE-
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Fwd: Gnash loves the Via C7

[Benjamin M. Schwartz]

Rob Savoye wrote:
>   What would be truly awesome would be OpenGLES support on the XO 1.5.
> :-) Software rendering kills streaming video performance...

I don't understand.  Could you elaborate?

The XO-1 has hardware-accelerated XVideo, including YUV->RGB and scaling.
 Are you talking about hardware acceleration for the internal stages of
video decoding, a la XvMC?  Tests on a 1.0 GHz C7-M (the processor in
XO-1.5) indicate that software-only rendering should be fast enough to
play DVD-resolution video and audio.

--Ben



signature.asc
Description: OpenPGP digital signature
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: CL1B power distribution

[Benjamin M. Schwartz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

John Watlington wrote:
> Quick straw poll on how many people think it is useful enough have  
> individual
> control over the power supplied to each connector to raise the cost  
> of the laptop
> by $0.15 ?

Turning off a single port to which nothing is connected saves no power,
right?  I don't see the appeal.  Maybe for deactivating power to passive
devices (e.g. usb sticks) during suspend, but such devices are cheap to
power anyway, and may not shut down cleanly if their power supply is
killed.  Moreover, I am persuaded by your argument that the software is
unlikely to get smart enough to use it.

Also, these "switches" are actually transistors, with some leakage current
and some effective resistance, right?  So it seems like we pay for the
flexibility of these switches with a small increase in power requirements.

- --Ben
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.10 (GNU/Linux)

iEYEARECAAYFAknz5a4ACgkQUJT6e6HFtqRgTgCdHb+0t19AEY2VaHOaVYVqC6Fs
Tr0AmwVwMtgWTTgzEPys2DpPlksdTv32
=pcyb
-END PGP SIGNATURE-
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: CL1B power distribution

[Benjamin M. Schwartz]

Richard A. Smith wrote:
>>> Ideally updates could be frequent enough to pick up a waveform
>>> from an unrectified power supply. (spare audio channel?)
> 
> Don't have much in the way of EC cycles available.  Don't have much EC 
> ram left to cache values either.
> 
> I can make the readings available via EC commands but each command takes 
> a few ms to complete and back to back commands will have a few ms of 
> delay as well.  I'm guessing you might be able to get a 20ms update rate.

That's not fast enough for much interesting signal processing, but it's
more than fast enough to do power metering.  Power metering while on
external power is something I've specifically been hoping for.

(So please consider adding this to the end of your very long EC TODO.)

--Ben



signature.asc
Description: OpenPGP digital signature
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: XO Gen 1.5

[Benjamin M. Schwartz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

John Watlington wrote:
> The enabling chipset is hot off the fab line, the VX855 [2].  This
> single chip provides ... a 3D graphics engine, an HD
> video decoder

It's worth remembering that the only existing driver that supports either
of these features is a pure binary blob.  The Openchrome drivers have no
3D support, never mind video decode support.  Even their Xv support is
glitchy.

In other words, this GPU represents a regression, compared to the Geode
LX, unless you're willing to run with (famously unreliable, unsupported)
binary-only drivers.

So don't get too excited.

- --Ben
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.10 (GNU/Linux)

iEYEARECAAYFAkns6IoACgkQUJT6e6HFtqSCTQCfacYu5ZvaF1mqPga0vwiNvvUZ
u5YAnRNSmM+0FtuaRL2TTCGhjU/Pk4ly
=5D6T
-END PGP SIGNATURE-
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Notes on service discovery XS/XO

[Benjamin M. Schwartz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Martin Langhoff wrote:
> The short of it is that mdns/dns-sd make sense for a small,
> underutilised network of peers. They assume that the network is a
> cheap resource, that broadcast messages are cheap, and that there is
> no coordinating server.

mDNS assumes all of the above things.  DNS-SD does not.  DNS-SD is
perfectly happy to work on a standard DNS server.  From the spec

"""
   This document proposes no change to the structure of DNS messages,
   and no new operation codes, response codes, resource record types,
   or any other new DNS protocol values. This document simply specifies
   a convention for how existing resource record types can be named and
   structured to facilitate service discovery.
"""
(http://files.dns-sd.org/draft-cheshire-dnsext-dns-sd.txt)

I'm not particularly knowledgeable about the XS service discovery
requirements, nor about DNS, so I can't reasonably tell you to use DNS-SD.
 What I can say is that it seems like it should be workable.

- --Ben
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.10 (GNU/Linux)

iEYEARECAAYFAknsW+UACgkQUJT6e6HFtqSx5QCglzpN+96F9aTAH05KnsQszg3E
vy4An0lCtq/z04OKiFVvv5TvXUcNnkZ5
=TRBq
-END PGP SIGNATURE-
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [BULK] Re: GPS on XO

[Benjamin M. Schwartz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hal Murray wrote:
> p...@laptop.org said:
>> i guess i'd be a lot more worried if the volume name (or whatever it
>> is that's being used as the device name) could contain a slash ('/')
>> character.  because that would no doubt render the device unmountable.
>>  someone should try that... 
> 
> It's the same problem.  Whatever works for spaces should work for slash too.  
> That may be an argument for using backslash in front of funny characters 
> rather than quotes around the string.

In fact, this is not true.  In POSIX filenames (and directory names) "/"
is the only character that is explicitly disallowed.   In contrast, " " is
a perfectly valid character in a filename.

- --Ben
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.10 (GNU/Linux)

iEYEARECAAYFAknawx4ACgkQUJT6e6HFtqR/1gCeON/fhmhS3DGB2BF1gzknQNdi
9p0An34tICd2TXoqQ0LcfhwF2ePDeRVe
=e1J1
-END PGP SIGNATURE-
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Google summer of Code?

[Benjamin M. Schwartz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Jameson Quinn wrote:
> Honestly, this is news to me. (and I am the co-administrator of the
> Sugarlabs program). If I had to articulate my view of our priorities, it
> would be something like the following:
> 
> 7-10 points: Key sugar core improvements. Long-standing, important gaps like
> versioning or unit-tests at the high end of this.

As others have pointed out many times, the SoC projects that are least
likely to produce useful results are the ones that are the most ambitious.
 In particular, it is difficult to find SoC applicants who are ready to
make deep modifications to an existing codebase, or will be able to
architect complex software.  Remember, SoC applicants are mostly current
undergrads, so most have never participated in multi-person development
effort, or written anything larger than 1000 lines.

> 0-8 points: Proposal quality.

Maybe this problem is wrapped up in "Proposal quality".  If I were
designing a system to reflect my own internal judgment structure, I would
probably add another /multiplying/ factor, the estimated probability of
success (although I hope we can do selection without resorting to
numerical scores.)

- --Ben
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkm6XnQACgkQUJT6e6HFtqSlrACgjuswY+/aYXWkfaTY3DZcls/l
gLcAnRP4Rn7tGfuQoiipzFtXQfEHP1g4
=Z92W
-END PGP SIGNATURE-
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Collaboration test environment problem

[Benjamin M. Schwartz]

James Simmons wrote:
> I have two PCs running Fedora 10 and the Sugar RPMs that come with 
> that.  One of the computers runs GNOME and the other uses Window Maker.  
> I run sugar-emulate on both.  One copy of Sugar uses the name "jim" and 
> the other uses "jsimmons".  Both use the schoolserver.media.mit.edu 
> jabber server.  Both are connected to the same router using Ethernet cables.
> 
> When I go to the neighborhood view (F1) on both I see a number of 
> "buddies".  However, while on the "jim" machine (Window Maker) I can see 
> and invite "jsimmons".  When I look at the same view on "jsimmons" 
> (GNOME) I  cannot see user "jim", although I can see other users.

Do they see the same other users?

schoolserver.media.mit.edu is using the "shared roster", so every user
should be able to see every other user.  If the asymmetric visibility that
you describe persists for more than 10 minutes, then you have found an
extremely bizarre bug.

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

Re: rotate button sucks on the XO

[Benjamin M. Schwartz]

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

Tangentially related:
Anyone who uses gstreamer for video is likely using "xvimagesink" to
display video, but IMHO this is almost always a bad idea.  If another
application is already using XV, your gstreamer pipeline will simply fail.
 Instead, use "autovideosink", which attempts to use xvimagesink, and
silently falls back to ximagesink if XV is not available.

--Ben

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

Re: getting mp3 sound working w/ Gnash easily

[Benjamin M. Schwartz]

S Page wrote:
> However, FWIW I just purchased the Fluendo MP3 decoder for $0 and 
> installation on 8.2 on my XO was pretty straightforward if you're 
> moderately familiar with the command line.  Now I can play .mp3 files in 
> Browse and Totem and _some_ Flash animations have sound in Gnash 
> ()

> If anyone gets a FOSS MP3 codec installed and working, the place to 
> document it is http://wiki.laptop.org/go/GStreamer#MP3 .

The Fluendo MP3 decoder _is_ FOSS, or at least it is as nearly Free as any
implementation of MP3 can be, given the patent problem.  The source-code
is MIT licensed.  Additionally, downloading the binary conveys a patent
license upon you, and upon anyone else to whom you distribute the binary.
 However, the binary itself is not quite Free.  For example, you cannot
distribute the binary codec linked into a GPL binary, because the patent
protections do not extend to derived works or modified forms.

Anyway, source tarball at
http://core.fluendo.com/gstreamer/src/gst-fluendo-mp3/

--Ben



signature.asc
Description: OpenPGP digital signature
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: OS/X11 support for XO-1 hardware?

[Benjamin M. Schwartz]

da...@lang.hm wrote:
>>  It would allow for much improved
>> video performance since you could play back a 320x240
>> video on the full screen at considerable CPU savings.
> 
> except that you would spend those CPU savings doing the scaling up from 
> 320x240 to the higher resolution.

Argh and double argh! You're both wrong.

1. Video playback in any sane player is already routed through XV, which
uses the GPU's video overlay scaler (and YUV->RGB converter).  The result
is that playing a 320x240 video at 1200x900 full-screen already costs zero
extra CPU cycles.  No need to mess with screen resolution.

2. The Geode LX GPU can do both output scaling and video-overlay scaling,
independently, at the same time.  On the latest drivers, we should be able
to set the screen resolution to 600x450, scaled up to 1200x900, and then
play a 320x240 video, scaled up to 480x360 (which means 960x720 physical
LCD pixels), all without using any CPU power for scaling.

There are lots of good reasons to play with screen resolution.  My
favorite reason is that reducing the resolution to 800x600 would make all
graphical operations runs twice as fast, and use half as much memory,
while introducing a negligible drop in display quality (the display,
remember, is not _really_ 1200x900 in color mode; the total number of
color elements is equivalent to 800x450).

--Ben



signature.asc
Description: OpenPGP digital signature
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [Sugar-devel] Future of Rainbow + Sugar?

[Benjamin M. Schwartz]

Martin Langhoff wrote:
> Maybe my ignorance on matters selinux is showing? ;-)

You are not alone.  Sugar/OLPC simply never had SELinux experts who
volunteered to work on Rainbow.  We still don't (raise your hand if you
consider yourself proficient at writing SELinux policy!).

It's hard to write a sandboxer like Rainbow, since it must not only appear
to work, but be verified "secure" to a high degree of confidence.  That's
harder still if one is writing in a system in which one is a novice, so
the developers (principally Michael) have instead stuck to technologies
with which they are already expert.

--Ben

P.S. The SELinux entry on Wikipedia contains the following gem: "Isolation
of processes can also be accomplished by mechanisms like virtualization;
the OLPC project, for example, sandboxes individual applications in
lightweight Vservers."



signature.asc
Description: OpenPGP digital signature
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [Sugar-devel] Future of Rainbow + Sugar?

[Benjamin M. Schwartz]

Wade Brainerd wrote:
> To me, Bitfrost was just one more lofty windmill OLPC tried to tilt because
> it seemed like an interesting challenge.  I'm not clear why Sugar needs more
> protection from rogue activities than a normal desktop environment has from
> rogue applications.
> 
> Reinventing the desktop as a constructivist learning environment is a big
> enough task for one development team / community to swallow.  Reinventing
> security is an altogether separate cause.

They are a single, indivisible cause, and also the entire reason for the
existence of Sugar.

Many operating systems provide users with a set of powerful tools for
manipulating ideas and data.  Sugar's purpose is to add another dimension:
to encourage users to modify and share the tools themselves.  To that end,
if my friend sends me a modified copy of an activity, I must be able to
run it without fear of wrecking my system.

Users naturally want to do this.  To see what happens when the operating
system doesn't support it, just look at the wave upon wave of e-mail
viruses that plagued Windows for so many years.

Without support for safe collaborative development of this sort, Sugar has
little to recommend it over XFCE and similar gtk-based iconic user
interfaces.  We are getting there, and with the latest improvements to
view-source and Rainbow, we are beginning to have the basics in place.

--Ben



signature.asc
Description: OpenPGP digital signature
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: On optimizing Theora

[Benjamin M. Schwartz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Tiago Marques wrote:
> Can you please try both options with also the following
> ones:*-ftree-vectorize -funroll-loops -m3dnow

(1) libtheora automatically adds the flags "-O3 -fforce-addr
- -fomit-frame-pointer -finline-functions -funroll-loops" to any specified
CFLAGS.

(2) libtheora's inner loops are largely hand-optimized MMX assembly, so
vectorization and 3dnow are unlikely to have a significant impact.

(3) I am not particularly interested in trolling through every combination
of relevant gcc flags in search of performance benefit.  That's the
compiler's (and compiler writers') job.  My point, instead, was that gcc
(at least the version in 767) does not have a good code generator for
Geode, and therefore we should not expect any performance increase by
rebuilding everything -march=geode.

If you are interested in searching for the perfect compiler flags, perhaps
you would like to try Acovea (http://www.coyotegulch.com/products/acovea/).

- --Ben
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkmhp7AACgkQUJT6e6HFtqRt4wCgl4CpYwb3OqlxUfwkgVvuMsk6
UcYAoJ54o4Oyhgl056lF6HQbbtf245O2
=dFCy
-END PGP SIGNATURE-
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: On optimizing Theora

[Benjamin M. Schwartz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Tomeu Vizoso wrote:
> On Fri, Feb 20, 2009 at 06:41,   wrote:
>> On Fri, Feb 20, 2009 at 12:28:42AM -0500, Benjamin M. Schwartz wrote:
>>> GCC 4.3 evidently does not do a very good job of optimizing for geode.
>> What percentage of CPU time was spent in libtheora?

100%.  The encoder was operating in a continuous loop.

> Yeah, both X and jffs2 seem to use a lot of cpu on the XO, so if they
> were involved during your tests, you may have seen little of theora
> itself.

Neither X nor jffs2 was involved.  The input file (y4m or ogv) was cached
in memory, and the output stream (ogv or y4m) was being sent directly to
/dev/null, and not displayed.

The only action being taken in X was to display, in the Terminal activity,
a text-only progress bar, rendered by the encoder_example, or dump_video
command.  These commands are part of libtheora, and were recompiled with
it, so the point remains.

- --Ben
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkmevNoACgkQUJT6e6HFtqR6tACeO1ZzMrBs/u1RZiGLqS19AJEv
RD4An26lFRgJ1sRxktsSlG18WjVQ92d7
=eIOq
-END PGP SIGNATURE-
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

On optimizing Theora

[Benjamin M. Schwartz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I have been testing libtheora-1.0 on a MP XO.  On build 767, using F9's
gcc-4.3, I compiled libtheora with CFLAGS="-march=geode".  I tested
encode, with the command

time encoder_example -v 1 coastguard_cif.y4m > /dev/null
using the test video from
http://media.xiph.org/video/derf/y4m/coastguard_qcif.y4m.  This test ran
in 44.15 +/- 0.15 seconds (all times are "user" time).

I then tested decode, with the command
time dump_video coastguard_cif1.ogv > /dev/null
using the ogg video that would be produced by the encoder above were it
not redirected to /dev/null.  This test ran in 4.60 +/- 0.05 seconds.

I then repeated these tests after recompiling with "-march=i586
- -mtune=generic", which I assume are approximately the CFLAGS used by
Fedora.  The resultant times  were 41.6 +/- 0.1 and 4.45 +/- 0.05.

In conclusion, compiling libtheora with "-march=geode" causes it to run
significantly (20 sigma, 7%) slower than "-march=i586 -mtune=generic" for
encoding, and possibly slightly slower for decoding as well.  GCC 4.3
evidently does not do a very good job of optimizing for geode.

- --Ben
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkmeP4oACgkQUJT6e6HFtqQw8wCdEhQQi0qzQNjn++HQU1uQRMXG
+aIAnA/LStzVA7pSZGMRFIWXUbeQv3oc
=wp55
-END PGP SIGNATURE-
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Unshare an Activity

[Benjamin M. Schwartz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hal Murray wrote:
>> This is the problem with your understanding.  A shared activity is
>> _initiated_ by one user, but this user does not _own_ the shared
>> activity.
>>  The user who initially shared the activity can turn off his computer,
>> and the other users can still continue to share with each other.  You
>> can see this with the Chat activity, for example. 
> 
> I'm missing a key idea.
> 
> Some activities have persistent data, say a document.  Another example would 
> be the high score database for a game.

I'm not sure what you mean by "persistent", but I believe I understand
your overall point.  Many activity implementations work internally by
designating one of the participants as a super-node or "server", and then
using that machine as a central point for maintaining canonical copies of
data and synchronizing communications.  A good example of a current
Activity written in this way is Write, in which the main copy of the
document is kept on the server, which is also the machine on which the
instance was initiated.

In the current Sugar design, an Activity like Write that behaves in this
way is considered "broken".  That is, the Sugar UI presents an abstraction
in which all nodes of an Activity are equal, and in principle sharing
continues regardless of who leaves.  This is deliberate, because that's
the desired behavior.  Sugar was designed with an eye toward sharing on a
mesh network, where all network links are unreliable, and sharing must
degrade minimally in the face of connection failures.

In the case of Write, the authors are attempting to reach this point by
writing code to elect a new super-node if the current one leaves the
shared session.  I believe that code has not yet been released.  The last
time I checked, if the initiator of a Write session left the shared
session, the remaining users would still be nominally "sharing" according
to Sugar, but no data would actually be transferred between them.

It's possible that Sugar should grow some UI to indicate if a single group
member is a keystone, and sharing will break if the connection to that
user drops.  That is, however, a fairly ugly thing to try to communicate
to a user, and given a choice we would rather make it unnecessary.

Personally, I've been working on writing a communications library called
Groupthink that ensures that all state is correctly replicated across all
activity instances.  Any Activity that can be written using Groupthink
will automatically be immune to the loss of any single member.

- --Ben
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkmaQuoACgkQUJT6e6HFtqTcjQCePlhnRJiX7uI7eeQPZTG7Ih5w
0BUAn0+f1YQNHI0yQ/PBDTPb2TX+dgjp
=Lk5L
-END PGP SIGNATURE-
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Unshare an Activity

[Benjamin M. Schwartz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Jorge Saldivar wrote:
> Thanks Bert!
> 
> 
>> But, even if you initiated the sharing, you can leave the shared activity.
>> After an activity has been shared, all participants are equal.
>>
> 
> I know that I you join a shared activity you can leave it, calling the leave
> method but what happend if i share the activity???, how can I unshare it??,
> or close the connection??, or some thing link that??.

This is the problem with your understanding.  A shared activity is
_initiated_ by one user, but this user does not _own_ the shared activity.
 The user who initially shared the activity can turn off his computer, and
the other users can still continue to share with each other.  You can see
this with the Chat activity, for example.

Sharing can only continue without the initiator if the sharing code for a
specific activity supports it.  If you are writing an activity, you must
figure out how to handle the case where the initiator leaves.  If you
cannot support continued sharing after that point, then you may wish to
notify the user that the instance is no longer shared.  However, it is
better to design your networking code so that sharing can continue.

- --Ben
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkmZ3rYACgkQUJT6e6HFtqTrxQCfRyxdcBovZMnozHecOu32jIph
28IAn0L6e3332NVba4oFJgg4/vHHdzl1
=mt9d
-END PGP SIGNATURE-
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: power consumption after shutdown

[Benjamin M. Schwartz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Mikus Grinbergs wrote:
> I take this to mean that *something* was draining some 
> power for the two days the XO was sitting in its "shut down" state.

All rechargeable batteries lose stored energy over time.  The phenomenon
is called "self-discharge".  It is sometimes modeled as a large (but not
infinite) resistance in parallel with the battery.

Just be glad the batteries aren't Li-Ion.  Those can self-discharge
totally in a month or less.

- --Ben
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkmWRtUACgkQUJT6e6HFtqRK1QCgnMJ2bhK9AXQ3/NAvlXMINRsB
aMEAn1hr7kDpxwy6LoA+UYd4EXXUyP0T
=hc5N
-END PGP SIGNATURE-
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Guidance sought on collaboration techniques

[Benjamin M. Schwartz]

James Simmons wrote:
> When I wrote collaboration into the View Slides activity I just copied 
> the code from the base Read activity so I could copy an entire slideshow 
> from one machine to another.  That didn't work all that well

No?  It would be good to know why.  Also, Telepathy now has a high-level
File Transfer API.  If you can afford to depend on the development builds
of Sugar (soon to be released as 0.84), then this might make your life
much easier regardless of which solution you choose.

> , so now I'm 
> considering something that I think is both more practical and a better 
> use of collaboration.  The idea is to have buddies that join a slideshow 
> passively view a show being navigated by the master user, sort of like 
> looking over someone's shoulder when he reads.

As has been noted elsewhere, this might one day be available to all
Activities, by having Sugar provide a view-only VNC server.  That isn't
tremendously difficult (VNC over Telepathy has already been demonstrated)
but no one's stepped up to implement it.  In fact, implementing this might
be easier than writing your own image-sharing system.

> What I have in mind is this:
...
> It occurred to me that the Chat activity must be doing something kind of 
> like this, but I haven't been able to figure out the code in that 
> Activity.

Remember that Telepathy is providing an abstraction layer over Jabber.
Chat is simply using Jabber's basic IM functionality.  I doubt you'll be
able to use Chat as a model for sharing images.

--Ben



signature.asc
Description: OpenPGP digital signature
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Treatise on Formatting FLASH Storage Devices

[Benjamin M. Schwartz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Mitch Bradley wrote:
> It has been my experience that USB sticks and SD cards with intact 
> factory formatting tend to last longer and run faster than ones that 
> have been reformatted with random layouts.

This gives us Linux users a bit of a dilemma if we want to use FTL flash
for primary storage.  FAT does not provide the file access permissions,
symlinks, hardlinks, or even case sensitivity, that we desire for most
filesystems on unixy systems.  However, FTL devices behave as a sort of
FAT-oriented black box, full of secret proprietary firmware that loves
FAT.  One obvious proposal, therefore, would be to use FAT for storage,
but wrap it with a layer that implements all our favorite POSIX stuff.

This has been done before for Linux, in the guise of UMSDOS/UVFAT [1][2].
 Although that work has fallen out of date, I suspect one could
reimplement it quickly using new linux features such as FUSE.  The
question is: would such an approach be worthwhile?

- --Ben

[1] http://linux.voyager.hr/umsdos/
[2] http://en.wikipedia.org/wiki/UMSDOS
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkmKBJ0ACgkQUJT6e6HFtqR8kwCfc9MlcbGv1yaSEog6lNJoqmey
kE0AmwRxwXtORZSITzyDUW5gqu9xBpoq
=Kxa1
-END PGP SIGNATURE-
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Treatise on Formatting FLASH Storage Devices

[Benjamin M. Schwartz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

da...@lang.hm wrote:
> On Wed, 4 Feb 2009, Mitch Bradley wrote:
> 
>> http://wiki.laptop.org/go/How_to_Damage_a_FLASH_Storage_Device
>>
>> Read it and weep.
> 
> this completely ignores wear leveling, which is very nessasary for just 
> about any filesystem, but especially for FAT (which appear to be the only 
> filesystems this author is familiar with)

Umm, what?

"To alleviate the "wear out" problems, the FTL must move data around so
that repeated writes to a given sector don't cause too many writes to the
same NAND page."

Mitch is describing "FLASH" devices like SD cards.  All such devices have
a built-in microcontroller (the FTL) that performs wear-leveling.
Layering additional wear-leveling filesystems like JFFS2 or UBIFS on top
of the FTL requires a reverse translation (block device->MTD) and is not
recommended.  e.g.  From http://www.linux-mtd.infradead.org/doc/ubifs.html :

"UBIFS was designed to work on top of raw flash, which has nothing to do
with block devices. This is why UBIFS does not work on MMC cards and the
like - they look like block devices to the outside world because they
implement FTL (Flash Translation Layer) support in hardware, which simply
speaking emulates a block device"

As for the author only being familiar with FAT, that is hilarious.  Mitch
implemented JFFS2 support in OFW, and wrote this page to explain how he
produced optimal ext2 formatting of FTL FLASH.  Indeed, that is the
subject of
http://wiki.laptop.org/go/How_to_Damage_a_FLASH_Storage_Device#Screwed-Up_Formatting

- --Ben
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkmJq7wACgkQUJT6e6HFtqT4sACdH/YR07Eq+l+i2M53HuWlZbF3
6bYAn3Aw3X7+k+cThHg9elaI/Jjiokp/
=6lfi
-END PGP SIGNATURE-
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: OLPC upgrades

[Benjamin M. Schwartz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

da...@lang.hm wrote:
> the fact that KDE and GNOME (both desktops that are considered pigs on
> normal machines) make a XO laptop seem snappy by comparison to Sugar (as
> of December) means that there is a significant problem with Sugar.

I'm not happy to simply take this as "fact".  It's either a measurement or
an opinion.

> when
> people ask about how to fix things, the answers that keep coming back
> all appear to be python related.

The whole system is in Python!  Everything is going to be python-related!

> so it's not FUD to say that the
> dependance on Python is hurting performance.

It's not "FUD", but it's not exactly substantiated.  We have some
understanding of where we are spending our cycles, and it's not as simple
as "in the python interpreter".  For example, measurements of activity
startup time indicate that we're spending a lot of time in SVG rendering
and Cairo.  This isn't too surprising, since Sugar uses SVGs much more
intensively than most desktop environments, and often renders many
different versions of the same icon for the purposes of recolorization or
animation.

There are certainly many improvements we could make to perceived speed.
Some, like fixing upstream modules (e.g. dbus-python) not to do any
computation at import time, are "python-related", though they have little
to do with the language itself.  Some, like switching to a better
filesystem or testing LZO support in JFFS2, are entirely separate.  Many,
like rewriting the Journal GUI to minimize redrawing of widgets and enable
smarter scrolling, are large projects.

Blaming Python for our user-experience speed problems is not scientific,
and it's not helpful.  Have you found some critical piece of code that you
can rewrite in C for speed?  We'd love that.

- --Ben
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkmIyVUACgkQUJT6e6HFtqSgFgCfdmmKz5qoy7AdDw7XVq1lh0/t
NmMAnij1vpH7oGOa/9h2z/fvrlP745gs
=VpmM
-END PGP SIGNATURE-
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel