Re: Why can't i access /dev/dsp or /dev/snd on my XO
What you say does not make any sense to me. The MIDI standard is *one* of many, and in fact the poorest of them all. Besides Csound is probably the most used computer music language with composers of Computer Music and its score an integral part of it. But it is not the only way that can be used to run it: MIDI, OSC, API event calls, etc., are also possible. If anything we should promote better standards than limit ourselves to a very poor one. Victor - Original Message - From: "Albert Cahalan" <[EMAIL PROTECTED]> To: "victor" <[EMAIL PROTECTED]> Cc: Sent: Sunday, January 20, 2008 1:29 AM Subject: Re: Why can't i access /dev/dsp or /dev/snd on my XO > On Jan 19, 2008 4:33 PM, victor <[EMAIL PROTECTED]> wrote: > >> I can't speak for TamTam because I am not involved in their >> design details, but I can say this, Csound's standard score >> preceeds MIDI by at least a decade (or two if you consider where >> it came from). It is much more flexible to convey musical data >> than MIDI. There are MIDI to csound score converters, but >> that is beside the point, because Csound can play MIDI files >> directly, receive realtime MIDI data and even output it. >> There is no problem whatsoever, with the proper instruments, >> Csound will be a MIDI synthesizer like any other. The main >> thing is, that it is not limited to it (thank goodness...). > > How about showing some support for standards by > dropping the non-standard stuff? You can #ifdef it. > Maybe you can even save a few bytes. > > If you really must, you can embed the non-standard > stuff into a MIDI file. It's better to avoid non-standard > stuff entirely of course, and any extended MIDI file > had better play decently on a standard MIDI player. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Why can't i access /dev/dsp or /dev/snd on my XO
Perhaps you are referring to the language rather than the API, when you say it is ghastly. The API is quite neat. I don't have any problems with the language, but some people don't like it. Perhaps you might be interested in looking at the things I am doing to integrate Csound to Sugar a bit more. If so, drop me a note. Victor - Original Message - From: "M. Edward (Ed) Borasky" <[EMAIL PROTECTED]> To: "Albert Cahalan" <[EMAIL PROTECTED]> Cc: "victor" <[EMAIL PROTECTED]>; Sent: Sunday, January 20, 2008 4:25 AM Subject: Re: Why can't i access /dev/dsp or /dev/snd on my XO > Albert Cahalan wrote: >> On Jan 19, 2008 4:33 PM, victor <[EMAIL PROTECTED]> wrote: >> >>> I can't speak for TamTam because I am not involved in their >>> design details, but I can say this, Csound's standard score >>> preceeds MIDI by at least a decade (or two if you consider where >>> it came from). It is much more flexible to convey musical data >>> than MIDI. There are MIDI to csound score converters, but >>> that is beside the point, because Csound can play MIDI files >>> directly, receive realtime MIDI data and even output it. >>> There is no problem whatsoever, with the proper instruments, >>> Csound will be a MIDI synthesizer like any other. The main >>> thing is, that it is not limited to it (thank goodness...). >> >> How about showing some support for standards by >> dropping the non-standard stuff? You can #ifdef it. >> Maybe you can even save a few bytes. >> >> If you really must, you can embed the non-standard >> stuff into a MIDI file. It's better to avoid non-standard >> stuff entirely of course, and any extended MIDI file >> had better play decently on a standard MIDI player. >> ___ >> Devel mailing list >> Devel@lists.laptop.org >> http://lists.laptop.org/listinfo/devel >> > > One of the main reasons I got an XO was because it has CSound. It's a > ghastly API, but it's been around for years and there are thousands of > working instruments! There's a huge book on it, and I doubt very > seriously if anyone will ever come up with a digital sound analysis and > synthesis tool set as comprehensive without investing a lot of effort > re-inventing a bunch of wheels, levers, inclined planes and such. > > By the way -- I've been meaning to check to see if this is in Trac, but > the csound-manual and csound-tutorial RPMs in the repository appear to > be empty. I can install them, but there isn't anything on the machine > after I do. > > I'm also attempting to get some of the Planet CCRMA software loaded on > the system. At this point, all I really want is Common Music -- I don't > need another synthesizer since I have CSound, and I don't need a music > notation program. If anyone else has already done this, I'd love to hear > about it. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New update.1 build 682
<[EMAIL PROTECTED]> writes: > DatabaseVersionError: Flint version file /media/2FD2-5097/.olpc.store/index/iamflint is version > 200709120 but I only understand 200706140 This will be because the Xapian package was accidentally updated to 1.0.4 recently, then your database was updated with this version which automatically upgrades the format, then the Xapian package version was dropped back to 1.0.2, which now can't read the upgraded database. The easiest fix is probably to just rebuild the database. Cheers, Olly ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New update.1 build 682
On Sun, 20 Jan 2008, Olly Betts wrote: > <[EMAIL PROTECTED]> writes: >> DatabaseVersionError: Flint version file > /media/2FD2-5097/.olpc.store/index/iamflint is version >> 200709120 but I only understand 200706140 > > This will be because the Xapian package was accidentally updated to 1.0.4 > recently, then your database was updated with this version which automatically > upgrades the format, then the Xapian package version was dropped back to > 1.0.2, > which now can't read the upgraded database. > > The easiest fix is probably to just rebuild the database. yep, doing a rm -r of .olpc.store fixed the problem David Lang > Cheers, >Olly > > ___ > 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: Why can't i access /dev/dsp or /dev/snd on my XO
On Jan 20, 2008 3:27 AM, victor <[EMAIL PROTECTED]> wrote: > What you say does not make any sense to me. The MIDI > standard is *one* of many, and in fact the poorest of them > all. Besides Csound is probably the most used computer music > language with composers of Computer Music and its > score an integral part of it. I know every developer wants to believe that their own file format is a standard (and a good one too!), but come on now. I went looking for stuff that supports csound. I found **one** program, about 5 wrappers (at least one of which also supported MIDI), and **zero** hardware. The situation with MIDI is radically different; there are a tremendous number of MIDI programs and devices. Perhaps it will be more obvious this way: Notice that the XO ships with a paint program. Suppose that the author invented a nifty new image format. Would it be good to use this format? Notice that the XO ships with a word processor. This word processor could use RTF, OpenDocument, OOXML, TeX, *roff, XHTML... or a custom format that the authors just happen to have invented. What do you think, go with the custom format? Notice that the XO lets you record sound. The most popular unpatented format was used. The authors could have invented their own sound format and used that though. See any problems with doing that? > But it is not the only way that > can be used to run it: MIDI, OSC, API event calls, etc., > are also possible. Excellent. You're ready to drop the non-standard stuff. > If anything we should promote better standards than limit > ourselves to a very poor one. MIDI looks damn good to me. If you really think you have it beat though, go get an RFC and an ISO standard. Get multiple major hardware manufacturers to start building your new standard into their hardware. See if you can get Microsoft and Apple to follow. Then maybe it will be time to begin the process of slowly saying goodbye to MIDI. Only then does the format belong on the XO. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Why can't i access /dev/dsp or /dev/snd on my XO
It's not a matter of trying to get a non-standard format across. Not all; it is a matter of supporting more possibilities. Besides, as I pointed out, MIDI will play alright on Csound, even if it is a poor way of conveying musical data. But hey, if MIDI looks damn good to you, it is worthless trying to say anything else. Good luck. Victor - Original Message - From: "Albert Cahalan" <[EMAIL PROTECTED]> To: "victor" <[EMAIL PROTECTED]>; Sent: Sunday, January 20, 2008 10:18 AM Subject: Re: Why can't i access /dev/dsp or /dev/snd on my XO > On Jan 20, 2008 3:27 AM, victor <[EMAIL PROTECTED]> wrote: > >> What you say does not make any sense to me. The MIDI >> standard is *one* of many, and in fact the poorest of them >> all. Besides Csound is probably the most used computer music >> language with composers of Computer Music and its >> score an integral part of it. > > I know every developer wants to believe that their own > file format is a standard (and a good one too!), but come > on now. I went looking for stuff that supports csound. > I found **one** program, about 5 wrappers (at least one > of which also supported MIDI), and **zero** hardware. > The situation with MIDI is radically different; there are > a tremendous number of MIDI programs and devices. > > Perhaps it will be more obvious this way: > > Notice that the XO ships with a paint program. Suppose > that the author invented a nifty new image format. Would > it be good to use this format? > > Notice that the XO ships with a word processor. This > word processor could use RTF, OpenDocument, OOXML, > TeX, *roff, XHTML... or a custom format that the authors > just happen to have invented. What do you think, go with > the custom format? > > Notice that the XO lets you record sound. The most > popular unpatented format was used. The authors could > have invented their own sound format and used that though. > See any problems with doing that? > >> But it is not the only way that >> can be used to run it: MIDI, OSC, API event calls, etc., >> are also possible. > > Excellent. You're ready to drop the non-standard stuff. > >> If anything we should promote better standards than limit >> ourselves to a very poor one. > > MIDI looks damn good to me. > > If you really think you have it beat though, go get an RFC and > an ISO standard. Get multiple major hardware manufacturers > to start building your new standard into their hardware. See if > you can get Microsoft and Apple to follow. Then maybe it will > be time to begin the process of slowly saying goodbye to MIDI. > Only then does the format belong on the XO. > ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New update.1 build 682
Ok, the problem is that by mistake some unstable builds had a too new version of xapian. We reverted to the known-good older version but it cannot read the indexes created or modified by the later version. Just do this in the terminal with the SD card mounted: mv /media/2FD2-5097/.olpc.store /media/2FD2-5097/.olpc.store.bk After rebooting, the SD card should be correctly recognized by the Journal. Tomeu On Sat, 2008-01-19 at 18:24 -0800, [EMAIL PROTECTED] wrote: > similar effects, but what I'm seeing is after a full power cycle. I'm not > doing a suspend > > attached is the sugar logfile > > David Lang > > On Sat, 19 Jan 2008, Tomeu Vizoso wrote: > > > Date: Sat, 19 Jan 2008 20:02:02 -0500 > > From: Tomeu Vizoso <[EMAIL PROTECTED]> > > To: [EMAIL PROTECTED] > > Cc: [EMAIL PROTECTED] > > Subject: Re: New update.1 build 682 > > > > Hi, > > > > looks like you have found http://dev.laptop.org/ticket/4013 . > > > > Could you check, please? > > > > Should work in latest joyride builds. > > > > Thanks, > > > > Tomeu > > > > On Sat, 2008-01-19 at 18:00 -0800, [EMAIL PROTECTED] wrote: > >> sorry for the delay in responding (I've been traveling for the last week) > >> > >> attached is the messages file, it looks like the system is trying to > >> unmount the SD card immediatly after boot (<2 seconds) > >> > >> I'll enable the sugar debugging and go into the journal immediatly after > >> boot and then see if there is anything interesting there. > >> > >> I'll be upgrading to a new build as soon as the RC is released. > >> > >> David Lang > >> > >> On Wed, 16 Jan 2008, Tomeu Vizoso wrote: > >> > >>> Date: Wed, 16 Jan 2008 10:29:25 -0500 > >>> From: Tomeu Vizoso <[EMAIL PROTECTED]> > >>> To: [EMAIL PROTECTED] > >>> Cc: [EMAIL PROTECTED] > >>> Subject: Re: New update.1 build 682 > >>> > >>> Can you give some more details? > >>> > >>> Particularly, see > >>> http://wiki.laptop.org/go/Attaching_Sugar_Logs_to_Tickets and > >>> also /var/log/messages would be of interest. > >>> > >>> Thanks, > >>> > >>> Tomeu > >>> > >>> On Wed, 2008-01-16 at 07:18 -0800, [EMAIL PROTECTED] wrote: > I can't get the journal to see the SD card with this build. > I can see it from the command line just fine. > > David Lang > > On Tue, 15 Jan 2008, Build Announcer Script wrote: > > > Date: Tue, 15 Jan 2008 15:00:03 -0500 (EST) > > From: Build Announcer Script <[EMAIL PROTECTED]> > > Reply-To: [EMAIL PROTECTED] > > To: [EMAIL PROTECTED] > > Subject: New update.1 build 682 > > > > http://pilgrim.laptop.org/~pilgrim/olpc/streams/update.1/build682/ > > > > -Paint-15.xo > > +Paint-17.xo > > -Read-38.xo > > +Read-40.xo > > -Record-49.xo > > +Record-50.xo > > -Terminal-5.xo > > +Terminal-8.xo > > -Web-83.xo > > +Web-84.xo > > +bash.i386 0:3.2-19.fc7 > > -bash.i386 0:3.2-9.fc7 > > -gnash.i386 0:0.8.1-1.olpc2 > > +gnash.i386 0:0.8.1-2.olpc2.20071226cvs > > -gnash-plugin.i386 0:0.8.1-1.olpc2 > > +gnash-plugin.i386 0:0.8.1-2.olpc2.20071226cvs > > -hulahop.i386 0:0.4.0-1.olpc2 > > +hulahop.i386 0:0.4.0-2.olpc2 > > -initscripts.i386 0:8.54.1-15.olpc2 > > +initscripts.i386 0:8.54.1-17.olpc2 > > -libabiword.i386 0:2.6.0.svn20071106-1 > > +libabiword.i386 0:2.6.0.svn20071127-1 > > -libabiword-plugins.i386 0:2.6.0.svn20071106-1 > > +libabiword-plugins.i386 0:2.6.0.svn20071127-2 > > -libxml2.i386 0:2.6.29-1.fc7 > > +libxml2.i386 0:2.6.31-1.fc7 > > -libxml2-python.i386 0:2.6.29-1.fc7 > > +libxml2-python.i386 0:2.6.31-1.fc7 > > -mingetty.i386 0:1.07-5.2.2 > > +mingetty.i386 0:1.07-9.olpc2 > > -ohm.i386 0:0.1.1-6.1.20080102git.fc7 > > +ohm.i386 0:0.1.1-6.3.20080102git.fc7 > > -olpc-utils.i386 0:0.63-1.olpc2 > > +olpc-utils.i386 0:0.63-2.olpc2 > > -pyabiword.i386 0:0.6.0.svn20071106-1 > > +pyabiword.i386 0:0.6.0.svn20071127-1 > > -rainbow.noarch 0:0.7.6-1.olpc2 > > +rainbow.noarch 0:0.7.8-1.olpc2 > > -sugar-evince.i386 0:2.20.0-4.olpc2 > > +sugar-evince.i386 0:2.20.1.1-1.olpc2 > > -sugar-evince-python.i386 0:2.20.0-4.olpc2 > > +sugar-evince-python.i386 0:2.20.1.1-1.olpc2 > > -sugar.i386 0:0.75.7-1 > > +sugar.i386 0:0.75.8-1 > > -totem.i386 0:2.18.2-11 > > +totem.i386 0:2.18.2-12 > > -totem-mozplugin.i386 0:2.18.2-11 > > +totem-mozplugin.i386 0:2.18.2-12 > > -totem-plparser.i386 0:2.18.2-11 > > +totem-plparser.i386 0:2.18.2-12 > > -xkeyboard-config.noarch 0:1.1-7.20071130cvs.olpc2 > > +xkeyboard-config.noarch 0:1.1-8.20071130cvs.olpc2 > > -xulrunner.i386 0:1.9-0.beta1.9.olpc2 > > +xulrunner.i386 0:1.9-0.beta2.1.olpc2 > > > > --- Paint-17 --- > >* Make the fix for #5586 work with security. (tomeu) > > > > --- Read-40 --- > >* Fix zoom-to-width (tomeu), #5866 > > > > --- Record-50 --- > > * #4525 updates > > * #5899 workaro
Re: Update.1 & testing
I know that we're supposed to all be developers here, and know how to change the firmware in our sleep; but it would be great to include a link to instructions. I searched the wiki - http://wiki.laptop.org/go/Manual_Firmware_Install is worse than useless, and http://wiki.laptop.org/go/OLPC_Firmware_q2d09#Unsecure_Machines is the wrong place (why include separate instructions on each firmware build page, instead of having a general instructions page?) and also does not tell you how to do it using SD instead of USB or internal. I'll take responsibility for putting the instructions on the wiki and making appropriate links to them, if someone tells me how to do it with SD. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
OLPC and GLX
After compiling in mesa source to get GLX working on the FC7-based builds. Running `glxgears -fullscreen` I get ~25 fps. Compared to Ubuntu which gets 65 fps, this is rather poor. I think the Ubuntu performance shows that 3D (albeit simple 3D) is very possible and worthwhile. I've tried the amd and fbdev drivers - they make no performance difference. Neither does i386 versus i586 (w/ mmx and 3dnow! included in cflags). I haven't tried DRI. I don't understand how it would help if I understand DRI correctly, but perhaps I'm missing something. I have no idea if processes that are re-niced automatically, or have some sort of resource limitation. I'm using the default xorg.conf. I hope the problem is something simple that I'm not seeing. Thanks. -Bryan Duff ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: OLPC and GLX
Bryan Duff wrote: > After compiling in mesa source to get GLX working on the FC7-based > builds. Running `glxgears -fullscreen` I get ~25 fps. Compared to > Ubuntu which gets 65 fps, this is rather poor. > > I think the Ubuntu performance shows that 3D (albeit simple 3D) is very > possible and worthwhile. > > I've tried the amd and fbdev drivers - they make no performance > difference. Neither does i386 versus i586 (w/ mmx and 3dnow! included > in cflags). > > I haven't tried DRI. I don't understand how it would help if I > understand DRI correctly, but perhaps I'm missing something. I have no > idea if processes that are re-niced automatically, or have some sort of > resource limitation. > > I'm using the default xorg.conf. I hope the problem is something simple > that I'm not seeing. > > Thanks. > > -Bryan Duff > ___ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel > Have you profiled any of the code? Compiled it with gcc flags for the architecture (mmx and 3dnow)? Then again, maybe the AMD libraries have some assembler kernels for this. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Update.1 & testing
Jameson "Chema" Quinn wrote: > I know that we're supposed to all be developers here, and know how to > change the firmware in our sleep; but it would be great to include a > link to instructions. I searched the wiki - > http://wiki.laptop.org/go/Manual_Firmware_Install is worse than > useless, and > http://wiki.laptop.org/go/OLPC_Firmware_q2d09#Unsecure_Machines is the > wrong place (why include separate instructions on each firmware build > page, instead of having a general instructions page?) and also does > not tell you how to do it using SD instead of USB or internal. > > I'll take responsibility for putting the instructions on the wiki and > making appropriate links to them, if someone tells me how to do it > with SD. Will you also take responsibility for handling the complaints I get (have gotten) for not having the manual installation instructions in each relnotes page? The procedure for SD is similar to that for USB, except that you use "sd:" instead of "u:" to specify the device. > > > > ___ > 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: Update.1 & testing
On Jan 20, 2008 1:07 PM, Mitch Bradley <[EMAIL PROTECTED]> wrote: > Jameson "Chema" Quinn wrote: > > I know that we're supposed to all be developers here, and know how to > > change the firmware in our sleep; but it would be great to include a > > link to instructions. I searched the wiki - > > http://wiki.laptop.org/go/Manual_Firmware_Install is worse than > > useless, and > > http://wiki.laptop.org/go/OLPC_Firmware_q2d09#Unsecure_Machines is the > > wrong place (why include separate instructions on each firmware build > > page, instead of having a general instructions page?) and also does > > not tell you how to do it using SD instead of USB or internal. > > > > I'll take responsibility for putting the instructions on the wiki and > > making appropriate links to them, if someone tells me how to do it > > with SD. > > Will you also take responsibility for handling the complaints I get > (have gotten) for not having the manual installation instructions in > each relnotes page? Simple. Put the manual install instructions in http://wiki.laptop.org/go/Manual_Firmware_Install and then, in each relnotes page add {{:Manual_Firmware_Install}}, which will include the text of that page in the one it is as a template in. If you want to be even cooler, in Manual_Firmware_Install, put the tags and on the stuff that you want to be included. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New update.1 build 682
On Sun, 20 Jan 2008, Tomeu Vizoso wrote: > Ok, the problem is that by mistake some unstable builds had a too new > version of xapian. We reverted to the known-good older version but it > cannot read the indexes created or modified by the later version. > > Just do this in the terminal with the SD card mounted: > > mv /media/2FD2-5097/.olpc.store /media/2FD2-5097/.olpc.store.bk > > After rebooting, the SD card should be correctly recognized by the > Journal. yes, after removing this dir it's recognised again. thanks. David Lang > Tomeu > > On Sat, 2008-01-19 at 18:24 -0800, [EMAIL PROTECTED] wrote: >> similar effects, but what I'm seeing is after a full power cycle. I'm not >> doing a suspend >> >> attached is the sugar logfile >> >> David Lang >> >> On Sat, 19 Jan 2008, Tomeu Vizoso wrote: >> >>> Date: Sat, 19 Jan 2008 20:02:02 -0500 >>> From: Tomeu Vizoso <[EMAIL PROTECTED]> >>> To: [EMAIL PROTECTED] >>> Cc: [EMAIL PROTECTED] >>> Subject: Re: New update.1 build 682 >>> >>> Hi, >>> >>> looks like you have found http://dev.laptop.org/ticket/4013 . >>> >>> Could you check, please? >>> >>> Should work in latest joyride builds. >>> >>> Thanks, >>> >>> Tomeu >>> >>> On Sat, 2008-01-19 at 18:00 -0800, [EMAIL PROTECTED] wrote: sorry for the delay in responding (I've been traveling for the last week) attached is the messages file, it looks like the system is trying to unmount the SD card immediatly after boot (<2 seconds) I'll enable the sugar debugging and go into the journal immediatly after boot and then see if there is anything interesting there. I'll be upgrading to a new build as soon as the RC is released. David Lang On Wed, 16 Jan 2008, Tomeu Vizoso wrote: > Date: Wed, 16 Jan 2008 10:29:25 -0500 > From: Tomeu Vizoso <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: Re: New update.1 build 682 > > Can you give some more details? > > Particularly, see > http://wiki.laptop.org/go/Attaching_Sugar_Logs_to_Tickets and > also /var/log/messages would be of interest. > > Thanks, > > Tomeu > > On Wed, 2008-01-16 at 07:18 -0800, [EMAIL PROTECTED] wrote: >> I can't get the journal to see the SD card with this build. >> I can see it from the command line just fine. >> >> David Lang >> >> On Tue, 15 Jan 2008, Build Announcer Script wrote: >> >>> Date: Tue, 15 Jan 2008 15:00:03 -0500 (EST) >>> From: Build Announcer Script <[EMAIL PROTECTED]> >>> Reply-To: [EMAIL PROTECTED] >>> To: [EMAIL PROTECTED] >>> Subject: New update.1 build 682 >>> >>> http://pilgrim.laptop.org/~pilgrim/olpc/streams/update.1/build682/ >>> >>> -Paint-15.xo >>> +Paint-17.xo >>> -Read-38.xo >>> +Read-40.xo >>> -Record-49.xo >>> +Record-50.xo >>> -Terminal-5.xo >>> +Terminal-8.xo >>> -Web-83.xo >>> +Web-84.xo >>> +bash.i386 0:3.2-19.fc7 >>> -bash.i386 0:3.2-9.fc7 >>> -gnash.i386 0:0.8.1-1.olpc2 >>> +gnash.i386 0:0.8.1-2.olpc2.20071226cvs >>> -gnash-plugin.i386 0:0.8.1-1.olpc2 >>> +gnash-plugin.i386 0:0.8.1-2.olpc2.20071226cvs >>> -hulahop.i386 0:0.4.0-1.olpc2 >>> +hulahop.i386 0:0.4.0-2.olpc2 >>> -initscripts.i386 0:8.54.1-15.olpc2 >>> +initscripts.i386 0:8.54.1-17.olpc2 >>> -libabiword.i386 0:2.6.0.svn20071106-1 >>> +libabiword.i386 0:2.6.0.svn20071127-1 >>> -libabiword-plugins.i386 0:2.6.0.svn20071106-1 >>> +libabiword-plugins.i386 0:2.6.0.svn20071127-2 >>> -libxml2.i386 0:2.6.29-1.fc7 >>> +libxml2.i386 0:2.6.31-1.fc7 >>> -libxml2-python.i386 0:2.6.29-1.fc7 >>> +libxml2-python.i386 0:2.6.31-1.fc7 >>> -mingetty.i386 0:1.07-5.2.2 >>> +mingetty.i386 0:1.07-9.olpc2 >>> -ohm.i386 0:0.1.1-6.1.20080102git.fc7 >>> +ohm.i386 0:0.1.1-6.3.20080102git.fc7 >>> -olpc-utils.i386 0:0.63-1.olpc2 >>> +olpc-utils.i386 0:0.63-2.olpc2 >>> -pyabiword.i386 0:0.6.0.svn20071106-1 >>> +pyabiword.i386 0:0.6.0.svn20071127-1 >>> -rainbow.noarch 0:0.7.6-1.olpc2 >>> +rainbow.noarch 0:0.7.8-1.olpc2 >>> -sugar-evince.i386 0:2.20.0-4.olpc2 >>> +sugar-evince.i386 0:2.20.1.1-1.olpc2 >>> -sugar-evince-python.i386 0:2.20.0-4.olpc2 >>> +sugar-evince-python.i386 0:2.20.1.1-1.olpc2 >>> -sugar.i386 0:0.75.7-1 >>> +sugar.i386 0:0.75.8-1 >>> -totem.i386 0:2.18.2-11 >>> +totem.i386 0:2.18.2-12 >>> -totem-mozplugin.i386 0:2.18.2-11 >>> +totem-mozplugin.i386 0:2.18.2-12 >>> -totem-plparser.i386 0:2.18.2-11 >>> +totem-plparser.i386 0:2.18.2-12 >>> -xkeyboard-config.noarch 0:1.1-7.20071130cvs.olpc2 >>> +xkeyboard-config.noarch 0:1.1-8.20071130cvs.olpc2 >>> -xulrunner.i386 0:1.9-0.beta1.9.olpc2 >>> +xulrunner.i386 0:1.9-0.beta2.1.olpc2 >>> >>> --- Paint-17 --- >>>* Make the fix for #5586 work with security. (tomeu) >>> >>> --- Read-40 ---
Re: Update.1 & testing
> > Simple. Put the manual install instructions in > http://wiki.laptop.org/go/Manual_Firmware_Install and then, in each > relnotes page add {{:Manual_Firmware_Install}}, which will include the text > of that page in the one it is as a template in. > > If you want to be even cooler, in Manual_Firmware_Install, put the tags > and on the stuff that you want to be included. > > I've done this - and, even cooler, I used a template parameter so that you can have the instructions refer to the right version, like this: {{:Manual_Firmware_Install|version=q2d09}} . ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Why can't i access /dev/dsp or /dev/snd on my XO
Sorry all - this thread re got me riled, I have to jump in on Victor's side here... On 20 Jan 2008, at 10:18, Albert Cahalan wrote: > I know every developer wants to believe that their own > file format is a standard (and a good one too!), but come > on now. I went looking for stuff that supports csound. > I found **one** program, about 5 wrappers (at least one > of which also supported MIDI), and **zero** hardware. > The situation with MIDI is radically different; there are > a tremendous number of MIDI programs and devices. Sorry Albert, but I think you may be *slightly* missing the point of Csound. - It *does* handle MIDI files really well - It's a very well established format that has been around decades, long before MIDI. - There is no hardware support for it, since it has always been a *software* sound design and manipulation tool and was designed for that job, unlike MIDI which was designed as a hardware protocol and had all manner of additional "responsibilities" foisted on it later. - Lots of computer music, at many levels from hobby users to serious research, gets done with Csound. It is a credible and viable option, and quite possibly the *correct* option for an *education focussed* platform. > Perhaps it will be more obvious this way: > > Notice that the XO ships with a word processor. This > word processor could use RTF, OpenDocument, OOXML, > TeX, *roff, XHTML... or a custom format that the authors > just happen to have invented. What do you think, go with > the custom format? Perhaps it will be more obvious this way: - MIDI is like a plain text format for music. - Csound is like a rich text, it allows considerably more subtle nuances. Subtle nuances are the heart of music. The Csound program can handle this rich text, but it can also read the plain text (MIDI) when it has too. Another point that people are skipping over here is the subtle cultural bias (maybe that should be Cultural Bias in a project like this, where it matters that we avoid bias!) that MIDI introduces. This *really* bothers me for a tool we are planning to deploy in large numbers in many different cultures. The basic MIDI design implicitly assumes a western style scale, with essentially equal-temperament, and a minimum interval of a semitone. [Of course, we grew up with music expressed with those constraints, and most western listeners hear equal-temperament as it if were correct (if they can hear it at all!) - but that's very much a learned response. To ears raised on more natural musical voicing, it sounds really artificial, forced and un-natural.] Now, it is *possible* to correct these problems in MIDI (e.g. by messing with the tuning on a per-note basis, that sort of thing) but it is non-trivial. So people will use the defaults, and that's probably a Bad Thing. Csound, on the other hand, is readily capable of true temperament, or micro-tonal scales, or etc.. That's got to be a good thing. > MIDI looks damn good to me. Sure - and plain text is The Way to code software. We all use it all the time. But for a more fancy-shmancy document you want some sort of fancy editor. Horses for courses - but if you have to choose just one, pick the fancy one, since it can work as the simple one when it has too. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Update.1 & testing
Jameson "Chema" Quinn wrote: > > > Simple. Put the manual install instructions in > http://wiki.laptop.org/go/Manual_Firmware_Install and then, in > each relnotes page add {{:Manual_Firmware_Install}}, which will > include the text of that page in the one it is as a template in. > > If you want to be even cooler, in Manual_Firmware_Install, put the > tags and on the stuff that you want > to be included. > > > I've done this - and, even cooler, I used a template parameter so that > you can have the instructions refer to the right version, like this: > {{:Manual_Firmware_Install|version=q2d09}} . Thanks, that will make it easier to maintain new versions of the page. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
RE: Testing the Wireless driver changes
After downloading the firmware, the ARM is told by the boot2 to jump to a specific location of the internal memory. If the firmware is not downloaded, the boot2 starts the grab the firmware from the Flash and jumps to the same location of the internal memory once that is done. The flash tool does not figure out anything here. The boot2 code is smart enough to figure that out. Best Regards, Ronak From: Michail Bletsas [mailto:[EMAIL PROTECTED] Sent: Saturday, January 19, 2008 10:23 AM To: Dan Williams; Ronak Chokshi Cc: Ricardo Carrano; devel; David Woodhouse; Giannis Galanis; [EMAIL PROTECTED] Subject: Re: Testing the Wireless driver changes > > Does the Boot2 code take care of figuring out the correct address to > write the thick firmware to, or does the flash tool have to figure out > the address to write it to? Normally this address is embedded in the > firmware flash file header, is there an address the tool should check > for to verify, or is that address completely irrelevant because the > boot2 code is smart enough to figure out where to put it? > Dan, You have to ask Ronak that. Right now the flash writing logic lives in the firmware. M. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Update.1 & testing
On Jan 20, 2008 6:46 PM, Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote: >AC not present > > Am I missing something here? I also downloaded q2d09.rom.{sha1,md5,asc} > to the same place just in case, but it didn't make a difference. > Plug in the AC adapter to the wall. -ffm ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Update.1 & testing
Jeremy Fitzhardinge wrote: > ok flash n:\boot\q2d09.rom > Reading n:\boot\q2d09.rom > Got firmware version: CL1 Q2D09 Q2D > Checking integrity ... > AC not present > Duh. I just realized this is referring to the fact that its not plugged into mains power rather than anything to do with the "Checking integrity..." line. I guess there's always a way to misinterpret the plainest message. J ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO wireless firmware, etc.
On Jan 20, 2008 10:10 AM, RHS Linux User <[EMAIL PROTECTED]> wrote: > > Hi, > >I have been following XO for some time. I see you are looking for > someone to help with open firmware for the Marvel chipset. Indeed. Have you looked at the Wiki page on the effort? http://wiki.laptop.org/go/Marvell_microkernel and sign yourself up. Can you answer any of the questions there? Are you on the OLPC devel mailing list? You can sign up at http://lists.laptop.org/ Our IRC channel is #olpc http://wiki.laptop.org/go/Communication_channels >I AM willing to help. I have considerable RF experience along with low > level software. Regards realtime OSs, I write my own. And doing 96k of > code doesn't seem that difficult. Even the RF part is not that tough. > >That said, I think a MUCH more useful direction would be to document > the 'mesh' protocol in sufficient detail so anyone could duplicate it with > whatever hardware, including the RF protocol and timers. That is the point of the 802.11s standard work. >I suspect you will discover that Marvell is STRONGLY opposed to this > effort despite their statements otherwise. And also that this is the part > EFF is most as strongly in favor of. No surprises there. No worries, either. >I am glad to see that the Linux end of the driver is getting some work. > This is a good place to begin. > >Personally despite the considerable work envolved, I think a 2nd > implementation using an open radio chip and one of the ADC-FPGA > combinations readily available would be well worth the effort. > >It could serve as a reference platform to ensure production radios > really work correctly as well as offering a way to add other devices by > other manufacturers to the XO mesh system. I can introduce you to other people working on Open Source Hardware if you like. >I am open to whatever suggestions you might have regards how I might > help with your efforts. Take a look at the existing Wiki pages and code, and we'll discuss it further. >Good luck with the XO program. > >warm regards from COLD Concord, NH USA >--anonymous for now-- >[EMAIL PROTECTED] Thank you. -- Edward Cherlin End Poverty at a Profit by teaching children business http://www.EarthTreasury.org/ "The best way to predict the future is to invent it."--Alan Kay ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Update.1 & testing
Mitch Bradley wrote: > Jameson "Chema" Quinn wrote: > >> >> Simple. Put the manual install instructions in >> http://wiki.laptop.org/go/Manual_Firmware_Install and then, in >> each relnotes page add {{:Manual_Firmware_Install}}, which will >> include the text of that page in the one it is as a template in. >> >> If you want to be even cooler, in Manual_Firmware_Install, put the >> tags and on the stuff that you want >> to be included. >> >> >> I've done this - and, even cooler, I used a template parameter so that >> you can have the instructions refer to the right version, like this: >> {{:Manual_Firmware_Install|version=q2d09}} . >> > Thanks, that will make it easier to maintain new versions of the page. I'm not having much success with these instructions. I downloaded q2d09.rom into /versions/boot/current/boot, rebooted into OFW and typed "flash n:\boot\q2d09.rom" as the instructions say. However I get: ok flash n:\boot\q2d09.rom Reading n:\boot\q2d09.rom Got firmware version: CL1 Q2D09 Q2D Checking integrity ... AC not present ok Am I missing something here? I also downloaded q2d09.rom.{sha1,md5,asc} to the same place just in case, but it didn't make a difference. Thanks, J ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Project Hosting Application: Lab
I have a significant majority of the base code written for Lab and plan to get at least a working standalone version within the next few weeks. 1. Project name : Lab Activity 2. Existing website, if any : None as of yet 3. One-line description : A scientific analysis and interface activity 4. Longer description : This activity is designed to allow full-featured : analysis of data collected from the XO Mic in port, : networked XOs, Measure log files, and numerous : other sources. It aims to integrate _analysis_ of : the data with the actual data collection. 5. URLs of similar projects : http://wiki.laptop.org/go/Measure 6. Committer list Please list the maintainer (lead developer) as the first entry. Only list developers who need to be given accounts so that they can commit to your project's code repository, or push their own. There is no need to list non-committer developers. Username Full name SSH2 key URL - #1 nasa Nicholas Sinnott-Armstrong https://www.cs.dartmouth.edu/~nasa/ssh2key.pub Email: [EMAIL PROTECTED] If any developers don't have their SSH2 keys on the web, please attach them to the application e-mail. 7. Preferred development model [X] Central tree. Every developer can push his changes directly to the project's git tree. This is the standard model that will be familiar to CVS and Subversion users, and that tends to work well for most projects. [ ] Maintainer-owned tree. Every developer creates his own git tree, or multiple git trees. He periodically asks the maintainer to look at one or more of these trees, and merge changes into the maintainer-owned, "main" tree. This is the model used by the Linux kernel, and is well-suited to projects wishing to maintain a tighter control on code entering the main tree. If you choose the maintainer-owned tree model, but wish to set up some shared trees where all of your project's committers can commit directly, as might be the case with a "discussion" tree, or a tree for an individual feature, you may send us such a request by e-mail, and we will set up the tree for you. 8. Set up a project mailing list: [ ] Yes, named after our project name [ ] Yes, named __ [X] No When your project is just getting off the ground, we suggest you eschew a separate mailing list and instead keep discussion about your project on the main OLPC development list. This will give you more input and potentially attract more developers to your project; when the volume of messages related to your project reaches some critical mass, we can trivially create a separate mailing list for you. If you need multiple lists, let us know. We discourage having many mailing lists for smaller projects, as this tends to stunt the growth of your project community. You can always add more lists later. 9. Commit notifications [ ] Notification of commits to the main tree should be e-mailed to the list we chose to create above [ ] A separate mailing list, -git, should be created for commit notifications [X] No commit notifications, please 10. Shell accounts As a general rule, we don't provide shell accounts to developers unless there's a demonstrated need. If you have one, please explain here, and list the usernames of the committers above needing shell access. 11. Translation [X] Set up the laptop.org Pootle server to allow translation commits to be made [ ] Translation arrangements have already been made at ___ 12. Notes/comments: ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
jabber for non-wireless XO ?
I don't have any wireless. I do have a wired ethernet connection to a LAN (which in turn uses a proxy to reach the internet). Even when I specify in sugar-control-panel the name of a real server, my XO is not accessing jabber (the field in olpc-netstatus is shown blank). I believe my proxy can correctly pass requests for ports 5222-5223. Does telepathy work with a wired ethernet? Does it have a problem if the connection is through a proxy? mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: OLPC and GLX
Hi, > There should be no particular reason why Ubuntu would have better > *software* GL rendering performance than Fedora, although hardy > ships with gcc 4.2, which could make a big difference. glxgears opens a window, but the software rendering performance will depend not just on that window, but also on the contents of the rest of the screen at the time. Perhaps the Ubuntu desktop had xfce in the background, and the OLPC desktop had the sugar home view, and perhaps there is a difference in rendering load between the two? (He said, with gale-force handwaving.) - Chris. -- Chris Ball <[EMAIL PROTECTED]> ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: OLPC and GLX
Bryan Duff wrote: > After compiling in mesa source to get GLX working on the FC7-based > builds. Running `glxgears -fullscreen` I get ~25 fps. Compared to > Ubuntu which gets 65 fps, this is rather poor. One last thing: I'm very curious about this disparity: could you please provide more details? What versions of Mesa and the X servers have you been using? Was the depth exactly the same? Could you run glxinfo on both systems? How did you build the Fedora X server? What compiler did you use and what optimization flags? There should be no particular reason why Ubuntu would have better *software* GL rendering performance than Fedora, although hardy ships with gcc 4.2, which could make a big difference. -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: OLPC and GLX
(please forgive minor mistakes as I was in a hurry and I had no time to double-check some of the facts reported below. Feel free to point out corrections, of course). Bryan Duff wrote: > After compiling in mesa source to get GLX working on the FC7-based > builds. Running `glxgears -fullscreen` I get ~25 fps. Compared to > Ubuntu which gets 65 fps, this is rather poor. > > I think the Ubuntu performance shows that 3D (albeit simple 3D) is very > possible and worthwhile. Nobody ever thought 3D was impossible or unfeasible on an full blown x86 CPU at 466MHz, when it very clearly was possible even on the 8bit, 1MHz, C64 with no hardware floating point support. My question is: why are you trying so hard to achieve *unaccelerated*, *indirect*, *GLX* support when it would be much easier and faster to just use OpenGL in-process and then XPutImage the resulting buffer? > I've tried the amd and fbdev drivers - they make no performance > difference. Neither does i386 versus i586 (w/ mmx and 3dnow! included > in cflags). Of course it makes no difference because the server-side software renderer gets used in both cases. And this renderer happens to be exactly the same code of Mesa, only built in a slightly different way. There's no need to run benchmarks to find this out. A simple inspection of the source code would reveal that there are no hardware accelerated paths in Mesa for the Geode. Although, some primitive form of GL acceleration could certainly be implemented for very trivial operations. > I haven't tried DRI. I don't understand how it would help if I > understand DRI correctly, but perhaps I'm missing something. I have no > idea if processes that are re-niced automatically, or have some sort of > resource limitation. Uh? DRI is the in-kernel support for DMA, command queue completion interrupts and now TTM and memory management for *direct* rendering clients. On the other hand, the indirect (i.e. server side) rendering path you're using historically happened without DRI's help because it was unaccelerated anyway. The X server still had some interaction with DRI in order to coordinate window management operations with direct rendering clients. Recently, Kristian Høgsberg did a huge architectural shift in order to add 3D acceleration to the server-side Mesa renderer. This is AIGLX. While AIGLX is somewhat slower than direct rendering due to the overhead of the GLX wire protocol, and generally not recommended for 3D intensive games, it is no doubt the way to go to achieve 3D desktop effects, and to redirect 3D clients to off-screen buffers so that their output can be further processed. At this time, the AIGLX effort is halfway finished: the basic features work beautifully and efficiently, but XVideo does not yet play by the rules, and mouse input keeps ignoring the 3D transformations. Another big show stopper for a fully 3D Linux desktop is that it needs aggressive graphics card memory usage in a multitasking environment, which requires a sophisticated memory manager with a smart swap-in policy to keep things fast on a crowded desktop. Although an implementation already exists, the underlying design is still being debated and could possibly undergo further changes before it will find its way into the kernel. -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: OLPC and GLX
I'm working do duplicate this part presently by setting up a gentoo on the OLPC to make sure I'm not missing anything. Outside of that I'll try out OSMesa. -Bryan Bernardo Innocenti wrote: > Bryan Duff wrote: > >> After compiling in mesa source to get GLX working on the FC7-based >> builds. Running `glxgears -fullscreen` I get ~25 fps. Compared to >> Ubuntu which gets 65 fps, this is rather poor. > > One last thing: I'm very curious about this disparity: could > you please provide more details? What versions of Mesa > and the X servers have you been using? Was the depth exactly > the same? Could you run glxinfo on both systems? How did > you build the Fedora X server? What compiler did you use > and what optimization flags? > > There should be no particular reason why Ubuntu would have > better *software* GL rendering performance than Fedora, > although hardy ships with gcc 4.2, which could make a big > difference. > ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel