Re: Infrequent heap corruption, XO-4, Fedora 20

[Jon Nettleton]

On Thu, Feb 5, 2015 at 8:00 AM, James Cameron  wrote:

> Thanks.
>
> Can I make it happen more often?
>
> Is there a later version of the driver?
>
> We have a different version that I may look into, on arm-3.5-android
> branch.
>
>
run memtester against the majority of your machines memory and then run
gtkperf in an X session.  That is usually enough to trigger it.

Considering that bug exists in all the 4.xx vivante galcore drivers I have
seen I doubt it is fixed in the other version.  Android is much simpler on
memory because it runs everything through a single GL context against a
framebuffer.

I have some tentative patches to fix parts of it in my trees but I doubt a
lot of them would apply to 3.5 without backporting a lot of upstream work.



> On Wed, Feb 04, 2015 at 12:14:02PM +0100, Jon Nettleton wrote:
> > It is a problem with the v4 version of the galcore driver.  We have
> replicated
> > it on a couple of platforms.
> >
> > On Wed, Feb 4, 2015 at 11:26 AM, Peter Robinson <[1]pbrobin...@gmail.com
> >
> > wrote:
> >
> > On Wed, Feb 4, 2015 at 8:10 AM, James Cameron <[2]qu...@laptop.org>
> wrote:
> > > Following up a thread from last September.
> > >
> > > This problem has just become more interesting, because it hit
> during
> > > an activity startup.
> > >
> > > I'm quite used to seeing it with yum.  But seeing it without yum
> now
> > > points us at kernel, glibc or python.
> >
> > We've not seen this in the wider F-20 Fedora ARM distro so my bet
> > would be on the kernel.
> >
> > Peter
> >
> > > [3]http://dev.laptop.org/ticket/12837#comment:4 has the details
> of the
> > > most recent event.
> > >
> > > On Wed, Sep 10, 2014 at 01:56:27PM +1000, James Cameron wrote:
> > >> G'day Peter,
> > >>
> > >> Thanks for any ideas you may have.
> > >>
> > >> The problem also reproduces on OLPC Fedora 20 image for XO-4:
> > >>
> > >> [4]http://build.laptop.org/14.1.0/os1/xo-4/41001o4.zd (552 MB)
> > >>
> > >> *** Error in `/usr/bin/python': free(): invalid pointer:
> 0x047c79ae ***
> > >> === Backtrace: =
> > >> /lib/libc.so.6(+0x6c8b4)[0xb6c828b4]
> > >> /lib/libc.so.6(+0x754e8)[0xb6c8b4e8]
> > >> === Memory map: 
> > >> [...]
> > >>
> > >> The error varies in detail, but always suggests corruption of
> heap or
> > >> pointers to heap.
> > >>
> > >> The triggering conditions are interactive use of yum, yum update,
> or
> > >> yum used by olpc-os-builder.  The latter is a simple reproducer
> for me.
> > >>
> > >> I'm reproducing it on an XO-4, with 2GB of RAM, no swap, 8 GB
> eMMC, 8
> > >> GB USB flash drive.
> > >>
> > >> While memory demand by yum is large by comparison to other
> programs,
> > >> the available memory at the time of failure is ample.  There are
> no
> > >> kernel out of memory (OOM) events.  It seems more likely to occur
> when
> > >> the filesystem cache is under heavy demand.
> > >>
> > >> The method to recreate the problem was:
> > >>
> > >> 1.  install the system image 41001o4.zd using fs-update and then
> boot,
> > >>
> > >> 2.  configure wireless network,
> > >>
> > >> 3.  "yum install -y git olpc-os-builder"
> > >>
> > >> 4.  clone the master branch of
> > >> git://[5]dev.laptop.org/projects/olpc-os-builder
> > >> (last verified with b87e6ee)
> > >>
> > >> 5.  run "./osbuilder.py examples/olpc-os-14.1.0-xo4.ini"
> repeatedly
> > >> until the error occurs (usually within about five attempts),
> > >>
> > >>
> > >> I've also tried running under valgrind, but that causes illegal
> > >> instruction.  It is quite likely I'm not using valgrind correctly.
> > >> [6]http://dev.laptop.org/~quozl/z/1XRYtO.txt
> > >>
> > >> The workaround at the moment is to build our Fedora 20 images on
> > >> Fedora 18.  Fedora 18 shows no sign of the problem.  I'm worried
> that
> > 

Re: Infrequent heap corruption, XO-4, Fedora 20

[Jon Nettleton]

It is a problem with the v4 version of the galcore driver.  We have
replicated it on a couple of platforms.

On Wed, Feb 4, 2015 at 11:26 AM, Peter Robinson 
wrote:

> On Wed, Feb 4, 2015 at 8:10 AM, James Cameron  wrote:
> > Following up a thread from last September.
> >
> > This problem has just become more interesting, because it hit during
> > an activity startup.
> >
> > I'm quite used to seeing it with yum.  But seeing it without yum now
> > points us at kernel, glibc or python.
>
> We've not seen this in the wider F-20 Fedora ARM distro so my bet
> would be on the kernel.
>
> Peter
>
> > http://dev.laptop.org/ticket/12837#comment:4 has the details of the
> > most recent event.
> >
> > On Wed, Sep 10, 2014 at 01:56:27PM +1000, James Cameron wrote:
> >> G'day Peter,
> >>
> >> Thanks for any ideas you may have.
> >>
> >> The problem also reproduces on OLPC Fedora 20 image for XO-4:
> >>
> >> http://build.laptop.org/14.1.0/os1/xo-4/41001o4.zd (552 MB)
> >>
> >> *** Error in `/usr/bin/python': free(): invalid pointer: 0x047c79ae ***
> >> === Backtrace: =
> >> /lib/libc.so.6(+0x6c8b4)[0xb6c828b4]
> >> /lib/libc.so.6(+0x754e8)[0xb6c8b4e8]
> >> === Memory map: 
> >> [...]
> >>
> >> The error varies in detail, but always suggests corruption of heap or
> >> pointers to heap.
> >>
> >> The triggering conditions are interactive use of yum, yum update, or
> >> yum used by olpc-os-builder.  The latter is a simple reproducer for me.
> >>
> >> I'm reproducing it on an XO-4, with 2GB of RAM, no swap, 8 GB eMMC, 8
> >> GB USB flash drive.
> >>
> >> While memory demand by yum is large by comparison to other programs,
> >> the available memory at the time of failure is ample.  There are no
> >> kernel out of memory (OOM) events.  It seems more likely to occur when
> >> the filesystem cache is under heavy demand.
> >>
> >> The method to recreate the problem was:
> >>
> >> 1.  install the system image 41001o4.zd using fs-update and then boot,
> >>
> >> 2.  configure wireless network,
> >>
> >> 3.  "yum install -y git olpc-os-builder"
> >>
> >> 4.  clone the master branch of
> >> git://dev.laptop.org/projects/olpc-os-builder
> >> (last verified with b87e6ee)
> >>
> >> 5.  run "./osbuilder.py examples/olpc-os-14.1.0-xo4.ini" repeatedly
> >> until the error occurs (usually within about five attempts),
> >>
> >>
> >> I've also tried running under valgrind, but that causes illegal
> >> instruction.  It is quite likely I'm not using valgrind correctly.
> >> http://dev.laptop.org/~quozl/z/1XRYtO.txt
> >>
> >> The workaround at the moment is to build our Fedora 20 images on
> >> Fedora 18.  Fedora 18 shows no sign of the problem.  I'm worried that
> >> a low probability heap corruptor may cause instability of applications
> >> in the field.
> >>
> >> The exact same kernel is being used for Fedora 18 and Fedora 20.
> >>
> >> On Tue, Sep 09, 2014 at 03:55:24PM +0100, Peter Robinson wrote:
> >> > What version of OOB are you using, and what config files? I can try
> >> > and recreate the problem here on other devices.
> >>
> >> --
> >> James Cameron
> >> http://quozl.linux.org.au/
> >
> > --
> > James Cameron
> > http://quozl.linux.org.au/
> ___
> Devel mailing list
> Devel@lists.laptop.org
> http://lists.laptop.org/listinfo/devel
>
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [Sugar-devel] restart by ctl+alt+bs

[Jon Nettleton]

On Tue, May 13, 2014 at 2:04 PM, Walter Bender  wrote:
>
>
>
> On Mon, May 12, 2014 at 11:18 AM, TONY ANDERSON 
> wrote:
>>
>> At some point, the ctl+alt+backspace signal to restart was dropped.  This
>> was
>> a very handy way
>> to get out of dead-ends caused by starting too many activities.
>>
>> What I would like to do is have this signal show a screen similar to the
>> switch desktop screen but with
>> a set of options:
>>
>> Start Sugar
>> Start Gnome
>> Login
>>
>> where the login option allows the user to set the nick to his/her
>> username.
>> The advantage of this is that
>> the nick is reset at Sugar start. This option is needed at sites where
>> more
>> than one person uses the laptop (even in OLPC sites, it can be expected
>> that
>> more than one person will use the laptop when it is at home).
>>
>> Does anyone know why this capability was dropped? Is there any technical
>> reason it can not be restored? How does one set the ctl+alt+bs to call a
>> procedure in globalkeys (similar to viewsource and screenshot)? Is that
>> the
>> way this should be done?
>>
>> Thanks,
>>
>> Tony
>>
>> ___
>> Sugar-devel mailing list
>> sugar-de...@lists.sugarlabs.org
>> http://lists.sugarlabs.org/listinfo/sugar-devel
>
>
>
> The newest versions of Sugar let you limit the number of open activities,
> hopefully obviating the root cause of the dead-end you described. Regarding
> support for multiple users, that is another topic altogether.
>

You should look into implementing KSM and zSwap in the XO kernels.
They are a couple of ways that Android KitKat is supporting hardware
with 512MB's of RAM.

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

Re: [Sugar-devel] XO on Fedora 20 (was Re: [GSoC] Porting To Python3)

[Jon Nettleton]

On Mon, May 12, 2014 at 8:02 PM, Daniel Narvaez  wrote:
> Hello,
>
> things are looking good so far, we already have all the models booting into
> sugar 0.101 with wif apparentlyi working. I would like to take a step back
> and understand a bit better where we want to go with this. Some random
> thoughts and questions.
>
> * To really understand how much work is left I think we need some good
> testing, especially on the hardware related bits. I expect there will be
> lots of small things to fix, but it would be good to understand as early as
> possible if there are roadblocks. I'm a bad tester and I've never used the
> XO much, so I'm often not sure what is a regression and what is not... thus
> helping with this would be particularly appreciated.
> * Which deployments are planning to ship 0.102 soon and hence are interested
> in this work? I know of AU. Maybe Uruguay?
> * Do we need to support all the XO models?
> * Should we contribute the olpc-os-builder changes back to OLPC or fork it?
> I don't know if OLPC will do any active development on the linux side of
> things, if not maybe better to turn this into a sugarlabs thing.
> * Are interested deployments using olpc-update? If I'm not mistake AU is
> not.
> * Do we care about maintaining the GNOME "dual boot"? I'm afraid we do, but
> I want to make sure.
> * As I mentioned in some other thread I'm interested in setting up automated
> builds from sugar master. I have some vague plan of what it would look like
> and wrote bits of it. The basic idea is that you would push changes to
> github and get images automatically built. I think this is good for upstream
> testing but the same infrastructure could be used by deployments. Are people
> interested in using this?

Why is all this work being put into Fedora 20?  The maintenance window
is limited and as of the next release they won't even support non-KMS
drivers by default.  Wouldn't make sense to look into a distribution
that provides and LTS release?  Resources already seem to be limited
so having to chase after Fedora every 6 months to a year seems like a
waste of resources.  The GTK3 and GNOME teams obviously have their
eyes on a different class of hardware than what is being used by
deployments.

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

Re: EC, CForth exploratory commands?

[Jon Nettleton]

On Mon, Apr 14, 2014 at 7:21 AM, Mitch Bradley  wrote:
> Recompiling can work if you fine tune your build and download setup so
> the crank-turn time is very short, like less than a minute.
>
> The very first thing I did when I joined OLPC was to fix the firmware
> downloader.  I was on a conference call with Richard and Jim Gettys and
> some guys from Quanta.  The report was that it took something like 15
> minutes to put in new firmware, using a DOS program that talked to a
> serial download port on the EC that owned the SPI FLASH.  My head
> exploded.  I knew that the hardware was capable of programming that size
> SPI FLASH in less than a minute, so I started looking for bottlenecks
> and quickly found them.
>

I was talking with bunnie and xobs about doing something similar for
the iMX6 platform that bootstraps from SDHC.  Since they had already
reverse-engineered the linux firmware for at least one type of SDHC
card, we figured we could run that on the FPGA and interface the FPGA
out to a microsdhc connection.  This would allow us to compile uboot
and install it to a ramdisk that would be immediately available to the
iMX6 board to attempt to boot and debug.  I will let you know my
initial bringup of the SolidRun boards got me very adept at swapping
microsdhc cards. ;-)

But I do like having the bootloader right on the SDHC card.  Virtually
unbrickable.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: EC, CForth exploratory commands?

[Jon Nettleton]

On Mon, Apr 14, 2014 at 5:44 AM, Martin Langhoff
 wrote:
> On Sun, Apr 13, 2014 at 10:25 PM, John Watlington  wrote:
>>
>> On Apr 13, 2014, at 9:19 PM, Jon Nettleton wrote:
>>
>>> Otherwise you really need a jtag debugger.
>>
>> Or Open Firmware --- by far the nicest bringup
>> tool I've ever had the pleasure to use.
>
> Yup. I'm learning OFW love alright with the kind hand of u-boot.
>
> To be fair, I am getting help from the u-boot maintainers and I am
> just kicking the tires and trying to update some board files to latest
> u-boot. But in the back of my mind I run through  "how would you use
> u-boot in bringup instead of ofw?".
>
> Lots of things I "knew" from discussions with y'all during bringups is
> now becoming clearer.
>
> Having the best u-boot hacker in the world would probably would bring
> you to a good outcome.

hahaha...I doubt that.  U-boot is such a mess to work with, sometimes
it surprises me it works at all.  BareBox is a much nicer
implementation and Novena and SolidRun will be switching over to it as
soon as I finish my DirectBoot implementation.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: EC, CForth exploratory commands?

[Jon Nettleton]

On Mon, Apr 14, 2014 at 2:56 AM, Martin Langhoff
 wrote:
> On Sun, Apr 13, 2014 at 7:34 PM, Mitch Bradley  wrote:
>> That early work is very detailed and very specific to grotty details
>
> Fantastic info -- thanks!
>
> Part of the story I am exploring is of why someone would want an EC
> and a tiny early interactive runtime for debugging (i.e. during bring
> up).
>
> In related news, I'm poking around with u-boot for the Novena board
> and maybe I'm missing some debugging tricks but it seems much harder
> to debug. When it doesn't boot all the way to a working u-boot, well,
> it doesn't and that's all you know.

Well the best you are going to get is enabling CONFIG_DEBUG to get
more verbose output.  If the crash is happening really early you can
enable the serial console by hand and use serial_puts, or puts to get
some output.

Otherwise you really need a jtag debugger.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [XSCE] XO-1 wireless tests

[Jon Nettleton]

*snip*

>
> So I think the answer is yes to 1) and yes to 2), especially if you are
> unlucky enough to have your target AP and the active mesh on the same
> channel.
>

Does the mesh get disabled or moved when you connect to an AP on a
different channel?  The XO's only have a single radio so can only
communicate efficiently on a single channel at a time.  If we are
trying to keep the mesh active on one channel and connect to an AP on
another that is certainly going to cause problems.

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

Re: [UKids] "XO-1 classrooms" don't reliably connect to many/most Wifi AP's

[Jon Nettleton]

On Tue, Feb 11, 2014 at 7:08 AM, James Cameron  wrote:
> On Mon, Feb 10, 2014 at 11:31:39AM +1100, James Cameron wrote:
>> On Sun, Feb 09, 2014 at 07:18:49PM -0500, Kevin Gordon Gmail wrote:
>> > Tp link set as 3g router mode, with usb Sierra wireless usb modem,
>> > set to channel 11, 80211g only, wpa2 pal security. Running stock
>> > f/w.
>>
>> Terry found that channel 1 was the most afflicted.  I suspect, but I
>> haven't checked, that the idle mesh only uses channel 1, but it also
>> use whatever channel the laptop is associated with.
>
> Tim's results from Open Firmware show that the idle mesh switches to
> whatever channel is being used for association with an access point.

This has to be the case because there is only one radio, so both
802.11s and 802.11b/g have to be configured for the same channel.

>
> So while we would normally see an operating mesh on 1, 6 and 11, it
> can be seen on other channels as well.
>
> The underlying fault was somewhat channel specific ... because the
> scans are done in sets; (1,2,3,4), (5,6,7,8), (9,10,11,12).  If a mesh
> was heard on channel 1 then the scan results for channels 2, 3 and 4
> will have been lost.  If a mesh was heard on channel 9, then the scan
> results for channels 10, 11 and 12 will have been lost.
>

I think really what we need to do is have a better workflow for
detecting connectivity, not much different from how we are handling
ad-hoc on the later model XO's

I think on initial boot, or waking from suspend and the previous wifi
state was not connected, we need to disable the mesh interface and
scan for infrastructure AP's.  Then if this fails we can either scan
for ad-hoc or bring up the mesh interface and look for a mesh network
to connect to.  I think besides driver bugs we have a general problem
of trying to do too much at the same time with a single radio.

any takers on this workflow for network discovery?

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

Re: [XSCE] Large groups of XO-1 do not work with access points

[Jon Nettleton]

On Fri, Feb 7, 2014 at 6:08 AM, James Cameron  wrote:
> On Thu, Feb 06, 2014 at 05:09:47PM -0500, Tim Moody wrote:
>> James wrote:
>> >The XO-1 will consume more of the available bandwidth than an XO-1.5
>> >or later, because each XO-1 continually transmits mesh beacons even if
>> >mesh is not in use.  Each XO-1 also responds to every scan (probe
>> >request) by every other laptop.
>>
>> I'm not sure what you mean by 'even if mesh is not in use'.  Do you
>> mean even if it has been explicitly turned off with echo 0 >
>> /sys/class/net/eth0/lbs_mesh?
>
> No.  What I mean by "even if mesh is not in use", is "even if a mesh
> network icon has not been selected by the user, and has not been
> automatically selected by Sugar, and the laptop is associated with an
> access point".
>
> Disabling the mesh using /sys/class/net/eth0/lbs_mesh does prevent the
> 409.6ms beacons.  This is easily demonstrated using monitor mode and
> tcpdump.
>

For the people seeing these problems and trying to debug could you
please run this command at startup to get some additional debug output
from the libertas driver?

echo 0x6180 > /sys/module/libertas/parameters/libertas_debug

For more debug options please reference,
http://wiki.laptop.org/go/Libertas_Debug

To both disable mesh and setup debug on boot do something like this.

echo "options libertas libertas_debug=0x6180 libertas_disablemesh=1" >
/etc/modprobe.d/libertas.conf

When testing for AP visibility please use iwlist scan rather than the
network view within Sugar.  NM compatibility bugs can skew the
perceived results.  It is much better to capture the data to analyse
at a closer level to the kernel driver.  This could very well be a NM
bug rather than an AP wifi driver bug.

After you have have tested with the above options set, please report
back with dmesg and `iwlist scan` output from both a successfully
connected client, and a failed client.  Also if you can export the
wifi settings for a router that exhibits the problem vs one that does
no that would be useful as well.

I understand some/all of these steps may have been done already.  If
they have could you pass on the results, or point me to a location I
can look at them?

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

Re: XO Problems (4 Problems)

[Jon Nettleton]

On Nov 25, 2013 5:37 AM, "Paul Fox"  wrote:
>
> walter wrote:
>  > On Sun, Nov 24, 2013 at 1:53 PM, C. Scott Ananian 
wrote:
>  > > Anyone have any suggestions for my six year old friend?
>  > > IIRC startup volume  is persistent, but I can't remember how it is
adjusted.
>  >
>  > Yes. He can adjust the volume using the volume control on the Frame
>  > and it should persist.
>
> really?  i thought startup volume (the "on music" -- love it!) was
> controlled by, and persisted by, OFW, and that it was a separate
> setting than for the running OS.  i.e., it used to be that you had to
> adjust the volume while the chimes were still playing, and then you'd
> be all set.
>

OFW and Linux do handle their volume settings individually. Paul's
suggestion should fix that problem up. I believe there is a newer OFW
revision that reduces the overall volume to avoid distortion.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: some very cool features for a capacitive touchscreen

[Jon Nettleton]

On Fri, Oct 25, 2013 at 1:40 PM, Manuel Quiñones  wrote:

> 2013/10/24 Sameer Verma 
> >
> > I saw some very cool features in a presentation today at the Internet
> > Archive. The presentation was by Eitenne Mineur, as part o the "Books
> > in Browsers 13" event.
> >
> > They are using paper and other simple objects that have kind of
> > conductive patterns to create story platforms, but with interactivity.
> > Start with a story screen, place a paper cutout of one of the
> > characters, and the story comes to life. Place a second character, and
> > the scene changes.
> >
> > All very interesting ideas for us to use on the XO-4 Touch, although
> > the XO4 does not use capacitance, but the idea is very cool.
> >
> > http://volumique.com/
>
> Wow, this is very inspiring.  Somebody should try this technique on an
> XO-4.


Unfortunately because of the way our touch technology works, this exact
implementation won't work.  However our touch technology is actually nicer
because you don't need special material to activate the touches.  I think
what would work well for us would be an activity that allowed you to
program what shape/character was attached to different size touch points.
 Then use small wooden/plastic disks of different sizes glued or clipped to
the back of the cutouts to trigger the touch events and let the program
know what story to tell.

smallest disk = dog
medium disk = frog
large disk = frisbee

I would have to double check but I think we pass along the touch width as
the pressure value for evdev.  Should be easy to parse the event and figure
out what is on the screen, and should work with 2-4 touches/items.

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

Re: [support-gang] [Sugar-devel] Sugar on a $100 tablet!

[Jon Nettleton]

On Sun, Sep 29, 2013 at 4:27 AM, Caryl Bigenho  wrote:

> Hi...
>
> Will some of you be at the SF Summit? I can bring my XO Tablet if you
> would like to test Sugar on it. All I ask is that you sweep it clean when
> finished so I can re-customize it for my grand daughter. It's to be her
> present for her third birthday in late December.
>
> Caryl
>
> P.S. If others can bring other Android devices they don't mind messing
> with that would be great. In fact, maybe you could play with my Samsung
> phone... same conditions... wipe it clean or restore it when we have
> finished playing.
>
>
Caryl,

To the best of my knowledge I don't believe that the XO Tablet has been
rooted, and the buyers do not have the ability to unlock the bootloader.
This basically means you will not be able to do this customization onto the
XO Tablet.  Yet another reason why that device fails in the OLPC Mission
statement in so many ways.

Except for Nexus devices, any other devices rooted or unlocked to perform
this testing on usually voids the devices manufacturer warranty.  I don't
want to discourage the tinkering, just make sure you know the ramifications
of your choice.

A device like Pengpod would be far more suitable for testing like this,
http://www.indiegogo.com/projects/pengpod-1040-quad-core-linux-android-dual-booting-tablets
Unfortunately it does not look like the company will receive the funding
they are in search of to produce their product.  I like their idea but the
execution so far does not inspire me enough to donate to their campaign.

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

Re: flash/marvell-ipp

[Jon Nettleton]

On Wed, Sep 25, 2013 at 2:06 PM, Yioryos Asprobounitis
wrote:

> I would appreciate if someone could inform me about the redistribution of
> the
>
> ARM version of Adobe Flash present in OLPC-AU builds for XO-4.
> We would like to include it in FatDog/Puppylinux builds for the ARM XOs
> but we
> certainly do not want to violate any outstanding redistribution agreements.
> Alternatively we could have a script for the user to rsync it from the
> olpc-au
> update server directly.
> I looked for the equivalent of rsync://updates.laptop.org/ but could not
> find
> anything.
> Any pointers?
>
> The other thing that we can not find is the marvell-ipp source. The
> http://wiki.laptop.org/go/Vmeta page points to
> Git repo: /home/dsd/private_git/marvell-ipp branch (mmp2/mmp3 branches)
> Does "private_git" means that indeed are not available?
> Or that maybe available only after an NDA or something relevant?
> Thanks
>
> My understanding is that the XO-1.75 codec licensing was done as an add on
to the customers order.  That changed with the XO-4 as codec licensing was
purchased for all machines produced.  That is why vMeta should be available
to all XO-4 owners.

I have never been in any conversations with anyone that new the actual
licensing for the Adobe Flash binary.  The restrictions for it were
originally imposed by the requirement that vMeta licensing be purchased
because our custom version of flash uses the vMeta hardware decoding for
video playback.  Be aware that the Flash plugin for the XO-4 only works on
the XO-4 as it is NEON optimized and the XO-1.75 does not support those
instructions.  The flash plugin for the XO-1.75 is iWMMXt optimized which
will run on both platforms.

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

Re: hdmi out

[Jon Nettleton]

On Aug 18, 2013 10:30 AM, "Barry Vercoe"  wrote:
>
> Jon, yes the file exists on our system here.  Contains just a zero.

Also when HDMI is plugged in? Could you send me a full dmesg output of the
HDMI handshake with auto power save enabled?

>
> -- barry
>
> On 18/08/2013 6:18 p.m., Jon Nettleton wrote:
>>
>>
>>
>>
>> On Sun, Aug 18, 2013 at 7:57 AM, Barry Vercoe 
wrote:
>>>
>>> Of Course!!  I used to have that problem when I played long Csound
demos -- overworking the Flt Pt processor yet untouched by human hands
...   I don't know why I didn't relate the two situations.
>>>
>>> Turned off power saving, and the problem immediately went away.
>>> No, power saving doesn't turn off automatically when hdmi is plugged
in.  Perhaps it should ...
>>> Or at least we should have a warning distributed with the hdmi cable
that the port will turn off after 15 seconds with power saving on.
>>>
>>
>> Could you check something quick for me.  Does the status
file /sys/devices/d420b000.display/pxa168fb_gfx.1/hpd exist on your system?
>>
>> Thanks
>>
>>
>>>
>>> Thanks all.
>>> -- b
>>>
>>> On 18/08/2013 5:26 p.m., Tom Parker wrote:
>>>>
>>>> On 18/08/13 17:05, Barry Vercoe wrote:
>>>>>
>>>>> OK, with tail -f ... messages, I do see a burst of messages and the
>>>>> projector shows the exact screen.  But only for 15 seconds, when the
>>>>> projector then goes blank and reverts to _No Signal_ until I touch
>>>>> something on the XO like the screen, track pad or some key.
Apparently
>>>>> the XO has stopped sending hdmi signals, so the projector is
reporting
>>>>> exactly that.
>>>>
>>>>
>>>> When the display goes blank, does the power light start flashing to
indicate the laptop has gone to sleep?
>>>>
>>>> Try turning off power saving in the settings. When I was testing, the
power saving automatically turned off when I plugged in an external display
and turned on again when I unplugged it, but perhaps this isn't working on
your laptop?
>>>
>>>
>>>
>>> ___
>>> Devel mailing list
>>> Devel@lists.laptop.org
>>> http://lists.laptop.org/listinfo/devel
>>>
>>
>
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: hdmi out

[Jon Nettleton]

On Sun, Aug 18, 2013 at 7:57 AM, Barry Vercoe  wrote:

>  Of Course!!  I used to have that problem when I played long Csound demos
> -- overworking the Flt Pt processor yet untouched by human hands ...   I
> don't know why I didn't relate the two situations.
>
> Turned off power saving, and the problem immediately went away.
> No, power saving doesn't turn off automatically when hdmi is plugged in.
> Perhaps it should ...
> Or at least we should have a warning distributed with the hdmi cable that
> the port will turn off after 15 seconds with power saving on.
>
>
Could you check something quick for me.  Does the status
file /sys/devices/d420b000.display/pxa168fb_gfx.1/hpd exist on your system?

Thanks



> Thanks all.
> -- b
>
> On 18/08/2013 5:26 p.m., Tom Parker wrote:
>
> On 18/08/13 17:05, Barry Vercoe wrote:
>
> OK, with tail -f ... messages, I do see a burst of messages and the
> projector shows the exact screen.  But only for 15 seconds, when the
> projector then goes blank and reverts to _No Signal_ until I touch
> something on the XO like the screen, track pad or some key.  Apparently
> the XO has stopped sending hdmi signals, so the projector is reporting
> exactly that.
>
>
> When the display goes blank, does the power light start flashing to
> indicate the laptop has gone to sleep?
>
> Try turning off power saving in the settings. When I was testing, the
> power saving automatically turned off when I plugged in an external display
> and turned on again when I unplugged it, but perhaps this isn't working on
> your laptop?
>
>
>
> ___
> Devel mailing list
> Devel@lists.laptop.org
> http://lists.laptop.org/listinfo/devel
>
>
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: hdmi out

[Jon Nettleton]

On Sun, Aug 18, 2013 at 7:26 AM, Tom Parker  wrote:

> On 18/08/13 17:05, Barry Vercoe wrote:
>
>> OK, with tail -f ... messages, I do see a burst of messages and the
>> projector shows the exact screen.  But only for 15 seconds, when the
>> projector then goes blank and reverts to _No Signal_ until I touch
>>
>> something on the XO like the screen, track pad or some key.  Apparently
>> the XO has stopped sending hdmi signals, so the projector is reporting
>> exactly that.
>>
>
> When the display goes blank, does the power light start flashing to
> indicate the laptop has gone to sleep?
>
> Try turning off power saving in the settings. When I was testing, the
> power saving automatically turned off when I plugged in an external display
> and turned on again when I unplugged it, but perhaps this isn't working on
> your laptop?
>

I think you guys are right on about what is happening.  Is this a 13.2.0
build or something older?  I can't remember at what point we added the
hooks to let powerd check for the hdmi connection status and act
accordingly.

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

Re: XO-4 HDMI output

[Jon Nettleton]

On Thu, Jul 18, 2013 at 11:19 AM, Tom Parker  wrote:

> On 17/07/13 21:21, Jon Nettleton wrote:
>
>> If you want to provide the output of dmesg when you connect your DVI
>> cable I will gladly take a look and see why you aren't at least getting
>> a VESA VGA resolution.
>>
>
> Today it behaved much better. I don't know why I had such poor luck
> yesterday. Today I tried jiggling the cables but that didn't seem to have
> any effect (ie it continued to work even with quite a lot of jiggling)
>

Is this a B1 model?  We had a positioning problem with the jack on the B1's
that was fixed in subsequent revisions.  We do have code that tries to
detect cable jitter and not kick of hotplug events accordingly.  Of course
if the cable itself is flaky then there isn't much we can do about that.


>
> I was able to identify a negative interaction with suspend -- if the
> laptop is suspended when you plug the hdmi cable in, it doesn't wake up and
> the display behaves as if the laptop is off. The couple of times I tried,
> waking the laptop up with the touchpad caused the external display to come
> to life. I don't think this can account for all of yesterday's troubles.
>

Power Manager should be disabling fast S/R if the hdmi connection is
detected this is just to keep the external display from blanking
continuously.  I have been running hdmi with suspend/resume enabled for
some time now and have not seen any adverse effects.  I will have to test
this with a vanilla 13.2.0 install.


>
> *snip*


Thanks for the dmesg output.  I will note that we found with some Dell
monitors you needed to go into the config and set the monitor to video mode
instead of computer mode.  I will try to keep everyone posted on the
continued HDMI progress as free time permits me to work on it.

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

Re: XO-4 HDMI output

[Jon Nettleton]

On Wed, Jul 17, 2013 at 10:45 AM, Tom Parker  wrote:

> Hi,
>
> How does the HDMI output on the XO-4 work? I've got a micro-HDMI to
> regular HDMI cable and also an HDMI-DVI adaptor. I tried connecting to the
> the HDMI input of a TV and that worked in both sugar and the firmware.
> Quality was kinda poor (like it was doing some scaling, which I guess it
> has to if it's doing mirror and filling both screens) and the mouse pointer
> didn't show up on the TV. I didn't check the output of xrandr in this
> configuration.
>

The XO-4 is using the SOC's hardware scaling to mirror the 1200x900
framebuffer of the XO-4.  Yes the quality isn't the best but we determined
it was good enough for launch and it saves some extra CPU cycles and
minimizes X drawing lag as Xorg is still just drawing for the LCD screen.
 Without compositing this is the lowest cost way of mirroring screen
output.  This is all done automatically in the kernel driver when the hdmi
cable is plugged in.  Much like most android tablets on the market we
wanted to keep the process simple without needing to tweak a large number
of knobs and config files.


>
> When I connect to a regular monitor via the DVI adaptor, the monitor
> detects the presence of the laptop and goes to sleep. In the open firmware,
> if I type 720p, I get the firmware on the screen. If I then type bye, the
> laptop boots normally but there is no further output on the screen. I don't
> see any additional displays in xrandr.
>

DVI requires an additional set of frequencies and resolutions setup.  HDMI
timings are CEC standard and DVI are VESA standard.  Some monitors do
handle CEC timings over the DVI cable but that is very hit and miss.  Our
initial goal was to get a driver working that could handle HDMI
certification and then add support for DVI later.  OFW gives you a 720p
resolution because that is the fallback that Mitch puts in.  You are
probably are getting output like "we don't support any of these
resolutions, falling back to 720p"  This is fine for OFW as more advanced
users will be in there using it for testing.  Simply outputting an unstable
or unsupported resolution to a monitor that could produce erratic behavior
was not something that we can support long term.  We felt only supporting
modes that the monitors EDID supported was the safest way to minimize
confusion.  This is a pretty safe assumption for HDMI, DVI can be hit and
miss.

We do have patches for more accurate HDMI clocks in the current kernel git
tree.  I am not sure if they have made it into a build yet.

Xorg has no idea that there is an HDMI monitor attached so xrandr will show
nothing about the output.  KISS for this release as it was a new feature to
the XO line.

If you want to provide the output of dmesg when you connect your DVI cable
I will gladly take a look and see why you aren't at least getting a VESA
VGA resolution.

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

Re: Headphone volume adjustment

[Jon Nettleton]

On Fri, Jul 5, 2013 at 5:48 PM, Daniel Drake  wrote:

> Hi,
>
> On Fri, Jul 5, 2013 at 12:40 AM, James Cameron  wrote:
> > Fixed for XO-4 in:
> >
> >
> http://dev.laptop.org/git/olpc-kernel/commit/?h=arm-3.5&id=e77de3d4ec7589af2e88014018c69528ceab3293
>
> Thanks for looking at this.
>
> I'm trying to review the change. I am a bit stuck though, because I
> still don't understand the answer to the opening question on this
> thread: is this a bug or by design?
>
> Do I gather correctly from your initial response that it is by design
> that the headphone volume slider does not cover the full range offered
> by the hardware? That is, if I use alsamixer to set the volume as low
> as it will go, the value programmed to the hardware is not the lowest
> that the hardware can go? If that is the case, why?
>

Is this a by-product of a different design decision.  I think it was for
the xo-1.75 that we implemented a feature that limited the max volume of
the headphone jack.  This is actually a requirement for EU sales.  Is it a
possibility that the range got shifted in the wrong direction?

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

Re: XO-1(.75)

[Jon Nettleton]

On Thu, Jul 4, 2013 at 8:19 AM, James Cameron  wrote:

> On Wed, Jul 03, 2013 at 11:03:17PM -0700, Yioryos Asprobounitis wrote:
> > - Original Message -
> >
> > > From: James Cameron 
> > > To: Yioryos Asprobounitis 
> > > Cc: OLPC Devel 
> > > Sent: Thursday, July 4, 2013 8:44 AM
> > > Subject: Re: XO-1(.75)
> > >
> > > On Wed, Jul 03, 2013 at 10:02:15PM -0700, Yioryos Asprobounitis wrote:
> > >>  - Original Message -
> > >>
> > >>  > From: James Cameron 
> > >>  > To: Yioryos Asprobounitis 
> > >>  > Cc: OLPC Devel 
> > >>  > Sent: Thursday, July 4, 2013 2:10 AM
> > >>  > Subject: Re: XO-1(.75)
> > >>  >
> > >>  > On Wed, Jul 03, 2013 at 02:21:08PM -0700, Yioryos Asprobounitis
> wrote:
> > >>  >>  I'm using the XO-1.75 a bit more these days and gives me a
> > > sense of
> > >>  >>  XO-1 performance wise.  So I compared my (500/200 overclocked)
> > > XO-1
> > >>  >>  running F14/os885/Sugar-0.94 to XO-1.75 running
> > >>  >>  F-18/13.2.0-11/Sugar-0.98.
> > >>  >
> > >>  > Since some general performance work was done between those software
> > >>  > versions, the comparison is uninteresting.  Compare 13.2.0-11
> across
> > >>  > XO-1 and XO-1.75, or compare XO-1 across os885 and 13.2.0-11,
> > >>  > depending on what you are looking to prove.
> > >>
> > >>  This comparison has been done a couple of months ago and is clear
> > >>  that F18/S0.98 taxes the systems considerably.
> > >
> > > Yes, it does seem that way.  I tried 13.2.0-n on XO-1 recently and
> > > felt it was quite slow, but I couldn't be sure it wasn't because my
> > > XO-1.75 and XO-4 experience influenced me.
> > >
> > >>  What I found interesting in this "unmatched" comparison was the
> > >>  inconsistency.
> > >
> > > I don't see any inconsistency though, because the comparison was
> > > unmatched to begin with.  Variables you changed included overclocking,
> > > the CPU, the memory, the internal storage, the touchpad, the kernel,
> > > the base operating system, the frame buffer, the X server, the OLPC
> > > utilities, and Sugar.  All I can draw from the results is that you
> > > changed a lot of things and a lot of things were different.
> >
> > But this is exactly the point!
> > When a _lot_ of things are changing and you have two groups of
> > activities one going one way and the other  the opposite, you look
> > for the "least common denominator" that will hopefully point to the
> > problem (this is is a very common approach in multi-variable
> > problems).
>
> Oh good, now I understand.
>
> >
> > >
> > >>  They might point to specific stacks in the
> > >>  architecture and/or core OS that may need attention (I originally
> > >>  thought was that activities with an extended non-python component or
> > >>  proportionally less gtk3, fair better on the XO-1.75 - but what do I
> > >>  know ;).
> > >>  Anyway, if the knowledgeable believe there is nothing to it or
> > >>  anything to be done about it,' there goes the comparison.
> > >
> > > We wait for someone who seems interested in fixing performance
> > > problems on the old hardware.  It requires quite a depth of knowledge
> > > and a lot of time.  It isn't something that we can justify a huge
> > > investment in.
> > >
> >
> > I would think that the performance of newer hardware may be the one
> > that needs attention but certainly can not prioritize it (unless if
> > XO-1.75 classifies under "older" by now).
>
> XO-1.75 and XO-4 are current, but XO-1.5 and XO-1 are old.
>
> We are certainly interested in any ways to make clear performance
> improvements on XO-1.75 and XO-4.
>
>
There is performance work that has been done for the XO-1.75 that is still
in the queue to be implemented in the OLPC builds.  It is on my list for
the summer to get this work cleaned up and published in a repo for
developer and end user consumption.  The performance gains are due to work
done by Matt Turner implementing iWMMXt acceleration in pixman, as well as
other libraries that when compiled with this support get some performance
boosts.  Mostly graphics and multimedia apps will benefit from this tuning.

On top of that both the XO-1.75 and XO-4 will get graphics performance
boosts when I finish up my graphics driver that allows cached pixmaps to be
used.  We have to do some graphics rendering and manipulations with the CPU
instead of the 2D core and we hit a performance bottleneck with the way
pixmaps are allocated for use by the graphics engine.

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

Re: School networks and electrical equipment damage

[Jon Nettleton]

On Thu, Jun 6, 2013 at 9:58 PM, Daniel Drake  wrote:
> Hi,
>
> Those of us familiar with setting up school networks (server + switch
> + APs) in some of our deployments will be familiar with  the
> occasional loss of hardware, due to surges in the low quality
> electrical supply or whatever, even when the system is protected by a
> cheap UPS which supposedly offers some protection.
>
> This has often been the case in Nicaragua, so the group is now buying
> more expensive UPSes, PoE switches, and PoE access points for new
> schools. This means that the server and switch are connected to mains
> power via a UPS which hopefully protects them, and none of the APs are
> connected directly to the mains (instead they get Power over Ethernet)
> which hopefully offers some isolation from bad electrical conditions.
>
> This equipment is expensive, especially in places like Nicaragua where
> lots of import taxes are applied. But the hope is that the investment
> pays off in that the equipment doesn't get zapped.
>
> However, one week after deploying this equipment in the first school,
> we are left with a server that doesn't boot, 3 out of 4 access points
> broken with a nice burning electronics smell, and a broken switch with
> a lot of visible damage to the electronics.
>
> And the most surprising thing - we had not even turned on the network
> yet, pending some electrical work. Everything was connected up except
> one crucial link - the UPS was not plugged into mains power. So all of
> this damage happened without any of the devices having a connection to
> the mains.
>
> Connectivity-wise, the setup was:
> WAN: Phone line - ADSL modem - XS
> LAN: XS - Switch - 4 APs
>
> And power connections: the XS, ADSL modem and switch were connected to
> the UPS. The APs were connected to the switch over ethernet for both
> power and data. Again, since the battery was not connected to mains
> power, none of the devices had a power source.
>
> The connectivity engineer's best bet is that a lightening bolt landed
> at the school or nearby, and that this caused a power surge on the
> phone line. This surge passed through the ADSL modem, server, switch,
> and 4 APs, destroying everything in its path (except 1 AP that was
> connected over a longer cable than the rest).
>
> I figured this is a story worth sharing, for any other projects
> considering splashing out on more expensive equipment...
>
> Also, I'm wondering if anyone has any advice/experience here. Would
> others expect this more expensive setup to be more resilient to bad
> electrical conditions than a cheaper setup - will the investment pay
> off?
>
> I figure that the case of a lightening bolt might be a bit extreme,
> but electrical storms are a nightly occurance here almost daily during
> the 6 month rainy season.
>
> I have seen that some UPSs (unfortunately not these ones) allow a
> phone line to be passed through them, supposedly offering some
> protection. Would such a system protect against a lightening bolt,
> assuming thats what happened here?

What is the grounding of the electrical setup there?  You may want to
invest in having a separate grounding rod installed specifically for
the circuit the network equipment is on and possibly a lighting rod.
When we built out a small data center in Alewife we actually had the
building install a lightning rod on the roof with a dedicated ground
circuit to help protect our circuits in the building.

In general I have found that more expensive network equipment handles
dirty power a bit better than the cheap stuff.  As for lightning and
other larger power surges, all of it fries about the same.  For POE
WAP's I would suggest looking at the Ubiquiti lineup.  I have a couple
of Picostation2's and a Nanostation M2 and have very impressed with
their coverage and stability for the price.  They are also
indoor/outdoor certified.

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

Re: USB Network Adapter recommendations

[Jon Nettleton]

On Mon, May 13, 2013 at 5:15 AM, John Watlington  wrote:
>
> Can you recommend a particular USB network adapter for long term reliability ?
>
> I have been using the Zoltan USB adapters that Michail had manufactured
> for use with the XO, with ok performance.   (I have been told that under
> heavy load they don't work as well.)   After only a year of continuous use, I 
> just
> had one stop working: transmissions (receptions ?) saw increasing errors but
> kept operating (just dropping seriously impacting link performance).  
> Occasionally,
> however, it would overcurrent the XO USB port, giving a clue as to the 
> defective component.

I have also seen this behaviour on one of my Zoltan USB adapters.  The
one that failed was painted green on the inside of the plastic, which
makes it an older one I believe.

I have ordered a USB network adapter from Pluggable and am using that
on my dev machine as it is 10/100/1000.  It runs an Asix chipset but I
can't really comment on long term reliability yet.  The performance is
quite good.

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

Re: Kernel RPMs now auto-install to boot partition

[Jon Nettleton]

On Fri, Mar 22, 2013 at 5:03 PM, Martin Abente
 wrote:
> Great! :D
>
>
> On Fri, Mar 22, 2013 at 12:09 PM, Anish Mangal  wrote:
>>
>> awesome!
>>
>> On Fri, Mar 22, 2013 at 10:57 AM, Paul Fox  wrote:
>> > wow.  somehow i didn't think this would ever happen.  thank you!!
>> >
>> > paul
>> >
>> > daniel wrote:
>> >  > Hi,
>> >  >
>> >  > Found some time to implement something that has been desired for a
>> >  > while: now when you install a kernel RPM on the XO, it will
>> >  > additionally auto-install to the boot partition, so now you can just
>> >  > install a new kernel RPM with rpm/yum and reboot and expect it to be
>> >  > used, no additional steps needed.
>> >  >
>> >  > The root of this strange behaviour (installing kernels twice) is due
>> >  > to the design of the update system, there might be room to improve on
>> >  > this in future as well, but at least this detail will now be less
>> >  > annoying to developers.

Does the installation occur only if the olpc-dev-kernel had previously been run?

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

Re: 12.1.0 and 13.1.0 provide absurdly small temporary space

[Jon Nettleton]

On Mon, Mar 18, 2013 at 6:36 AM, James Cameron  wrote:
> On Mon, Mar 18, 2013 at 12:08:38AM -0500, Mikus Grinbergs wrote:
>> >I was unable to reproduce on 13.1.0.
>>
>> My apologies - I wrote without realizing that I haven't experience
>> this with recent 13.1.0 builds (but I do remember it on 13.1.0 -
>> maybe it was on the initial builds).
>
> No worries.  Yes, I remember it too, perhaps it was fixed in that
> period.
>
>> I definitely do currently experience the too-small-tmp-size with my
>> (customized) 12.1.0 build 21.  My bypass is to issue 'umount -l
>> /tmp' followed by 'mount -a' - that restores /tmp to the size I have
>> in my fstab.
>
> I'm puzzled.  I've just tested on XO-1 with 12.1.0 build 21, and it
> does not reproduce for me.
>
> /tmp begins with size 51200 blocks according to df.  I was able to
> increase the size with this command:
>
> sudo mount -o remount,size=90m /tmp
>
> The file /etc/fstab has size=50m for /tmp.  I edited the file to 70m,
> then rebooted.  /tmp/ now shows size 71680 blocks.
>

I have seen this same problem.  I am not sure what the circumstances
were that produced tmpfs only being mounted with 1MB of space.

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

Re: Playing video on Sugar startup with VMETA

[Jon Nettleton]

On Fri, Feb 22, 2013 at 6:31 AM, Sridhar Dhanapalan
 wrote:
> We're trying to make XO-1.75s play quality video on Sugar startup. Our
> solution involves installing the VMETA software on 12.1.0 and then
> loading the video in Totem using the Welcome activity hook in Sugar.
>
> As this is for marketing/instructional purposes, we need the process
> to be really slick:
>
>   1. XO loads with fully graphical boot animation (no console)
>   2. video loads and plays, with no chrome (toolbars, sidebars, etc.),
> high quality, full frame rate and complete A/V sync
>   3. Sugar loads as normal
>
> What we've found is that Totem segfaults when invoked with
> --fullscreen. It doesn't crash when loaded in a window, but there's so
> much chrome that it looks silly. Even a simpler gstreamer-based
> player, gst123, crashes soon after startup. I'm of the understanding
> that we need to be using a gstreamer player.

As of now yes.

>
> Is there anything that we can do to improve our present situation?

Can you please provide the patches, and media you are using to accomplish this?

Does totem --fullscreen segfault if run from a terminal under Sugar?

Please provide any logs that you can collect.

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

Re: 13.1.0 build 29 for XO-4 released

[Jon Nettleton]

On Tue, Feb 12, 2013 at 7:42 PM, Martin Langhoff
 wrote:
> On Tue, Feb 12, 2013 at 1:33 PM, Gary Martin  
> wrote:
>>> This is a known issue. Next release will have a better fix.
>>
>> Does this fix also resolve the small random graphic corruptions to the first 
>> boot welcome content?
>
> AIUI, Jon is working on sorting all the corruption fixes he can, so
> the answer should be yes, but the work isn't finished yet... :-)
>

Yep known about and working on it.  Will have them fixed for the next build.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: 13.1.0 build 29 for XO-4 released

[Jon Nettleton]

On Feb 12, 2013 2:43 PM, "Walter Bender"  wrote:
>
> On Tue, Feb 12, 2013 at 8:41 AM, Simon Schampijer 
wrote:
> > On 02/11/2013 08:59 PM, Daniel Drake wrote:
> >>
> >> Hi,
> >>
> >> Another XO-4 only build for 13.1.0:
> >> http://download.laptop.org/xo-4/os/candidate/13.1.0-29/
> >>
> >> Changes are:
> >>   - Improved power saving in graphics and other areas
> >>   - Latest wake-on-WLAN developments
> >>   - A potential fix for loss of mouse on boot (#12101)
> >>   - Latest EC code
> >>   - Wikipedia works when offline (#12479)
> >>
> >> Thanks
> >> Daniel
> >
> >
> > The most obvious issue I saw after booting the machine was that the
Sugar
> > cursor was corrupted. At the left side there was some artifact. After
reboot
> > the cursor was fine. A known issue?
>
> FWIW, I saw that on os28 as well.
>
>
This is a known issue. Next release will have a better fix.

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

Re: XO-4 lack of keyboard/mouse input - still happening?

[Jon Nettleton]

If you see this again can you please attach the output of
/proc/interrrupts.  Thanks

On Fri, Feb 1, 2013 at 5:58 PM, Emiliano Pastorino
 wrote:
> Hit this issue today. Both keyboard and touchpad missing.
> XO-4 B1, OFW Q7B14, EC 0.3.10, os28.
>
> Same kernel messages:
>
>> psmouse serio1: Failed to deactivate mouse on olpc_touchpad/serio0
>> psmouse serio1: Failed to enable mouse on olpc_touchpad/serio0
>>
>> atkbd serio0: keyboard reset failed on olpc_keyboard/serio0
>
>
>  Didn't need to remove power, I just rebooted the XO.
>
>
>
>
>
> On Tue, Jan 29, 2013 at 2:48 PM, John Watlington  wrote:
>>
>>
>> On Jan 29, 2013, at 11:45 AM, Jon Nettleton wrote:
>>
>> > On Tue, Jan 29, 2013 at 5:40 PM, Daniel Drake  wrote:
>> > On Tue, Jan 29, 2013 at 10:34 AM, Jon Nettleton
>> >  wrote:
>> > > I have seen this problem on both my machines today while testing.
>> > > Sometimes
>> > > just keyboard, sometimes touchpad, sometimes both.  I found that if my
>> > > machine was in this state and I suspend it, resume would hang at
>> > > ec_irq on
>> > > the console.  The only fix was powering off and removing plug and
>> > > battery.
>> >
>> > Which OS build (any custom kernel?), OFW and EC firmware versions?
>> > Touchpad type? Any kernel logs saved?
>> >
>> >
>> > OS build is os26, OFW is Q7B12mb EC is 0.3.10
>> >
>> > Touchpad is Sentelic, no kernel logs.
>>
>> Somewhere in the tickets I noted that I saw this problem with both
>> touchpad types.
>>
>> wad
>>
>> ___
>> Devel mailing list
>> Devel@lists.laptop.org
>> http://lists.laptop.org/listinfo/devel
>
>
>
>
> --
> Ing. Emiliano Pastorino
> Centro Ceibal
> Av. Italia 6201 Ed. Los Ceibos
> Montevideo, Uruguay
> Tel: (598) 2601 5773 int.: 2232
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: XO-4 lack of keyboard/mouse input - still happening?

[Jon Nettleton]

On Tue, Jan 29, 2013 at 5:40 PM, Daniel Drake  wrote:

> On Tue, Jan 29, 2013 at 10:34 AM, Jon Nettleton 
> wrote:
> > I have seen this problem on both my machines today while testing.
>  Sometimes
> > just keyboard, sometimes touchpad, sometimes both.  I found that if my
> > machine was in this state and I suspend it, resume would hang at ec_irq
> on
> > the console.  The only fix was powering off and removing plug and
> battery.
>
> Which OS build (any custom kernel?), OFW and EC firmware versions?
> Touchpad type? Any kernel logs saved?
>
>
OS build is os26, OFW is Q7B12mb EC is 0.3.10

Touchpad is Sentelic, no kernel logs.

Both my B1 and C1 have the same config.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: XO-4 lack of keyboard/mouse input - still happening?

[Jon Nettleton]

On Tue, Jan 29, 2013 at 5:28 PM, Paul Fox  wrote:

> daniel wrote:
>  > Hi,
>  >
>  > In recent months we have seen some issues with the XO-4 keyboard and
>  > mouse, where the system would boot (or resume from suspend?) and not
>  > respond to keyboard/mouse input (and/or respond to keyboard input in a
>  > very lagged manner).
>  >
>  > This problem may have been accompanied with kernel messages like:
>  > psmouse serio1: Failed to deactivate mouse on olpc_touchpad/serio0
>  > psmouse serio1: Failed to enable mouse on olpc_touchpad/serio0
>  > psmouse serio1: sentelic: Unable get OPC state.
>  > atkbd serio0: keyboard reset failed on olpc_keyboard/serio0
>  >
>  > and corresponds to tickets:
>  > #12101 cl4: touchpad missing after reboot
>  > #12370 No mouse interaction possible after bootup
>  >
>  > Has anyone seen these problems or the possibly-related kernel messages
>  > on recent builds such as 13.1.0 build 27 with the latest firmware?
>  >
>  > I previously saw it fairly regularly on my two XO-4s but I can't
>  > recall seeing it recently. Additionally, we would sometimes get those
>  > kernel messages during shutdown, and those messages have now gone
>  > away, so I'm wondering if we have fixed these issues while working on
>  > related things.
>
> i wish i could point to an EC or kernel fix that i'm aware of that
> would have made it go away, but i can't.  i agree that i don't recall
> seeing it lately.
>
>
I have seen this problem on both my machines today while testing.
 Sometimes just keyboard, sometimes touchpad, sometimes both.  I found that
if my machine was in this state and I suspend it, resume would hang at
ec_irq on the console.  The only fix was powering off and removing plug and
battery.

My guess is this is a timing problem as after I removed a bunch of debug
messages from my S/R functions I stopped having the problem.

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

Re: 13.1.0 development build 19 released

[Jon Nettleton]

Type D to Type A is correct.

http://www.amazon.com/Micro-Cable-Amazon-Kindle-Tablet/dp/B009A4B6YG/ref=sr_1_10?ie=UTF8&qid=1355846611&sr=8-10&keywords=micro-hdmi+to+hdmi+cable

obviously you can't buy from there, but that is the cable you want.

Jon


On Tue, Dec 18, 2012 at 5:02 PM, Manuel Kaufmann  wrote:

> On Tue, Dec 18, 2012 at 12:48 PM, Paul Fox  wrote:
> > remember that as discussed yesterday on the devel@ list, there are
> > some caveats regarding HDMI on B1 units.
>
> Ok. Hopefully, I will get a C1 next week.
>
> I'm a bit confused regarding the cable that I need. If I understand
> property, I need a Type D ---> Type A HDMI cable. But this line made
> me think different (from Type D Wikipedia's description):
>
> "The pin assignment is different from Type A or C."
>
> So, is it not possible to have a Type D on one side and a Type A on
> the other side?
>
> --
> Kaufmann Manuel
> -- http://mkaufmann.com.ar
> ___
> Devel mailing list
> Devel@lists.laptop.org
> http://lists.laptop.org/listinfo/devel
>
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: 13.1.0 development build 19 released

[Jon Nettleton]

On Tue, Dec 18, 2012 at 4:40 PM, Manuel Kaufmann  wrote:

> On Sun, Dec 16, 2012 at 1:40 PM, Daniel Drake  wrote:
> > XO-4 now has HDMI support in Linux (#12350). Other kernel fixes:
>
> Is there some "user guide" about this?
>
> I mean, what I need to know to make this work? I have a 32'' LED TV
> and a 23'' LCD Monitor that I would like to try with the XO-4 HDMI
> output. Both, the TV and the monitor have this kind of connector[1].
>
> So, should I just need a cable with a mini-HDMI on one side (to be
> connected in the XO) and a "common" HDMI connector on the other side
> (to be connected into the TV or Monitor)?
>
>
The cable you need is micro-HDMI to HDMI.  As a general rule, HDMI
connectors can roughly be broken down like this.

full size HDMI - Displays, Set-top boxes (cable, blue-ray, etc), full-size
desktops and laptops.
mini HDMI - Digital camcorders (there are some other oddball hardware but
very rare)
micro HDMI - smart phones, tablets, laptops

Then if your monitor or TV supports 720p, 1080p, or another CEA standard
resolution then things should just work.

Note: If you have a B1 XO4 then you will need to cut back the jacket on the
micro-hdmi end of the cable so it can plug further into the chassis.

Hope that helps.

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

Re: 13.1.0 development build 19 released

[Jon Nettleton]

On Mon, Dec 17, 2012 at 7:22 PM, Anna  wrote:

> hdmi_hpd_work state 4000 hdmi_state 0


Hot plug detection is working, but all those handlers means there is
significant jitter in the connection.  hdmi_state 0 means that no stable
connection could be detected, so linux won't even setup the connection.

You may have better luck by cutting a mm or two off from the end of the
micro-hdmi connector's jacket.  This will allow the connector to plug in
further and possibly make a stable connection.

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

Re: 13.1.0 development build 19 released

[Jon Nettleton]

On Mon, Dec 17, 2012 at 6:13 PM, Anna  wrote:

>
>
> On Mon, Dec 17, 2012 at 11:00 AM, Paul Fox  wrote:
>
>> anna wrote:
>>  > On Sun, Dec 16, 2012 at 10:40 AM, Daniel Drake  wrote:
>>  >
>>  > >
>>  > > XO-4 now has HDMI support in Linux (#12350).
>>  > >
>>  >
>>  > Once of the perks of having an AV contractor in the house is that it
>> wasn't
>>  > hard to dig up the proper HDMI adaptor.  Still mostly the same issue as
>>  > build 18 as noted in #12350, but under build 19 there's no HDMI output
>> at
>>  > all after entering boot instead of the TV hanging on the OFW screen
>> while
>>  > the XO boots.
>>  >
>>  > I tried both 720p and 1080p.
>>
>> i can't tell if you're not getting signal at all, or just in OFW.
>>
>
>
> Sorry, I guess I wasn't clear.  I am getting HDMI signal in OFW, but the
> second it boots to Linux, my TV reports it doesn't have signal.
>

This will always happen as the clocks get reset and the signal needs to be
resynced.

>
>
>>
>> if the former, and you're using a B1 unit (and i assume you are), then
>> there's a good chance that the cable isn't making contact properly.
>>
>
> I do have a B1 unit, but since I'm getting signal in OFW, that would mean
> the connection is fine.
>

Not necessarily.  There are many pins associated with hdmi.  You may be
able to generate a signal that works, but the linux connection relies on
being able to read the EDID information from the television as well.
 Without logs we can only guess what is going on.

>
>
>> if the latter, and you have signal in OFW but not linux, be sure your
>> upgrade to q7b09 was successful.  linux hdmi won't work without it.
>>
>>
> Yes, the firmware upgrade to q7b09 was successful.  I just doublechecked
> it to be sure.  Has anyone else tested this yet?
>

The B1's have flaky hdmi connectivity at best.  Not only were there jack
location problems that needed to be addressed, but they were susceptible to
ESD causing a failure in the hot-plug detection circuit.  These are both
reasons why HDMI would fail to work  under Linux.

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

Re: HDMI audio on XO-4

[Jon Nettleton]

On Thu, Dec 6, 2012 at 5:31 AM, Sridhar Dhanapalan wrote:

> Does the micro-HDMI port on the XO-4 transmit audio?
>
>
Not yet but it will.  We were waiting for the audio driver to stabilize.

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

Re: HDMI port

[Jon Nettleton]

On Sun, Dec 2, 2012 at 2:07 PM, Samuel Greenfeld wrote:

> The connector on XO-4 B1 motherboards is a bit further in than it should
> be.  You might not be able to establish a reliable connection to it without
> increasing the size of the opening in the case.
>
> The connector on XO-4 C1 motherboards has been moved a bit further out.
>
> In terms of using the smaller connector, for users upgrading motherboards,
> there has been discussion about including an adapter to make the existing
> hole for a third USB port micro HDMI-size.  I have not seen one of these
> adapters yet so I cannot comment much about it.
>
>
> On Sun, Dec 2, 2012 at 5:06 AM, Sameer Verma  wrote:
>
>> I was looking for a cable for the micro HDMI port on the XO4. I couldn't
>> find it locally, so I bought it online. The connector is similar to a micro
>> USB on my phone (size wise) but after plugging it into the XO, I realized
>> that the connector is very flimsy. I suppose the bit sticking inside the XO
>> doesn't feel robust enough to forgive any major movement of the cable on
>> the outside.
>>
>> A type A HDMI cable connector seems to be quite robust, like a USB A
>> connector. What was the thinking behind picking a micro HDMI connector?
>>
>> A regular HDMI connector seems more robust and easily available (my
>> experience...yours may vary).
>>
>> cheers,
>> Sameer
>>
>>
Micro-HDMI is the de-facto mobile internet HDMI connector.  Obviously part
of that is due to size, but I also feel that the connection was designed to
stand up to use in a device that can be moved around a lot, i.e. Mobile
Phone, or Tablet.  I think you see this in how the connectors are built.
 Because the connection itself is smaller it allows the cable manufacturers
to make the plastic cover for the plug thicker.  This gives additional
support against the outside of the case and helps minimize the force that
is put on the connection between the micro-hdmi port and the motherboard
when the plugs is levered.

Personally I like the micro-hdmi connector because it also stands out and
makes it obvious that it is not another USB port.

I am sure the hardware team will have a lot of other more technical reasons
for the choice.  These are just my personal viewpoints about why I liked
the choice of a Micro-HDMI port vs. a Full size port.

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

Re: [Sugar-devel] OLPC OS on Zync Z930 Tablet

[Jon Nettleton]

On Fri, Nov 23, 2012 at 10:01 AM, Peter Robinson wrote:

> On Fri, Nov 23, 2012 at 5:51 AM, Johnson Chetty 
> wrote:
> > Hey,
> >
> > Yes... we're working on getting Sugar on the tablet form factor.
> > We're looking at compiling Sugar for an armv7 chip based tablet.
> (Allwinner
> > A10 chip- armhf ). There are many cheap tablets flooding the market here
> in
> > India, so we thought it is a good idea to get Sugar on them.
> > Would be quite cost effective, (not in the long run though, none of them
> are
> > as sturdy as the XOs)
> > Getting the touch screen  and multi-touch capabilities in linux are
> > seemingly a problem here.
> > If anyone is working on the linux/environment configuration for the new
> XOs,
> > would love to get some technical guidance for this..
>
> Sugar is already compiled and known working for ARMv7 hardfp via the
> Fedora project and downstream OLPC. The Fedora stack would happily
> work on this device and all we would need is a kernel, a Xorg driver
> as possibly a touchscreen driver. If the tablet is based on the
> AllWinner A1x CPUs I'm already working on getting Fedora support so it
> shouldn't be hard to extend the support to the tablet.
>
> All the userspace is already done as you can use the existing Fedora
> ARMv7 hardfp userspace without any problems.
>
> There's probably better places to discuss this as it's kind of
> offtopic for this list. Archives and details to subscribe to the
> Fedora ARM list are here [1]
> https://admin.fedoraproject.org/mailman/listinfo/arm


That SOC uses a Mali400 I believe.  Xorg drivers do exist for it.

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

Re: qemu & wine experiments on ARM

[Jon Nettleton]

On Fri, Oct 5, 2012 at 4:09 PM, Martin Langhoff  wrote:
> On Fri, Oct 5, 2012 at 10:02 AM, Jon Nettleton  
> wrote:
>> I have tested that patch already and it does not fix it with the current
>> codebase.  I believe you need to get qemu 0.14.1 to use that patch for
>> success.
>
> Oh, grumble -- the discussion around it in the ml was not encouraging.
>
> It's not the only patch, however, this one might be better:
> http://lists.gnu.org/archive/html/qemu-devel/2009-08/msg01041.html
>

We tried that one to no avail the other night as well :-(

This can't be that difficult will just take some more poking I think
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: qemu & wine experiments on ARM

[Jon Nettleton]

On Fri, Oct 5, 2012 at 3:53 PM, Martin Langhoff  wrote:
On Fri, Oct 5, 2012 at 6:53 AM, Reuben K. Caron wrote: 
> [reuben@koji3 ~]$ proot -Q wine/qemu-i386 mock/ 
> proot info: started 
> sh-4.2$ ls 
> sh: fork: Invalid argument 
> sh-4.2$ 

ok, so that's the fork . Avenues I can suggest. 

- The proot folks have their own (old) qemu-user rpms. Maybe there's 
a fixup in there. Grab them from the same dir I published proot in. 

- Perhaps there is an NPTL bug (which I thought was stale, old info) 
affecting fork(). If that's so, people claim that this patch 
http://patchwork.ozlabs.org/patch/45206 fixes it. You'll want to 
recompile qemu-user with this patch. 

I have tested that patch already and it does not fix it with the current 
codebase.  I believe you need to get qemu 0.14.1 to use that patch for success.

I also don't have any time for this today, but it is on my "things of interest 
to do in spare time when wife allows it list"  Hopefully this weekend.

Jon

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

Re: XO-1.5 graphics clock control causes instability

[Jon Nettleton]

On Mon, Sep 24, 2012 at 2:20 PM, Daniel Drake  wrote:
> Hi,
>
> A couple of months ago, we ran an XO-1.5 suspend/resume test outside
> of X and found that it would frequently fail to resume. Upon resume,
> the system would spontaneously reboot. No kernel messages were printed
> during the resume process over serial, only "+X" or "+r+X" which is
> OpenFirmware saying "memory contents are bad, I can't figure out how
> to resume"
>
> This was filed as #12039.
>
> Wad suggested that the most likely cause is memory rot, probably
> caused by some device accessing main memory (e.g. with DMA) while the
> CPU was asleep. This will bring the memory out of self-refresh and
> since the CPU is asleep, the memory contents would then be lost.
>
> I've investigated this and I have a workaround (accepted upstream,
> pushed for next build). Since its an odd issue and likely to bite
> again at some point, here are the details:
>
> viafb recently started tweaking the state of the primary (IGA1) and
> secondary (IGA2) clocks and PLLs (e.g. in commit b692a63af8b6).
> It is the tweaking of the clock state that causes instability. The
> clocks in question are configured by IO Port 3C5.1B ("Power Management
> Control 1"), bits 5:4 (IGA1) and 7:6 (IGA2).
>
> These clocks can be configured in 3 ways:
>  1. Always on
>  2. Always off
>  3. Clock auto on/off according to power management status (default)
> (it's not clear what the definition of "power management status" is)

I am pretty sure that the Power Management Status is referring to the
ACPI Power Management Status.  If we are setting our config to the
"auto" mode then we should probably not be disabling the clock
manually.  I would assume that the hardware should disable the clock
properly depending on the ACPI state it is put into.  We should
probably have this wrapped around an ifdef CONFIG_ACPI or
something like that.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Fixing GNOME3 "regressions" in 13.1.0

[Jon Nettleton]

On Sep 21, 2012 10:11 PM, "Martin Langhoff" 
wrote:
>
> On Fri, Sep 21, 2012 at 3:46 PM, Daniel Drake  wrote:
> > Its not really clear what they want on that ticket. If they just want
> > the nautilus-driven desktop back, its easily doable.
>
> I believe that that's what they want. Others have definitely
> complained about the regressions (or "lockdown") of our GNOME desktop.
>
> I also observe that "how do I return to Sugar?" used to be visibly
> obvious, and now it is fairly hidden.
>
> > But its not clear to me if we want to do that by default (is that what
> > you are suggesting?).
>
> Yes, that's what I am proposing, and yes, I think we want it.
>
> We will also need to tweak the height of top and bottom bar (and of
> the buttons therein) to make them useful in a Touch UI.
>

Does it make sense to use some of the tweaks that Ubuntu used for their old
netbook ui? Having "touchable" panels top and bottom is really goin to use
up valuable screen space. Probably a top panel with buttons for each open
app would make better use of screen real estate.

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

Re: sketchometry

[Jon Nettleton]

On Tue, Sep 18, 2012 at 9:24 AM, John Watlington  wrote:
>
> It runs.  The UI is non-intuitive enough that I didn't get very far.
>
> How can an HTML5 app be closed source ?  It may not
> be free, and you may not be able to redistribute it, but it is HTML...

My guess is that all the heavy lifting is done on the backend and passed
back to the browser via WebSockets.  Haven't taken a look yet though

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

Re: [Sugar-devel] "glibc-devel" F14 package for armv5tel

[Jon Nettleton]

On Thu, Jul 12, 2012 at 10:09 PM, Ajay Garg  wrote:
> Thanks Jon for the reply.
>
> Here is the output ::
>
>
> #
> [olpc@xo-c5-b9-6c rpmbuild]$ sudo yum list glibc*
>
> Loaded plugins: downloadonly
> Installed Packages
> glibc.armv5tel 2.13-2.1   @koji.dist-f14-armv5tel/$releasever
> glibc-common.armv5tel  2.13-2.1   @koji.dist-f14-armv5tel/$releasever
> #
>

Oh that is very strange because the package does exist there.
http://mock.laptop.org/repos/koji.dist-f14-armv5tel/RPMS

perhaps you should try a sudo yum clean all, then sudo yum list 'glibc*'

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

Re: [Sugar-devel] "glibc-devel" F14 package for armv5tel

[Jon Nettleton]

On Thu, Jul 12, 2012 at 9:44 PM, Peter Robinson  wrote:
> On Thu, Jul 12, 2012 at 8:16 PM, Ajay Garg  wrote:
>>
>>
>> On Fri, Jul 13, 2012 at 12:39 AM, Peter Robinson 
>> wrote:
>>>
>>> On Thu, Jul 12, 2012 at 12:47 PM, Ajay Garg 
>>> wrote:
>>> > Hi all.
>>> >
>>> > I am trying to build "avahi" on my XO-1.75.
>>> >
>>> > Building "avahi" requires "glibc-devel" as one of its dependent
>>> > packages.
>>> >
>>> > Very, very surprisingly, there is no "glibc-devel" present in the ARM
>>> > repos
>>> > (for armv5tel/armv7tel) !!
>>> >
>>> >
>>> > I have tried building the "glibc" packages from the source-rpm, but even
>>> > that fails,  with no error message :\
>>> > Heck, building "glibc" packages fail even on x86 !!
>>> >
>>> >
>>> > So,
>>> > I would request everyone, if someone could point-me-to/give-me a
>>> > "glibc-devel" rpm for ARM, being used in the OLPC/sugar ecosystem, as I
>>> > believe that "glibc-devel" is a very fundamental package (or at least
>>> > that
>>> > is what the "glibc.spec" file says).
>>> >
>>> >
>>> >
>>> >
>>> > For brevity,
>>> >
>>> > a)
>>> > [olpc@xo-c5-b9-6c rpmbuild]$ rpm -qa | grep glibc
>>> >
>>> > glibc-common-2.13-2.1.armv5tel
>>> > glibc-2.13-2.1.armv5tel
>>> >
>>> >
>>> >
>>> >
>>> > b)
>>> > [olpc@xo-c5-b9-6c rpmbuild]$ uname -a
>>> >
>>> > Linux xo-c5-b9-6c.localdomain 3.0.19_xo1.75-20120321.1512.olpc.1398916
>>> > #1
>>> > PREEMPT Wed Mar 21 16:04:14 EDT 2012 armv7l armv7l armv7l GNU/Linux
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> > Thanks in advance..
>>>
>>> Have you tried "yum install glibc-devel"? Have you enabled the fedora
>>> repositories in the yum config if they're not?
>>
>>
>> Of course yes.
>>
>> If you have the glibc-devel package that I need, please provide it to me.
>
> It's in the fedora repositories.

Please verify your date and time are up to date.  Having an incorrect
system time can cause
the SSL verification on the yum repo get to fail.  Also if you can not
install glibc-devel via yum
please post the output of yum list 'glibc*' so we can evaluate it.  We
obviously want to fix this
if it is a problem.

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

Re: [Sugar-devel] How to disable "Authentication Required By Wireless Network" popup in Fedora 17

[Jon Nettleton]

On Thu, Jun 21, 2012 at 3:52 PM, Ajay Garg  wrote:
>
>
> On Thu, Jun 21, 2012 at 9:23 AM, James Cameron  wrote:
>>
>> On Wed, Jun 20, 2012 at 11:29:37PM -0400, Paul Fox wrote:
>> >
>> > ajay wrote:
>> >  > Hi Paul.
>> >  >
>> >  > Well, I am doing development on sugar-jhbuild F17.
>> >  >
>> >  > So, after I launch sugar-emulator, I wish to have the sugar
>> >  > network-authentication popup pop up (if at all), and not the gnome
>> > one.
>> >
>> > ah.  sugar vs.  gnome.  now that i understand your problem, i find i
>> > can be of no help whatsoever.  sorry!
>>
>> Indeed, I have no idea either.  Running GNOME at the same time as
>> Sugar means NetworkManager might behave differently, as it has
>> multiple clients.  So I never wanted to try that.  Because it would
>> not be representative of the typical usage.
>
>
> Exactly 

This functionality was just introduced in F17, NetworkManager 0.9.x.
Previously you could only have one client connected to the
NetworkManager daemon at a time.  Now the behavior has changed
to make it work better with fast-user-switching.

This new connection sharing also causes secrets to be handled
differently.  Previously everything was stored in your gnome-keyring,
now by default secrets are stored at the system level.  A client
can register to be a secrets provider however I don't know if this has
been implemented in sugar yet.


>>
>>
>> When I was last testing Sugar and NetworkManager interaction, I did it
>> on a system, such as an XO, without GNOME running.  I edited the
>> source files live and restarted Sugar to see the changes.  When I had
>> finished, I copied my changes out of the target and into git using ssh.
>
>
> Well, that would indeed work. Thanks for the idea .. :D :D

I may have more information about this this weekend.  I currently
have an unstable network connection and the NetworkManager
password popups are annoying me.  If I find anything interesting
I will update everyone.

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

Re: [Techteam] 12.1.0 devel build 13 released, for the XO-1, XO-1.5 and XO-1.75

[Jon Nettleton]

On Tue, Jun 12, 2012 at 7:34 PM, Martin Langhoff  wrote:
> On Tue, Jun 12, 2012 at 1:04 PM, Peter Robinson  wrote:
>> I was just going on the logs from git and we have 2.0.13 and according
>> to the logs 2.0.13 was post that commit, but it seems it wasn't tagged
>> so I assume 2.0.13 is the same as 2.0.12 then
>>
>> http://dev.laptop.org/git/projects/olpc-utils/
>
> I think you have some other commit in mind. From 2.0.12 to 2.0.13 you
> have one commit that enables render accel, that is in xorg.conf.
> That's not what we were after, we were after a udev rule that allows
> talking to the device nodes that the vmeta implementation exposes.
>
> No problem. Just material for the next build ;-)

Speaking of next builds, is there an ETA?

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

Re: 12.1.0 devel build 13 released, for the XO-1, XO-1.5 and XO-1.75

[Jon Nettleton]

On Jun 8, 2012 3:07 PM, "Peter Robinson"  wrote:
>
> On Fri, Jun 8, 2012 at 1:58 PM, Jon Nettleton 
wrote:
> >
> > On Jun 8, 2012 2:53 PM, "Peter Robinson"  wrote:
> >>
> >> The "The life of a dreamer, the days of a business, and the nights in
> >> between." release.
> >>
> >> This is the end of the development cycle. We're now headed into the
> >> stabilisation and bug fixing phase.
> >>
> >> http://wiki.laptop.org/go/12.1.0/Release_plan
> >>
> >> Fixed bugs:
> >> #10040  we don't use all available SD card space
> >> #11819  sisusb support broken on 12.1.0/os8
> >> #11878  gnome battery icon unresponsive
> >> #11832  OLPCRoot mounted on /run/media/olpc/OLPCRoot
> >> #6670   Userspace power manager needs to know about the audio device
state
> >> #11920  Update Image Viewer to version 21 in 12.1.0
> >> #11765  UL Warning screen not shown on shutdown on 12.1.0
> >> #11895  udev rule for Butia robots
> >> #11890  Please update Portfolio to Version 25
> >> #11916  Update Fototoon to version 13 in 12.1.0
> >> #11917  Update Maze to version 20 in 12.1.0
> >> #11911  Physics: grab objects crashes the activity
> >> #11914  Update Speak to version 41 in 12.1.0
> >> #11781  Alt+click does not work in home view to start new
> >> #11912  Activity strings in global scope go untranslated
> >> #11816  First Sugar boot - simple welcome screen
> >> #11829  Sugar speech feature in os8 does not allow work other
> >> gstreamer-espeak instances
> >> #11691  Give feedback during activity saving process
> >> #11894  Please update TurtleBlocks to Version 140
> >> #11837  wikipedia activity slow to start
> >> #11892  Add Wikipedia 34 to 12.1.0 image
> >>
> >> Activity changes:
> >> +Chart-5
> >> -FotoToon-12
> >> +FotoToon-13
> >> -ImageViewer-20
> >> +ImageViewer-21
> >> -Log-28
> >> +Log-29
> >> -Maze-18
> >> +Maze-20
> >> -Physics-9
> >> +Physics-10
> >> -Portfolio-21
> >> +Portfolio-25
> >> -SimpleGraph-3
> >> -Speak-38
> >> +Speak-41
> >> -TurtleArt-140
> >> +TurtleArt-143
> >> -Welcome-3
> >> +Welcome-5
> >> -Wikipedia-34
> >> +Wikipedia-35
> >> -WikipediaEN-33.5
> >> +WikipediaEN-35
> >>
> >
> > Did we get the change to olpc-utils enabling hardware rendering on the
xo
> > 1.75?
>
> Yep, according to the olpc-utils git repo it should have been in
> 2.0.13 which we have, it seems either didn't have a trac ticket or it
> wasn't in my queue/

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

Re: 12.1.0 devel build 13 released, for the XO-1, XO-1.5 and XO-1.75

[Jon Nettleton]

On Jun 8, 2012 2:53 PM, "Peter Robinson"  wrote:
>
> The "The life of a dreamer, the days of a business, and the nights in
> between." release.
>
> This is the end of the development cycle. We're now headed into the
> stabilisation and bug fixing phase.
>
> http://wiki.laptop.org/go/12.1.0/Release_plan
>
> Fixed bugs:
> #10040  we don't use all available SD card space
> #11819  sisusb support broken on 12.1.0/os8
> #11878  gnome battery icon unresponsive
> #11832  OLPCRoot mounted on /run/media/olpc/OLPCRoot
> #6670   Userspace power manager needs to know about the audio device state
> #11920  Update Image Viewer to version 21 in 12.1.0
> #11765  UL Warning screen not shown on shutdown on 12.1.0
> #11895  udev rule for Butia robots
> #11890  Please update Portfolio to Version 25
> #11916  Update Fototoon to version 13 in 12.1.0
> #11917  Update Maze to version 20 in 12.1.0
> #11911  Physics: grab objects crashes the activity
> #11914  Update Speak to version 41 in 12.1.0
> #11781  Alt+click does not work in home view to start new
> #11912  Activity strings in global scope go untranslated
> #11816  First Sugar boot - simple welcome screen
> #11829  Sugar speech feature in os8 does not allow work other
> gstreamer-espeak instances
> #11691  Give feedback during activity saving process
> #11894  Please update TurtleBlocks to Version 140
> #11837  wikipedia activity slow to start
> #11892  Add Wikipedia 34 to 12.1.0 image
>
> Activity changes:
> +Chart-5
> -FotoToon-12
> +FotoToon-13
> -ImageViewer-20
> +ImageViewer-21
> -Log-28
> +Log-29
> -Maze-18
> +Maze-20
> -Physics-9
> +Physics-10
> -Portfolio-21
> +Portfolio-25
> -SimpleGraph-3
> -Speak-38
> +Speak-41
> -TurtleArt-140
> +TurtleArt-143
> -Welcome-3
> +Welcome-5
> -Wikipedia-34
> +Wikipedia-35
> -WikipediaEN-33.5
> +WikipediaEN-35
>

Did we get the change to olpc-utils enabling hardware rendering on the xo
1.75?

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

Re: XO battery/performance

[Jon Nettleton]

On Sat, Jun 2, 2012 at 3:12 AM, Samuel Greenfeld  wrote:
> On Fri, Jun 1, 2012 at 8:07 PM, Richard A. Smith  wrote:
>>
>> On 05/30/2012 03:34 AM, Yioryos Asprobounitis wrote:
>>
>>> Most of the test had empty values but the informative ones (below) show
>>> that the XO-1.5 is better in basic integer operations and memory bandwidth
>>> while the XO-1.75 is better in float and double operations as well as in
>>> memory latency.
>>> I'm not sure how much this means for real life usage :-/
>>
>>
>> I'm very suspect of this measurement.  The 1.5 has a hardware floating
>> point unit and the 1.75 is still using soft-float.  Its extremely unlikely
>> that the floating point performance on 1.75 is better than the 1.5.
>
>
> Hard FP status depends on if Yioryos is running 11.3.1 or 12.1.0.  Since he
> said "os10" by today's date I'm presuming 12.1.0.
>
> The Fedora 17 builds should be hard fp (armv7hl).  The Fedora 14-based
> 11.3.1 builds are not (armv5tel / armv7l kernel).

Looking at those numbers I am quite certain that he is using F17 and
hardfp on the 1.75.  Floating Point performance of the VIA vx855
chipset is a known limitation.  It is something that they fixed in the
next generation vx900 chipset.

As for the integer math.  Most the simple integer benchmarks come down
to clock frequency and integer pipelines, both of which the x86
processor beats the ARM on.  Theoretically these operations could be
faster on our ARM processor as it has dual issue instructions, meaning
some instructions can be handled by the core at the same time.  I
don't think we are taking full advantage of this functionality as I
believe gcc needs to be told about it and then software recompiled
with the proper tuning options.  That patch was just submitted by
Marvell upstream, and we still have to test it.

Once I get everything built I will try to run some tests to compare
against your results, or possibly provide some binaries you can run on
your system.

Overall I believe the ARM chipset is a win on all fronts.  Yes it
doesn't blow away the previous generation on raw processing power but
really the proper metric to look at in our usage scenario is
processing per watt.  On top of that the ARM SOC is able to do things
like encode/decode 720p video using a special DSP.  One of the design
principles of ARM is to not make a single chip that does everything
really fast, but instead combine a group of specialized chips that are
efficient at what they do yet provide a good overall computing
experience.

Thanks for the numbers, it should be good to revisit this as we move
forward with other optimizations.

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

Re: XO battery/performance

[Jon Nettleton]

*snip*
http://lists.laptop.org/pipermail/devel/2012-May/035198.html ) I also
tried to test the XO-1(os880), XO-1.5(os883) and -1.75(os10) battery
life and thought to report it. It might be of help to someone.

os10 is very much a development release and not great for testing.  In
particular graphics acceleration was not working properly, so this
test is strictly testing the cpu.

*snip*

> I can appreciate that this is far from a CPU/computer performance test but 
> taking counts just as an *indication* of CPU/FPU performance would imply that 
> the XO-1.75 is 65% faster than the XO-1 but 40% slower(?) than the XO-1.5.

see above reasoning as to why this is an incorrect assumption.
Although the XO 1.75 will be slightly slower than an XO 1.5 in this
test as it is primarily doing glyph compositing in the terminal.  The
XO 1.5 hardware supports compositing the A8 format via the 3d engine,
while the XO 1.75 only supports rgb565 and argb in hardware so a
lot of the compositing functions will fall back to software.  We are
helping to speed up this fallback by enabling iwmmxt optimizations in
pixman.

> Considering counts/discharge however, the XO-1.75 appears 33% more efficient 
> than the XO-1.5 and 320%(!) more efficient than the XO-1
>
> One thing I noticed is that while on the XO-1 and XO-1.5 the output was a 
> constant stream of new lines without and "hesitations" and the cursor barely 
> visible, on the XO-1.75 were "hesitations" and the cursor was appearing at 
> the end of the line during these "hiccups".

These hiccups are probably due to the lack  of hardware acceleration.
However because  the SOC does do more rendering I have also been
experimenting with increasing the buffer for libxcb to help prevent
hiccups between the Xclients and Xserver.

OS12 should be a better image to test on the XO 1.75.

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

Re: #11744 BLOC 12.1.0: Reminder: Disable varios _DEBUG=y flags in defconfig before shipping

[Jon Nettleton]

Done

On Wed, May 23, 2012 at 8:59 PM, Zarro Boogs per Child
 wrote:
> #11744: Reminder: Disable varios _DEBUG=y flags in defconfig before shipping
> ---+
>           Reporter:  martin.langhoff  |       Owner:  dsd
>               Type:  defect           |      Status:  new
>           Priority:  blocker          |   Milestone:  12.1.0
>          Component:  not assigned     |     Version:  not specified
>         Resolution:                   |    Keywords:
>        Next_action:  never set        |    Verified:  0
> Deployment_affected:                   |   Blockedby:
>           Blocking:                   |
> ---+
> Changes (by dsd):
>
>  * cc: jnettlet (added)
>
>
> Comment:
>
>  Reviewed them all and disabled a few.
>
>  Jon, is CONFIG_CMA_DEBUG ok to disable?
>
>  {{{
>  Turns on debug messages in CMA.  This produces KERN_DEBUG               │
>  messages for every CMA call as well as various messages while           │
>  processing calls such as dma_alloc_from_contiguous().                   │
>  This option does not affect warning and error messages.
>  }}}
>
>  If so, please disable it and push. If not, please close this bug as fixed.
>
> --
> Ticket URL: 
> One Laptop Per Child 
> OLPC bug tracking system
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [Sugar-devel] Wanting to know a bit of (NetworkManager) workflow upon resume-from-suspend

[Jon Nettleton]

On Wed, May 2, 2012 at 10:42 AM, Martin Langhoff
 wrote:
> On Wed, May 2, 2012 at 4:07 AM, Martin Abente
>  wrote:
>> I think (guessing by the responses) the original problem here is that, if
>> you disable the mesh AFTER NM has taken the device, NM crashes. This a
>> regression bug, considering that this didn't happened in fedora-11 based
>> builds.
>
> The timings in F11 builds were completely different. Maybe you were
> winning the race that you're now losing.
>
>> So the solution here is to find another place to place the script, where it
>> guarantee that the script will be executed before NM does its job at resume
>> time.
>
> udev script :-) -- I am pretty sure you can number yourself lower (to
> run earlier) than the udev script that fires off the "new device"
> event to NM.
>
>> Another solution is to find out why NM crashes now and why didn't before,
>> but I wouldn't go that way.
>
> Making NM completely resilient to these race conditions is probably a hard 
> task.

This is also a temporary solution.  There is a kernel patch in 3.1 and
greater kernels that allows you to disable mesh as a kernel module
parameter.

I just played around with the udev script and there definitely seems
to be some timing issues even with that.

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

Re: Wanting to know a bit of (NetworkManager) workflow upon resume-from-suspend

[Jon Nettleton]

One thing I forgot to add.  You can use the standard udi format to
specify devices. i.e  /org/freedesktop/NetworkManager/Devices/0

On Sun, Apr 29, 2012 at 11:34 AM, Jon Nettleton  wrote:
> On Sun, Apr 29, 2012 at 10:04 AM, Martin Abente
>  wrote:
>> Are you guys still using this?
>> http://git.sugarlabs.org/dextrose-platform/mainline/blobs/master/etc/powerd/postresume.d/disable_mesh.sh
>>
>> If so, you should remove it IF there is no way to guarantee that it will run
>> before NM picks up the device. At least it will avoid the crash...
>>
>> I would ask in the NM community if there is a better way to disable a
>> particular device, like banning a device(?).
>
> Edit /etc/NetworkManager/NetworkManager.conf
>
> Add a line to the [main] section like
>
> no-auto-default=xx:xx:xx:xx:xx (obviously replacing the x's with the
> mac-address of your mesh device.)
>
> This does not stop NM from managing your device, but does stop it from
> auto-connecting the device.  You would still be able to go into NM and
> manually enable the mesh network.   If you want NM to completely leave
> the device alone you can go one more step.
>
> Also in /etc/NetworkManager/NetworkManager.conf
>
> change the plugins line to
>
> plugins=ifcfg-rh,keyfile
>
> Then add a section that looks like this.
>
> [keyfile]
> unmanaged-devices=mac:xx:xx:xx:xx:xx:xx (Where X's are the mac address
> of the device you want to ignore)
>
>
> Hope that helps, let me know if you have further questions.
>
> -Jon
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Wanting to know a bit of (NetworkManager) workflow upon resume-from-suspend

[Jon Nettleton]

On Sun, Apr 29, 2012 at 10:04 AM, Martin Abente
 wrote:
> Are you guys still using this?
> http://git.sugarlabs.org/dextrose-platform/mainline/blobs/master/etc/powerd/postresume.d/disable_mesh.sh
>
> If so, you should remove it IF there is no way to guarantee that it will run
> before NM picks up the device. At least it will avoid the crash...
>
> I would ask in the NM community if there is a better way to disable a
> particular device, like banning a device(?).

Edit /etc/NetworkManager/NetworkManager.conf

Add a line to the [main] section like

no-auto-default=xx:xx:xx:xx:xx (obviously replacing the x's with the
mac-address of your mesh device.)

This does not stop NM from managing your device, but does stop it from
auto-connecting the device.  You would still be able to go into NM and
manually enable the mesh network.   If you want NM to completely leave
the device alone you can go one more step.

Also in /etc/NetworkManager/NetworkManager.conf

change the plugins line to

plugins=ifcfg-rh,keyfile

Then add a section that looks like this.

[keyfile]
unmanaged-devices=mac:xx:xx:xx:xx:xx:xx (Where X's are the mac address
of the device you want to ignore)


Hope that helps, let me know if you have further questions.

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

Re: Trac slowness diagnosis

[Jon Nettleton]

On Thu, Mar 29, 2012 at 9:22 PM, Martin Langhoff
 wrote:
> On Thu, Mar 29, 2012 at 2:46 PM, Martin Langhoff
>  wrote:
>> On Thu, Mar 29, 2012 at 1:52 PM, Daniel Drake  wrote:
>>> Through some profiling I found that an inefficient trac design causes
>>> about 17,000 identical SQL queries to be executed during each page
>>> load, related to the number of users in the system (we have about
>>> 5.5k).
>
> BTW, when you are dealing with this kind of SQL abuse, every little
> thing that lowers your latency helps alleviate the pain:
>
>  - have the DB on the same host
>  - ensure the python or php runtime connects to the DB via a unix socket
>  - shooting the programmer^W^W^Wseparating to a different DB instance

Another option could be to add some javascript to the page that uses
ajax to query the users only when the drop down menu is initiated.
This would make general page load time fast and only when changing
ticket ownership would we get the big query hit.

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

Re: [OLPC Engineering] [Techteam] 12.1.0 devel build 5 released, for the XO-1, XO-1.5 and XO-1.75

[Jon Nettleton]

On Mar 25, 2012 9:15 PM, "Simon Schampijer"  wrote:
>
> On 03/25/2012 08:45 PM, Chris Ball wrote:
>>
>> Hi,
>>
>> On Sun, Mar 25 2012, Simon Schampijer wrote:
>>>
>>> Yeah, flashed now another 1.75 machine (1C2 4GB) and the first boot
>>> when I did not sit next to the machine it came up the same as my 1B1
>>> with a non usable keyboard and trackpad. I rebooted and directly
>>> entered a name and could use than the machine.
>>>
>>> Things I came across from a first quick look:
>>> - the trackpad was not as good responsible
>>> - the neighborhood view had no APs listed
>>> - Paint did not start due to missing binaries (does start on the 1.5)
>>
>>
>> It might have crashed on its way into idle suspend (probably due to the
>> libertas bugs) leading to an apparant symptom of no keyboard/trackpad.
>> I stopped powerd straight away to avoid that.
>>
>> - Chris.
>
>
> Yeah, that is what I did, now I don't get hangs anymore at least. The
trackpad is still not as responsible, though.
>
> I filed a few more activity bugs on the sugarlabs tracker verifying the
bugs we already found in os4 [1], marked them with the keyword '12.1.0'.
>
> Regards,
>   Simon
>
> [1] http://wiki.laptop.org/go/User:Erikos/Testing/os4
> ___
> Devel mailing list
> Devel@lists.laptop.org
> http://lists.laptop.org/listinfo/devel

I would recommend disabling render acceleration in the xorg.conf of the
1.75 it seems to be very crashy.

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

Re: Video chat activity (was: Re: C and Sugar/GTK)

[Jon Nettleton]

On Thu, Mar 22, 2012 at 5:46 PM, Alex Waterman  wrote:
>
> Hi Paul,
>
>>
>> what happens if you simply install and run the gnome version of empathy
>> on an XO?  that would seem like the first step.  :-)  (and i'm interested
>> in hearing how it works!)
>
>
> Good question, I can't think of any reason why it wouldn't work providing
> the dependencies are also installed. When I get some more free time I will
> try to compile empathy and deps and let you know what happens.
>

you can install empathy with `sudo yum install empathy`.  I bet it is
already installed on your XO as it comes default on our images.

FYI, gnome-shell's messaging interface is done via a D-Bus connection
to empathy running in the background.

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

Re: 11.3.1 development build 31 for XO-1.75

[Jon Nettleton]

On Thu, Mar 22, 2012 at 5:02 PM, Martin Langhoff
 wrote:
> On Thu, Mar 22, 2012 at 11:50 AM, Gary Martin
>  wrote:
>> No panics yet with Record (five 6min videos so far). Changing quality to 
>> high causes the video to stall after a handful of frames, but no panic, and 
>> Recored would respond to Stop even if it was beach-balling. Low quality 
>> video records fine.
>
> Cool. I hear Jon Nettleton has evil plans to improve our
> capture/encode performance so we can grab higher-quality video.
>

*laughing maniacally, and rubbing hands together*

Yes I will hatch my evil plans soon.  We have a three pronged attack

1)  Enable the vmeta dsp and hook that up to gstreamer
2)  get iWMMxT accelerated codepaths wherever possible.  Marvell
provided us with an optimized vp8 encoder and I have looked at some of
the optimizations that exist in ffmpeg to see if they can be applied
elsewhere.
3)  Not that I am doing this, but switching to F17 and hardfp builds.
Encoding our audio is actually one of the biggest pigs, as it is all
floating point and we are doing all of that number crunching in
software.

I will keep everyone apprised of new information as my plan unfolds.

*locks himself back in his lair located somewhere in the Danish countryside*

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

Re: idea: set a niceness value under which a process won't awaken suspended CPU

[Jon Nettleton]

On Mar 2, 2012 11:06 AM, "Lennert Buytenhek"  wrote:
>
> On Fri, Mar 02, 2012 at 01:50:16AM -0800, Jon Nettleton wrote:
>
> > > One problem you can get into with this scheme is a kind of priority
> > > inversion.  If the low priority process does:
> > >
> > >fd = open("/foo/bar", O_RDWR);
> > >flock(fd, LOCK_EX);
> > >
> > > and the high priority process then also does:
> > >
> > >fd = open("/foo/bar", O_RDWR);
> > >flock(fd, LOCK_EX);
> > >
> > > and the low priority process then does:
> > >
> > >sleep(1);
> > >flock(fd, LOCK_UN);
> > >
> > > and the system then goes into suspend, you'll not wake up again
> > > after that second expires, and you might not wake up again soon
> > > at all.  The low priority process doesn't even have to sleep
> > > explicitly, if it takes a page fault you get basically the same
> > > thing.
> >
> > I believe the cgroup method will catch this though.  I would have
> > to double check, but I think that the cgroup becomes partially
> > frozen returning EBUSY until all the processes can properly be
> > frozen.  At that time I believe it is up to userspace to thaw, or
> > refreeze the group, unless the blocking process ends in which case
> > the entire cgroup is set to the frozen state.
>
> You can still suffer from priority inversion if you freeze a cgroup
> with a low priority process in it that holds a resource that another
> high priority process needs.
>
> You indeed can't suffer from priority inversion between processes in
> the same cgroup if you are going to freeze all of them, but then you
> don't care about CPU wakeups for the high priority process either.
>
> I guess that what I don't see yet is how you would use cgroups to
> implement the goals of John's scheme.

The cgroup would be the method to organize the processes that you don't
want running all  the time, but only when a higher priority processes has
already woken the cpu and is doing significant work.  If we put all these
"background" processes in a special cgroup, we can freeze their activity
before suspend, or any other arbitrary time at that point.  Then it would
be up to a process scheduler, or a userspace daemon to decided when we
would want to thaw this group because our system will already be up and
doing work.  We can also put a lower priority on that cgroup as to not
steal cpu cycles from the process that caused the cpu/system to wakeup to
do work.

Am I misunderstanding the concept proposed?

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

Re: idea: set a niceness value under which a process won't awaken suspended CPU

[Jon Nettleton]

On Mar 2, 2012 10:37 AM, "Lennert Buytenhek"  wrote:
>
> One problem you can get into with this scheme is a kind of priority
> inversion.  If the low priority process does:
>
>fd = open("/foo/bar", O_RDWR);
>flock(fd, LOCK_EX);
>
> and the high priority process then also does:
>
>fd = open("/foo/bar", O_RDWR);
>flock(fd, LOCK_EX);
>
> and the low priority process then does:
>
>sleep(1);
>flock(fd, LOCK_UN);
>
> and the system then goes into suspend, you'll not wake up again
> after that second expires, and you might not wake up again soon
> at all.  The low priority process doesn't even have to sleep
> explicitly, if it takes a page fault you get basically the same
> thing.

I believe the cgroup method will catch this though.  I would have to double
check, but I think that the cgroup becomes partially frozen returning EBUSY
until all the processes can properly be frozen.  At that time I believe it
is up to userspace to thaw, or refreeze the group, unless the blocking
process ends in which case the entire cgroup is set to the frozen state.

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

Re: idea: set a niceness value under which a process won't awaken suspended CPU

[Jon Nettleton]

Although the idea sounds good, the mechanism of using nice is very 2007
:-)  This should be accomplished by putting this type of process in a
specific cgroup.  We can then use the cgroup freezer to freeze all tasks in
that group, and thaw it when we see fit.

I used a similar mechanism to fix the problem where my wife would have all
sorts of flash things running in different tabs of her web browser, when I
was switched over to my user profile on the netbook.  I added some hooks
into policy kit to thaw the background users cgroup and unthaw the logged
in user.  Really I could have just limited the amount of processor
resources they had access to, but why waste the battery?

Other than that I think this could be a very good thing.  I also think this
would be a good way to control things that we only want to run when plugged
in.  No reason to run some of those cpu intensive cron jobs when running on
battery.

-Jon

On Mar 2, 2012 9:44 AM, "John Gilmore"  wrote:
>
> Here's a power-saving idea that's been marinating since 2007 (in an
> obscure corner of my mail queue).  When I reviewed it today I didn't
> see anything too wrong with it.
>
>John
>
> Message-Id: <200710240912.l9o9c1k2026...@new.toad.com>
> To: gnu
> Subject: OLPC idea: set a niceness value under which a process won't
awaken suspended CPU
> Date: Wed, 24 Oct 2007 02:12:01 -0700
> From: John Gilmore 
>
> An easy lever for CPU consumption management (power mgmt) would be to
> define a set of user processes that won't be scheduled in a
> power-suspended system.  They won't wake the CPU even if their timer
> goes off, their packet arrives, or their fairy godmother calls.  But
> if something else wakes the CPU, and it's going to stay running a bit
> while some higher priority process is waiting for flash or packets or
> something, these processes can run in the background.
>
> My idea is to tie this to "nice".  So if you "nice -20", it puts you into
> this range.  Say everything below -15, which lets you set a few priorities
> among the low priority background stuff.
>
> So if you nice things all the way down, they run when the CPU is powered,
> in the cracks when there's nothing else to do, but they don't cause the
CPU
> to wake up to service them if nothing else is going on.
>
> For example, code that polls and updates the battery status once a
> minute in HAL.  Or a system activity monitor that shows CPU state
> graphs or how many MHz we're running.  Or an RSS feed reader.  Or the
> thing that clears out Mozilla's cache.  Or the incremental backup
> daemon that copies the machine's state to the school server.  (If that
> ran with scavenged electricity, cool!  It can raise its priority once
> a day or so, to make sure that a backup gets done one way or another.)
>
> The GUI could have a way to throw a process into this state or out of it.
> E.g. push your mail reader there, polling every once in a while for email,
> opportunistically.
>
>John
>
> --- End of Forwarded Message
>
> ___
> Devel mailing list
> Devel@lists.laptop.org
> http://lists.laptop.org/listinfo/devel
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Impacts of disabling Automatic Power Management

[Jon Nettleton]

On Sat, Feb 11, 2012 at 6:24 AM, Daniel Drake  wrote:
> On Thu, Feb 9, 2012 at 7:33 PM, Sridhar Dhanapalan
>  wrote:
>>> Looking for the happy middle ground that doesn't interfere with
>>> collaboration.
>>
>> Emphasis on collaboration stability, but we would prefer not to have
>> massive battery drain while doing so. We understand that there are
>> trade-offs.
>
> I think its hard to find a middle ground at the moment. Maybe it is
> just subjective. As John Gilmore points out, we have years of
> experience of applying workarounds and it hasn't brought brilliant
> results. Recent workarounds have already shifted us quite
> significantly to the stability side (sacrificing power savings) -
> waking up on all multicast frames, apparently even ones that wouldn't
> normally be sent from the hardware to the driver - but we are still
> left with a (IMO) substandard experience for the field.
>
> If you apply the collaboration workaround in question you just shift
> the problem to other areas, such as presence and web browsing.
>
> In terms of the real solution, we are making progress on some of the
> issues. Slowly but surely.
>

I have never really been involved in collaboration and am just getting
up to speed but here are my observations as a fresh mind.

Right now almost all the collaboration problems seem to exist on the
client side of things.  That makes a lot of sense to me as the we know
there are limitations in the firmware we use for the wireless cards.
The way we work around that is disabling powersavings so the card can
"behave" normally.

My suggestion is that we can make the machines/servers acting as host
smarter and that can allow the best of both worlds.  This will
probably require reciprocal work on the clients but that will be
worked out in the development process.

The first problem I see is that machines don't wake on ARP.
Ultimately I believe we don't want our machines to wake on ARP, we
really want firmware that can handle ARP and only wake when our
address is ARP'd.  I don't know how unreasonable a request that is.
Without that option the next best thing is to have the other machines
on our network create a static ARP entry for other machines involved
in collaboration.  This makes it very easy for accurate unicast
wakeups.

Another problem appears to be lost wakup packets while collaborating.
This should be able to be fixed by using an iptables queue.  If we
queue collaboration traffic that isn't responded to, we can quick of a
script when the queue gets X long that tries various methods to wakeup
the machine on the other end.

Be smarter about how we track network traffic.  Other than just
checking if there is network traffic, we should be tracking where this
network traffic is from or to.  The most recent solution I have seen
inhibits powerd if a collaboration session is invoked.  I think a more
fine grained hammer would be to register who is being colaborated with
and specifically watching for network traffic with those hosts.

I am most certainly missing some things, but I am quite sure that we
can make all this work by stretching the rules of modern networking a
bit.  More and more networking code is written with the assumption the
other machine is always online and accessible.  That is generally a
fair assumption, except in our model.  To get around this we will need
to make our networking model a bit more stateful, and intelligent.  I
think all the pieces exist we just need to pull it all together with
some duct tape and bubble gum McGuyver style.

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

Re: Pretty gnome cursor theme on XO-1.75

[Jon Nettleton]

2012/2/10 Manuel Quiñones :
> El día 10 de febrero de 2012 10:17, Gonzalo Odiard
>  escribió:
>> Tested in os27, looks better than before.
>> Maybe the white line in the border of the circle can be a little wider.
>> The shadow in the arrow looks very good.
>> The hand can be improved (look like the line in the base is cutted)
>
> I fully agree.
>
> With time, I could touch every PNG manually, and left them in 2bpp
> already (as I did with the cursor), so the GPU does not change them.

The ultimate goal here would be able to fixup the svg so the cursors
are able to be generated properly.  This means snapping cursors edges
to the nearest 1px grid point.

With regards to firefox I always disable smoothscroll and then install
the "Yet Another Smooth Scroller" extension.  The algorithm he uses
for scrolling is by far the smoothest web scrolling experience on an
XO.  I also do this with the XO 1.5

It is a little off topic but the FF extensions I always use under
GNOME on an XO are YASS, and No Squint (It allows you to set the
default zoom of a page, and remembers zooms set for individual pages)

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

Re: [Techteam] The Fedora Fifteen Franken ARM hardfp build 1 for XO 1.75

[Jon Nettleton]

On Tue, Jan 3, 2012 at 6:55 AM, Martin Langhoff  wrote:
> On Tue, Jan 3, 2012 at 8:03 AM, Peter Robinson  wrote:
>> The "This sonic transducer, it is I suppose some kind of
>> audio-vibratory-physio-molecular transport device?" release.
>
> Right out of Barbarella!
>
>> This is a hard floating point Franken release for development and
>> testing of the hardfp on the XO 1.75. Its very incomplete and has a
>> number of things that don't work.
>
> And I am downloading it now :-)

We can build some binary graphics drivers for performance testing.
Still not to sort out the long term solution.

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

Re: 11.3.0 build 7 released, for XO-1.75, XO-1.5 and XO-1

[Jon Nettleton]

On Mon, Dec 19, 2011 at 11:24 PM, Sridhar Dhanapalan
 wrote:
> On 27 September 2011 22:31, Peter Robinson  wrote:
>> The "Come as you are? Oh Nevermind" release.
>>
>> We're into Activity freeze so no major changes.
>>
>> Download from:
>>
>> http://build.laptop.org/11.3.0/os7/
>>
>> Bugz fixed:
>> Tap-to-click on AVC touchpads disabled
>> XO-1.75 RenderAccel disabled for increased graphics stability
>
> How stable is RenderAccel on XO-1.5s? Is it worth activating?
>

RenderAccel is enabled by default for the XO-1.5's.

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

Re: [Techteam] 12.1.0 devel build 1 released, for XO-1.5 and XO-1

[Jon Nettleton]

On Mon, Nov 7, 2011 at 6:59 AM, Martin Langhoff  wrote:
> On Mon, Nov 7, 2011 at 9:41 AM, Peter Robinson  wrote:
>> Yes, its coming to F17 as a feature, as I said previously, that
>> doesn't mean that Fallback mode is going away in F17.
>
> There's nothing in that discussion thread about keeping a knob to
> enable fallback mode. The title of the thread says it all.
>
> I was just going to send Ajax your build, I see you're one step ahead
> of me :-) -- one thing is missing -- instructions on how to install
> it, for someone who's gotten rusty (like Ajax who hasn't updated his
> XOs in a while). And the XO-1 install process is different with UBIFS.
>
>> What is the state of merging out VIA driver back into mainline? That
>> would certainly help from the XO 1.5 PoV.
>
> That's for Jon to answer...

Well that is really a tough one.  Right now all the VIA development
work is going into the KMS/GEM driver.  Would we want to push forward
with that merge?

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

Re: XO-1.75 relative performance

[Jon Nettleton]

On Mon, Nov 7, 2011 at 6:36 AM, Tony Anderson  wrote:
> Hi,
>
> I was referring, of course, to the need for a 1GB memory to support the 3D
> drivers which appear to be required by the future Fedora releases. That
> sound scary!

This configuration would largely be recommended for supporting GNOME 3
on Fedora.  It will be possible to look at alternative desktops (XFCE,
LXDE)  that don't have quite the high end requirements.

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

Re: XO-1.75 relative performance

[Jon Nettleton]

>
> nouveau has been very usable for quite some time. I was using it
> without issues back in F-12/13 timeframe without too many issues.

What have you been using it for? Gnome-shell didn't exist back then.
They have been incrementally adding features but it has taken time.  I
have never used nouveau because there has been no power control
features, not something we I can do without.  I am not trying to say
something negative on the project, I just think it is a good barometer
for people to realistically grasp how long it takes to mature modern
graphics drivers without documentation.

>>
>> There should be a distinction between GNOME 3 and gnome-shell.
>> Gnome-shell is the only part of GNOME 3 that requires 3D acceleration.
>>  Could our hardware run gnome-shell?  Well that would take a bit of
>> time to figure out.  To my knowledge nobody has shown gnome-shell
>> running with clutter utilizing the OpenGLES backend.  Last I remember
>> clutter didn't support texture from pixmap capabilities with their EGL
>> backend, so that may still have to be implemented.  This may have
>> changed in the last couple of months by I have definitely not seen it
>> demonstrated or talked about anywhere.
>
> That's not exactly entirely true. There's a number of other apps that
> are making using of clutter through clutter-gtk, clutter-gst or MX.
> totem is one of these for example. Also before long gnome is planning
> on deprecating non gnome-shell based UXs and concentrating on getting
> sofware rendering up to a reasonable speed. We can start testing this
> in F-17 as it'll be a feature [1]. Phoronix has more details on
> llvmpipe [2] and the gallium3D bits [3]

Is this argument for or against GNOME 3?  You point out a lot of
libraries that require clutter, but none that are hard dependencies of
GNOME.  I understand a lot of projects are dependant on clutter, but
none are hard dependencies of the GNOME project.

The use of software rendering via llvm is great, but unfortunately
that is targeted at modern multi-core processors that have cycles to
spare.  This does not target at the limited resources an XO has
available.

>> Oh and that is just system RAM it
>> doesn't take into account the memory that is needed for the actual
>> graphics engine.
>
> Aren't the production 1.75s moving to 1Gb of RAM due to pricing of the
> different units?

Not that I have heard but we will see.  Regardless I don't see any
justification that would suggest we should target gnome-shell as a
desktop.

I understand the push to proliferate GNOME, however as Linus and many
other GNOME expatriates have emphasized it is not the right fit for
everyone.   I have been a gnome-shell contributor and propenent from
early on, but I can' t suggest it is a good alternative for limited
resource computers, when it continually fails me on my quad-core
desktop with a top of the line video card, which I originally ran the
nouveau drivers on but had to switch to the binary nvidia drivers
because it ran the fan at 100% the entire time.

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

Re: XO-1.75 relative performance

[Jon Nettleton]

> Hi Jon,
>
> We are doing some forwards-planing with regards to the XO-1.75. Would
> you be able to tell us what kind of performance we can expect from the
> graphics driver that you are working on? Would it support 3D hardware
> acceleration?

Well yes and no.  The graphics hardware does support 3d acceleration,
however currently that is only supported via a binary driver.  We also
don't have all the documentation nor man power to write a 3d driver.
The nouveau team has had 3 to 4 people working full time on a driver
for almost 4 years and their driver is just getting to a stable usage
point for desktop compositing.

For a general idea of performance our 3d graphics hardware will run
Quake3 at native 1200x900 resolution with medium quality graphics at
about 30fps on average.

>
> We are considering working to get GNOME 3 running, but for that to
> work well we'll need some good graphics capabilities.

There should be a distinction between GNOME 3 and gnome-shell.
Gnome-shell is the only part of GNOME 3 that requires 3D acceleration.
 Could our hardware run gnome-shell?  Well that would take a bit of
time to figure out.  To my knowledge nobody has shown gnome-shell
running with clutter utilizing the OpenGLES backend.  Last I remember
clutter didn't support texture from pixmap capabilities with their EGL
backend, so that may still have to be implemented.  This may have
changed in the last couple of months by I have definitely not seen it
demonstrated or talked about anywhere.

The bigger concern I have with targeting a compositing window manager
is the amount of RAM that it needs.  Every window also has a
duplicated texture in memory that is used to create the composited
display.  Generally gnome-shell will use 100+MB's of RAM just to
display the desktop, and there is no way to tweak around this by using
16-bit colors as everything is an ARGB texture.  On a machine with 1GB
of RAM this isn't so bad, but that is a hefty chunk of memory for a
machine with 512MB's of memory.  Oh and that is just system RAM it
doesn't take into account the memory that is needed for the actual
graphics engine.

To sum things up.  Yes the hardware should have the capabilities to
run gnome-shell, again I say should as it is very untested.  I would
not recommend targetting it's use in any future plans unless you have
GNOME and Xorg hackers lined up to spend a good chunk of time working
on it.

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

Re: 11.3.0 can have difficulties with wired ethernet adapter

[Jon Nettleton]

>
> Can you explain how we can reproduce this? At which point do you
> connect the ethernet adapter?
>
> We already have a mechanism in place that should reserve eth0 for the
> internal wifi card, so this is unexpected.

We have mechanisms that rename the wifi interface to eth0.  The
problem is that the usb ethernet comes of first and is given eth0
which causes udev to thrash when wifi is brought up and it tries to
rename it.  I think it usually ends up naming the device wlan-eth0 or
something like that.

The steps are easy.  Flash a new image onto a device, or remove
/etc/udev/rules.d/70-persistent-net.rules.  Then reboot with wlan
enabled and a usb-ethernet device plugged in.  You may have to hard
power off the machine so udev doesn't create a new persistent file on
shutdown, can't remember exactly.

You can of course also fix this condition by going in and manually
editing the persistent net rules to make the wifi card get eth0 and
the usb device get eth1.

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

Re: 11.3.0 can have difficulties with wired ethernet adapter

[Jon Nettleton]

On Mon, Oct 31, 2011 at 9:14 AM, Mikus Grinbergs  wrote:
> Using os883 with q3b22.rom on an XO-1.5.  On first-time boot-up with a
> build, which interface gets assigned to the ethernet depends upon when the
> ethernet-USB adapter gets plugged in to the XO.  [If plugged in too soon,
> the wired ethernet gets assigned the 'eth0' interface -- which causes
> conflicts trying to use wireless.]

This is a known bug.  I don't know the bug number off the top of my
head.  It is a race condition between the usb ethernet and the
wireless renaming udev rules.  To fix this unplug wired ethernet,
remove /etc/udev/rules.d/70-persistent-net.rules and reboot the
computer.  Wait for the computer to come up and then plug in the usb
ethernet adapter.  This will allow the persistent rules file to set
wireless as eth0 and usb ethernet as eth1 and susbsequent reboots want
cause the race condition where usb ethernet grabs eth0 and then udev
hangs trying to rename wlan0 to eth0 which is taken.

>
> Further, with the ethernet-USB adapter plugged in, shutdown usually takes
> about a minute (while displaying the U/L warnings screen).  It appears that
> something regarding the ethernet is being timed out.

Haven't see this sorry.   Perhaps getting the device renaming and
persistent rules straightened out will fix it.

>
> [Also, since this summer the Fedora 14 NetworkManager has gotten aggressive
> -- it periodically simply disconnects my ethernet connection (so that it can
> scan for wireless signals ??).  My bypass is to stop the NetworkManager
> before connecting the XO to the internet using the wired ethernet rather
> than connecting the XO through a wireless AP.]

Have definitely not seen this.  NetworkManager will bring up both
interfaces if they are available.  Are you sure that NM isn't
connecting to wireless in a bad environment and causing the network to
hang because it is going out the wifi connection instead of the usb
ethernet?  Please open a ticket for this and we can get some NM logs
to see what is happening.

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

Re: [Testing] 11.3.0 release candidate 3 (build 882) released

[Jon Nettleton]

On Tue, Oct 25, 2011 at 6:54 PM, Martin Langhoff  wrote:
> My thinking was along the lines of Paul's in his comment in #11304:
> consistently disable DPMS/blanking/etc from X hooks, and let powerd
> consistently control it, across all platforms.
>
> Is it a powerd bug that it doesn't DTRT on XO-1? Or maybe there's a
> limitation on XO-1 (maybe the kernel we ship doesn't expose the right
> controls to powerd...) and it makes sense to rely on DPMS there...
>
> In any case, I didn't do it with any special knowledge of XO-1 specifics. I
> was just trying to make code and behaviour consistent across hw platforms.
> Which may well been a naive move.

The only specifics I know of is that originally the geode Xorg driver
had code to control the DCON in the DPMS hooks.  When the question
came back up for the XO 1.5 I suggested removing the DPMS out of the
question all together and just handle everything through powerd.  My
preference was to limit the moving pieces a bit, with the downside
being custom distros would have to adopt powerd or fend for
themselves.  I think as a platform this decision is working well and
we should keep it consistent across the different models.

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

Re: #11231 NORM 1.75-so: Wrong dimenssions in PyGame activities

[Jon Nettleton]

It will be os8
On Sep 28, 2011 12:36 AM, "Zarro Boogs per Child" 
wrote:
> #11231: Wrong dimenssions in PyGame activities
>
+---
> Reporter: godiard | Owner: jnettlet
> Type: defect | Status: new
> Priority: normal | Milestone: 1.75-software
> Component: physics-activity | Version: not specified
> Resolution: | Keywords:
> Next_action: never set | Verified: 0
> Deployment_affected: | Blockedby:
> Blocking: |
>
+---
>
> Comment(by erikos):
>
> Replying to [comment:7 jnettlet]:
> > Guys, we also added a Virtual 1200 1200 line to the xorg.conf that
> limits the resolutions shown as available by the xrandr. This does fix
> the problem on our xo 1.75's but for SOAS and we will probably want a
> proper fix in the activities.
>
> Hmm, I can nost see a line saying 'Virtual 1200 1200' in the xorg conf. In
> os7 Physics has still the wrong dimensions and things fall of the screen.
>
> --
> Ticket URL: 
> One Laptop Per Child 
> OLPC bug tracking system
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [Techteam] 11.3.0 build 6 released, for XO-1.75, XO-1.5 and XO-1

[Jon Nettleton]

On Wed, Sep 21, 2011 at 10:14 PM, Sameer Verma  wrote:
> On Wed, Sep 21, 2011 at 9:35 PM, Martin Langhoff  wrote:
>> On Wed, Sep 21, 2011 at 11:23 PM, Sameer Verma  wrote:
>>> Reflashed a 1.75B1 with os6 It boots up with text messages scrolling, but
>>> when it gets to X with the mouse pointer, it doesn't show me the name
>>> screen. Mouse isn't frozen, but the blank white screen just sits there.
>>> Anyone else seeing this?
>>
>> Everyone it seems. Workaround at http://dev.laptop.org/ticket/11257
>
>
> Workaround works, but the machine freezes shortly there after in Browse.
>
This is a known issue.  Browse is causing a resource shortage in the
graphics driver.

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

Re: Syncronizing defconfig between XO-1.5 and XO-1.75

[Jon Nettleton]

On Thu, Sep 15, 2011 at 11:55 AM, Jerry Vonau  wrote:
> On Thu, 2011-09-15 at 14:37 -0400, Martin Langhoff wrote:
>> On Thu, Sep 15, 2011 at 2:36 PM, Jerry Vonau  wrote:
>> >>  - Did not enable drivers for Joliet and other CD filesystems. I doubt
>> >> we care -- we don't seem to have CD-ROM drivers anyway. Why do we have
>> >> this on XO-1.5?
>> >>
>> >
>> > It's nice to be able to plug in a usb cd/dvd and have it work.
>>
>> Does it effectively work on XO-1 or XO-1.5? It's a candid question --
>> I don't have any USB-CD...
>

Just plugged my external Sony CD/DVD RW that uses an external power source
into my XO 1.5 and it was properly recognized and mounted the CD in it.

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

Re: XO 1.75 os4 display

[Jon Nettleton]

On Sun, Sep 11, 2011 at 7:06 AM, Gabriel Eirea  wrote:
> 2011/9/11 Gary Martin :
>> Hi Sameer,
>>
>> On 11 Sep 2011, at 02:32, Sameer Verma  wrote:
>>
>>> I installed os4 on a XO 1.75 B1 last night. I see a screen corruption
>>> with text on both the GNOME and Sugar sides. Entering text into a
>>> textbox in a browser will start corrupting to a point that I can no
>>> longer see some of the letters typed. Minimizing the window and
>>> maximizing it will bring the text back.
>>>
>>> Anyone else seeing this?
>>
>> Yes I'm seeing something similar here in Browse particularly where you have 
>> mouse over button UI changes where the cursor seems to be related to the 
>> clobbering of the redraw.
>>
>
> Same thing here. The cursor over the text box messes up the letters.
> If you double-click on the text, it shows up again correctly.

This is a problem with the accelerated copies in the new driver.  You
can work around it
by editing /etc/X11/xorg.conf.d/xo1.75.conf  and changing Option "Copy" to false

This will still give you accelerated solids, compositing and XVideo.
You will notice a slowdown
in performance.  I am looking into it.

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

Re: OOB - can we teach imgcreator about our arm arch?

[Jon Nettleton]

On Thu, Jun 9, 2011 at 3:36 PM, Peter Robinson  wrote:
> On Thu, Jun 9, 2011 at 10:52 PM, Martin Langhoff
>  wrote:
>> Hi Daniel, Peter, list
>>
>> I am wondering how we can teach imgcreator about our ARM arch, so that
>> it can build an image with some arm5tel packages and some armv7l
>> packages (such as the kernel).
>
> If we do something like run imgcreator as armv7l it should just work,
> this might not work if its run on koji2/koji3 due to them only being
> v5tel
>
>> Today I discovered that rpm itself is complaining about installing a
>> kernel armv7l package -- in a lousy hack in a preimage script,
>> probably because uname reports that the (build)host is arm5tel. We'll
>> probably have to teach rpm about this as well.

Anyway we can get around this by have the Image Builder call setarch?

This is basically how mock gets around the issue I believe.

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

Re: WebM format for Record

[Jon Nettleton]

>>
>> This is with no changes to the pipelines.  I just wanted a quick
>> reference.
>>
>
> This is XO-1.5?
> Tiago

I only tested on the XO-1.5, but I don't see any reason we shouldn't
see similar improvements on the XO-1

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

Re: WebM format for Record

[Jon Nettleton]

On Sun, Apr 10, 2011 at 9:58 PM, John Watlington  wrote:
>
> You forgot to include the URL of the page ?
>
> On Apr 9, 2011, at 9:48 PM, Jon Nettleton wrote:
>

Sorry I hit reply all, but looks like the mailing list was stripped off.

 http://dev.laptop.org/~jnettlet/record_tests/

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

Re: WebM format for Record

[Jon Nettleton]

>
> Oh and there was a question about backwards compatibility.  I know
> there would be work testing it, but I see no problems with backward
> compatibility.  We would just have to check file types and adjust the
> pipeline accordingly.  We would also have to adjust the mimetype
> properties to any Activities that may hard code them.
>

A quick follow up.  I decided to do a general shoot out for Record and the
different codecs.  Here is an html5 page that shows all three codecs.

Upper Left is default Record.  CPU utilization was around 95% on average.
Upper Right is webm Record   CPU utilization was around 75% on average
Lower Left is theora 1.2.0alpha1.  CPU Utilization was around 95% on average.

This is with no changes to the pipelines.  I just wanted a quick reference.

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

Re: WebM format for Record

[Jon Nettleton]

On Sat, Apr 9, 2011 at 11:16 AM, Benjamin M. Schwartz
 wrote:
> 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.

Google has also worked on speed optimizations for the vp8 encoder.
The version of libvp8 included in Fedora 14, might be in
updates-testing, includes these optimizations.  You will see in my
patch I am using speed setting 2 which is a single pass encoding meant
for live streaming.  I am so far very impressed with the system
demands as well as the quality.  With speed set to 2, and quality at 5
( middle of the road ) I was able to record full 2 minute clips at Low
Res, High Res, and also did some testing at 640x480.  400x300
recordings were using about 70-80% cpu utilization encoding in the
WebM format.

Google is also working on ARM optimizations that will be important for
the XO 1.75

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

I did test this version out but found the improvements on our hardware
to be marginal.  I know there was talk about constant bit rate vs vbr
possible needing to be tweaked.  I didn't have the time to look into
it then.

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

You can see in this video  http://www.youtube.com/watch?v=ilmMrtlzSRg
that the WebM on the XO 1.5 is really working better than our current
release.  You will hear a few pops in the audio, those points were
when we would previously lose all sink between audio and video.  In
this video the sink isn't perfect but relatively close.

Oh and there was a question about backwards compatibility.  I know
there would be work testing it, but I see no problems with backward
compatibility.  We would just have to check file types and adjust the
pipeline accordingly.  We would also have to adjust the mimetype
properties to any Activities that may hard code them.

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

WebM format for Record

[Jon Nettleton]

Hey Guys,

I was hoping to get more work done on this but haven't had the chance
to work on it any further.  This patch switches Record to use the WebM
video format as specified by google.  It should work on our F14
builds.  The videos will playback in Record, but you will have to
patch your mimetypes files to add support to other programs.  In
particular you should add video/webm to the
/usr/share/sugar/data/mime.defaults file.

I do know that one thing that needs to be fixed is the preview image
shown while the recording is being encoded is displayed in greyscale
instead of color.  Other than that I am quite happy with the recording
quality.  You will still notice an audio hiccup at  between 14 and 20
seconds of the start of the recording.  This is where we would
previously lose audio sync.  With this patch the sync re-adjusts
itself but leaves a small hiccup in the audio track.

Hope this is useful to someone.

-Jon
From 42c66aaf17686be5b5320698c7d258e11164812d Mon Sep 17 00:00:00 2001
From: Jon Nettleton 
Date: Fri, 8 Apr 2011 05:50:25 -0700
Subject: [PATCH] Convert to using WebM video format

This switches Record to use vp8 video and ogg audio
in a matroska container.  This is the standard that
makes up the WebM video format.  The encoder quality
and performance seems to be better than the existing
ogg/theora combination.
---
 constants.py |4 +-
 glive.py |   59 +
 2 files changed, 32 insertions(+), 31 deletions(-)

diff --git a/constants.py b/constants.py
index 9b0ed4a..2381029 100644
--- a/constants.py
+++ b/constants.py
@@ -26,8 +26,8 @@ MEDIA_INFO[TYPE_PHOTO] = {
 
 MEDIA_INFO[TYPE_VIDEO] = {
 'name' : 'video',
-'mime' : 'video/ogg',
-'ext' : 'ogg',
+'mime' : 'video/webm',
+'ext' : 'webm',
 'istr' : _('Video')
 }
 
diff --git a/glive.py b/glive.py
index 07d187b..14288cf 100644
--- a/glive.py
+++ b/glive.py
@@ -38,9 +38,9 @@ import utils
 
 logger = logging.getLogger('glive')
 
-OGG_TRAITS = {
-0: { 'width': 160, 'height': 120, 'quality': 16 },
-1: { 'width': 400, 'height': 300, 'quality': 16 } }
+WEBM_TRAITS = {
+0: { 'width': 160, 'height': 120, 'quality': 5 },
+1: { 'width': 400, 'height': 300, 'quality': 5 } }
 
 THUMB_STUB = gtk.gdk.pixbuf_new_from_file(
 os.path.join(get_bundle_path(), 'gfx', 'stub.png'))
@@ -180,13 +180,14 @@ class Glive:
 
 colorspace = gst.element_factory_make("ffmpegcolorspace", "vbcolorspace")
 
-enc = gst.element_factory_make("theoraenc", "vbenc")
-enc.set_property("quality", 16)
+enc = gst.element_factory_make("vp8enc", "vbenc")
+enc.set_property("quality", 5)
+enc.set_property("speed", 2)
 
-mux = gst.element_factory_make("oggmux", "vbmux")
+mux = gst.element_factory_make("matroskamux", "vbmux")
 
 sink = gst.element_factory_make("filesink", "vbfile")
-sink.set_property("location", os.path.join(Instance.instancePath, "output.ogg"))
+sink.set_property("location", os.path.join(Instance.instancePath, "output.webm"))
 
 self._videobin = gst.Bin("videobin")
 self._videobin.add(queue, scale, scalecapsfilter, colorspace, enc, mux, sink)
@@ -217,7 +218,7 @@ class Glive:
 
 def _config_videobin(self, quality, width, height):
 vbenc = self._videobin.get_by_name("vbenc")
-vbenc.set_property("quality", 16)
+vbenc.set_property("quality", 5)
 scaps = self._videobin.get_by_name("scalecaps")
 scaps.set_property("caps", gst.Caps("video/x-raw-yuv,width=%d,height=%d" % (width, height)))
 
@@ -366,7 +367,7 @@ class Glive:
 
 self.model.still_ready(self._audio_pixbuf)
 
-line = 'filesrc location=' + audio_path + ' name=audioFilesrc ! wavparse name=audioWavparse ! audioconvert name=audioAudioconvert ! vorbisenc name=audioVorbisenc ! oggmux name=audioOggmux ! filesink name=audioFilesink'
+line = 'filesrc location=' + audio_path + ' name=audioFilesrc ! wavparse name=audioWavparse ! audioconvert name=audioAudioconvert ! vorbisenc name=audioVorbisenc ! matroskamux name=audioOggmux ! filesink name=audioFilesink'
 audioline = gst.parse_launch(line)
 
 taglist = self._get_tags(constants.TYPE_AUDIO)
@@ -376,7 +377,7 @@ class Glive:
 vorbis_enc.merge_tags(taglist, gst.TAG_MERGE_REPLACE_ALL)
 
 audioFiles

Re: The next four weeks

[Jon Nettleton]

>>
> From a technical POV, no difference. From the POV of the learner,
> there are workflow and structural affordances we want to support. E.g,
> We want the kids to ask themselves: What, How, Why, For whom... We
> want to support the idea of selection, reflection... lots of details
> that we have a placeholder for, but not enough scaffolding for.
>

Perhaps this is something that we could work with the Diaspora project
on.  I haven't played with it too much, but they are supposedly
working to add much better content control to a facebook like web
experience.  The server is OSS, which would allow use to possibly
bundle it with the School Server.

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

XO 1.5 performance testing.

[Jon Nettleton]

It has been a fun and fulfilling weekend tracking down performance
regressions when using DRI on the XO 1.5 platform.  One place I was
looking at specifically was blitting solids from userspace to the
kernel.  I found that copy_from_user was really chewing up a
significant amount of cpu.  Looking further I found that for VIA C7
processors these two options,  X86_INTEL_USERCOPY and
X86_USE_PPRO_CHECKSUM, are not enabled.

I have not done thorough testing on it, but after patch the kernel
with the attached patch my gtkperf run dropped from 63 seconds down to
50 seconds.  A 20% improvement is not bad, but more testing is
definitely needed, and testing both options independently is also
needed. I have my test kernel available here
http://dev.laptop.org/~jnettlet/f14/kernel-2.6.35.9_xo1.5-20110313.2249.fc14.c06443f.i586.rpm

If anyone else reports back that they are also seeing improvements I
will open a bug and we can track this improvement down further.

Jon
diff --git a/arch/x86/Kconfig.cpu b/arch/x86/Kconfig.cpu
index 2ac9069..e320d51 100644
--- a/arch/x86/Kconfig.cpu
+++ b/arch/x86/Kconfig.cpu
@@ -364,11 +364,11 @@ config X86_ALIGNMENT_16
 
 config X86_INTEL_USERCOPY
 	def_bool y
-	depends on MPENTIUM4 || MPENTIUMM || MPENTIUMIII || MPENTIUMII || M586MMX || X86_GENERIC || MK8 || MK7 || MEFFICEON || MCORE2
+	depends on MPENTIUM4 || MPENTIUMM || MPENTIUMIII || MPENTIUMII || M586MMX || X86_GENERIC || MK8 || MK7 || MEFFICEON || MVIAC7 || MCORE2
 
 config X86_USE_PPRO_CHECKSUM
 	def_bool y
-	depends on MWINCHIP3D || MWINCHIPC6 || MCYRIXIII || MK7 || MK6 || MPENTIUM4 || MPENTIUMM || MPENTIUMIII || MPENTIUMII || M686 || MK8 || MVIAC3_2 || MEFFICEON || MGEODE_LX || MCORE2 || MATOM
+	depends on MWINCHIP3D || MWINCHIPC6 || MCYRIXIII || MK7 || MK6 || MPENTIUM4 || MPENTIUMM || MPENTIUMIII || MPENTIUMII || M686 || MK8 || MVIAC3_2 || MVIAC7 || MEFFICEON || MGEODE_LX || MCORE2 || MATOM
 
 config X86_USE_3DNOW
 	def_bool y
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: XO-1.1 differences

[Jon Nettleton]

On Thu, Mar 10, 2011 at 7:57 AM, John Watlington  wrote:
>
> While more testing is good, I would point out that Jon's frankenstein
> machine is much more different from the hardware you
> will be installing onto than the original XO-1 (CL1).
>
> The ONLY differences between the CL1A and CL1 laptops is the
> single-mode capacitive touchpad instead of the dual mode
> resistive/capacitive one.
>

As I figured, my hardware modifications were not exactly the same as
the production ones.  Even so I will report back that I was able to
install and run the requested image on my "frankenstein" XO1 with an
XO 1.5 keyboard and mouse.

Sridhar I hope that gives you a bit more confidence in your upgrade
path.  Good luck.

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

Re: XO-1.1 differences

[Jon Nettleton]

On Wed, Mar 9, 2011 at 8:09 PM, Sridhar Dhanapalan
 wrote:
> A year ago, we deployed about 200 XO-1.1 machines in a community. I'm
> not sure if that version number is official, but it's what we call
> XO-1s with XO-1.5 style capacitive trackpads.
>
> I am going to that community in a couple of weeks to upgrade them to
> the latest OS build. I only have the standard XO-1s available to me
> for testing. Is there anything peculiar that I need to know about the
> XO-1.1s that will affect development and testing?

I would not say that is an official XO-1.1, but I have replaced my
XO1's base with one from my alpha board XO 1.5.  I think the end
result is basically what you are describing.  The hardware designers
would probably know if the hardware is an exact match.

If you let me know which build you plan on installing, I can test for you.

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

Re: Graphics guinea pigs

[Jon Nettleton]

On Fri, Mar 4, 2011 at 11:24 AM, Gonzalo Odiard  wrote:
> Hi Jon
> I can see the corruption again with this rpm, and the configuration changed.
> Can I send you any useful information?
> Regards
>

Gonzalo,

I have found a couple of bugs with repeating texture rendering.  I am
trying to track them down.

If you can take a picture of the corruption and the steps to recreate
it I would appreciate it.

Thanks,

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

Graphics guinea pigs

[Jon Nettleton]

Hey all,

I think I have finally nailed down all the last issues with the chrome
driver and am hoping some volunteers may help me to test before I
include it in the next build.

If you are brave and willing to bug me with bug reports grab
http://dev.laptop.org/~jnettlet/f14/xorg-x11-drv-chrome-5.74.33-4.fc14.i686.rpm
then edit /etc/X11/xorg.conf.d/xo1.5.conf and comment out the Option
"MigrationHeuristic" "greedy" line.  Then restart X


Any questions mail me or ping me on #olpc-devel

Thanks,

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

Re: [support-gang] Questions Re: Skype on XO

[Jon Nettleton]

On Tue, Mar 1, 2011 at 7:30 PM, Luke Faraone  wrote:
> I'm not sure this is an apt question for IAEP.
>
> On 03/01/2011 09:24 PM, Caryl Bigenho wrote:
>>
>> I need to be able to do a 2-way video chat.  I would like to know...
>>
>> 1) How much memory does Skype take up?
>
> Disk space: the RPM page is 18.7MiB, so I'd imagine it takes up a little
> bit more than that on disk.

Skype also requires Qt to be installed.  My static version of 2.0.0.72
takes up 26.5Mb.

*snip*

>> 3) What is the difference in performance between the XO-1 and the XO-1.5?

I don't think that the XO1 supports the multiple XV surfaces needed to
run skype video out.  This has just been added to the XO 1.5 11.2.x
series.

>> 4) What is the reason for the difference, memory or speed or both?

I think I have probably worked the most with getting skype running on
the XO 1.5 platform, so I will try to sum up my experience.

The most recent version of skype that I suggest running is 2.0.0.72.
It has its quirks and problems but still uses the old codecs for audio
and video compression.  The 2.1 series introduced the Silk codecs that
require much more CPU than the XO's have available.  The video does
now work with the most recent development builds for the XO 1.5, but
there is still more tweaking that is necessary to get skype working.
You need to do some specific configuration for both the soundcard and
the camera to get everything working.

I spent an hour or two pulling together all my notes and starting an
RPM installation this weekend.
When is your video chat and do you have any other computers available?
 You can e-mail me off list and I will try to help you out as much as
possible.

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

Re: Flash

[Jon Nettleton]

>
>> What are the specs on the desktop?
>
> Twin-core Opteron running at 2.6 GHz.  However, 'top' shows no more than
> 5% of one core being used by Firefox+plugin while rendering that video clip.
>

Sounds like you are running an nvidia GPU with the proprietary
drivers.  As of flash 10.2, VDPAU is supported for flash video
decoding.  This offloads virtually all the processing to the gpu.  Of
course this is also entirely proprietary and only Nvidia's proprietary
drivers support it.

Ultimately flash is a proprietary system, so there is only so much we
can do to make it run better.  My recommended solution for
youtube/vimeo is the flash video replacer video plugin.

Again from my basic testing, the big killer with flash on an XO is the
limited cpu cache.

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

Re: Flash

[Jon Nettleton]

>> With the new display drivers, youtube videos at 320p are very
>> watchable.  You will get occasional glitches due to CPU constraints
>> but generally quite smooth.
>
> Sorry - I disagree.
>
> Just went and watched the "2011 NBA All-Star Game Mini Movie" clip:
> Side by side on XO (Browse-120) with driver
> xorg-x11-drv-chrome-5.74.33-2.fc14.i686 and on desktop system (Firefox)
> - both presenting that video clip at 360p.

What are the specs on the desktop?  Flash video is all done via
software rendering.  We are still limited by being 1ghz and with a
very small cache.  You are also testing worst case scenario which is
full motion running all the time.

>
> On the desktop, the clip is SMOOTH and continuous.  On the XO, the clip
> exhibits "video interruptions" -- more frequently than I like the images

Are you on youtube without any ad-blocking software?  youtube is
loading more flash ads on the sides of the screen throughout the video
playback.  This is probably where you see the screen 'stay' still, not
a playback option, just a limit of the computers capabilities.

> shown "stay still" for a brief instant, then "jump" to their current
> positions.  To me, the effect on the XO aggregates to UNSMOOTH.

Playing just a pure flash 360p video is smooth and possible.

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

Re: Flash

[Jon Nettleton]

> similar performance to flash 10.2.  [On the XO-1.5, all of these
> browsers display YouTube 240p clips acceptably (but still jerky).]

With the new display drivers, youtube videos at 320p are very
watchable.  You will get occasional glitches due to CPU constraints
but generally quite smooth.

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

Re: Flash

[Jon Nettleton]

On Wed, Feb 23, 2011 at 6:02 PM, James Cameron  wrote:
> No, there is no "best practice" rule.
>
> The problem with "best practice" is that every practice must be
> evaluated before one can be claimed to be "best".  I don't think there's
> anyone doing that.  It would be a difficult task; the phase space has
> dimensions of (a) hardware model, (b) operating system, (c) desktop, (d)
> browser, (e) plugin, and (f) content or web site.
>
> I've tested Browse and Firefox with the Adobe Flash plugin in the past
> week or so.  My data point in the phase space:
>
> (a) XO-1.5
> (b) 10.1.3
> (c) GNOME or Sugar
> (d) Firefox or Browse
> (e) flash-plugin-10.1.102.65-release.i386.rpm
> (f) googleartproject.com
>
> Result: good.
>

(a) XO-1.5
(b) 11.2.0
(c) GNOME or Sugar
(d) Firefox or Browse
(e) flash-plugin-10.2.152.27-release.i386.rpm
(f) googleartproject.com / youtube.com

Result: better :-)

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

Re: [Sugar-devel] Activity crashes when using libsugarize.so

[Jon Nettleton]

On Wed, Feb 9, 2011 at 8:28 AM, Martin Langhoff
 wrote:
> On Wed, Feb 9, 2011 at 11:08 AM, Thomas C Gilliard
>  wrote:
>> Last year I experimented with sugarize and stored the files required in a
>> local repo:
>
> Right. Could you please change your notes to recommend that people...
>
>  - download libsugarize.c and compile it on the target OS instead of
> downloading yours?
>  - use the shell version of "sugarize" instead of the C version?
>
> The libsugarize.so issue is the main one. It probably only works
> reliably on the specific Fedora version it was built on.
>

Any reason not to package both of these into an rpm and provide it in
the OLPC repos?

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

Re: Sugar on arm

[Jon Nettleton]

On Mon, Feb 7, 2011 at 8:41 AM, ismael schinca
 wrote:
> Hello everyone. I'm trying to run Fedora 12 on a Beagleboard xm and running
> sugar on it.
> However, when I try to install the sugar package via yum I get some
> dependencies problem. Specifically, the xapian-bindings-python package is
> missing (apparently sugar-datastore requires it). This package is not
> available for ARM architecture.
> So I downloaded and compiled the latest xapian bindings for python manually.
> However, after succesfully installing this, the dependencies problem still
> remains. I suppose it just checks for the package.
> Any suggestions? I'm no expert so maybe it's something quite simple (yum
> skip-broken does not do the trick).

The best way to resolve this is to build your own local rpm.  You can
grab the src.rpm from koji.fedoraproject.com and then run rpmbuild
--rebuild nameof.src.rpm

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

Re: [Devel Digest, Vol 60, Issue 12] Announcing OLPC's work on new "chrome" VIA video

[Jon Nettleton]

*snip*
>>
>>
>
> Excellent.
> One clarification. "Our platform" means "(customized) Fedora 14 _and_ XO-1.5" 
> or either one alone also qualifies?
> Thx.
>

Of course the first priority for development is Fedora 14 on the XO
1.5 platform.  I will also try to help as much as possible to handle
other configurations, and patches for other platforms will be
accepted.

My priorities are from top to bottom are

1) Implement all needed features on the current XO 1.5 platform
2) Bug fixes and performance optimizations where applicable to our platform
3) Compatibility with other distributions running on the XO 1.5 hardware
4) Hardware and feature compatibility for other Chrome9 based hardware

I hope that answers your question.

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

Re: Kahn Academy, YouTube, XO-1

[Jon Nettleton]

On Sat, Feb 5, 2011 at 5:21 AM, Walter Bender  wrote:
> On Fri, Feb 4, 2011 at 8:45 PM, Hal Murray  wrote:
>>
>> I'm a bit surprised nobody has mentioned Khan Academy here before.
>>  http://www.khanacademy.org/
>
> There is a long thread on the iaep list beginning here:
>
> http://lists.sugarlabs.org/archive/iaep/2010-December/012201.html
>
> There are pre-converted (to .ogg) versions available as well as an
> archive.org stash.

For video I think a good alternative to look at for gnash in the
default install is
https://addons.mozilla.org/en-US/firefox/addon/flashvideoreplacer/  It
is actively developed, the source is here,
http://www.webgapps.org/addons/flashvideoreplacer , and is GPL
licensed.  I understand we use flash for other things, but I think
this is a good solution for some of the more popular video sites.
This should also help with battery drain while watching vdeos because
it allows the graphics hardware to do some of the work instead of a
pure CPU driven software solution.

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

Re: [Server-devel] Hidden SSID and Proxy settings

[Jon Nettleton]

>
> This wouldn't happen to be in NYC, would it?  I remember reading a long time
> ago that the schools there have a policy that SSIDs can't be broadcast.  You
> might deter my Grandma with that, but it's almost pointless as a security
> measure.
>
> http://olpcnyc.wordpress.com/2008/05/09/connecting-to-hidden-wifi-networks/
>
> That workaround is likely deprecated now, though.
>

If this is a newer image, one based on F11 then you should be able to
use nmcli to connect.  Take a look at this page.

http://blog.nixpanic.net/2011/01/connect-automatically-and-immediately.html

Hope that helps. My grandma would still hack it in 2 seconds though :-)

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

F14 testing for the new "chrome" driver

[Jon Nettleton]

This is not for the faint of heart, but I think I have enough pieces
working that I am ready to take on bugs from the general testing
populous. This update is for XO 1.5 developers that are using the F14
based builds.  If you aren't running this configuration close this
e-mail now and walk away.

Installation:

You need to download 3 files from here http://dev.laptop.org/~jnettlet/f14/

http://dev.laptop.org/~jnettlet/f14/xorg-x11-drv-chrome-5.74.33-1.fc14.i686.rpm
http://dev.laptop.org/~jnettlet/f14/xo1.5.conf
http://dev.laptop.org/~jnettlet/f14/01-disable-dpms-off.conf

Use rpm to install xorg-x11-drv-chrome-5.74.33-1.fc14.i686.rpm, then
copy the other two files to /etc/X11/xorg.conf.d/

After you restart X you should now be running the chrome video driver.

What works:

- Hardware accelerated rotation
- Multiple XVideo ports, (I.E. skype video chat, ekiga, multiple movies)
- Rotated XVideo support, if you rotate the screen while a movie is
playing it will still be accelerated.
- Texture compositing - if you enable compositing in Metacity things
should not be slow as death.  This is still a WIP and not supported by
us at all, just mentioning it.

What doesn't work:

- Aggressive power saving causes display corruption.  If you are
reliant on this do not switch video drivers.  Normal suspend/resume
like closing the lid should be fine although I have done limited
testing.
- switching between Sugar and GNOME will give you some temporary
display corruption
- DRI is not implemented yet.  I will work on getting that into the
next release.

Please file bugs for anything else you find.  The sooner we find them
the more time I have to fix them.  Try not to file duplicate bugs
please.

Thanks for testing and catch me on #olpc-devel if you need immediate assistance.

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