Re: html5 codecs on 1.75
On 02/02/2012 05:10 PM, Peter Robinson wrote: On Thu, Feb 2, 2012 at 8:05 PM, Sameer Verma sve...@sfsu.edu wrote: Is this something missing on the Firefox end? No, html5 video support was added in Firefox 4. I think you'll find it has firefox 3.6.x This is not true. Firefox has supported HTML5 video/ (with Ogg Theora) since version 3.5. WebM support was introduced in 4.0. --Ben signature.asc Description: OpenPGP digital signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: optimal font rendering settings for XO display
On 01/25/2012 07:59 PM, Sridhar Dhanapalan wrote: What are the optimal font rendering settings for the XO's display? Not sure about optimal, but on a clean build the defaults are: Fonts are Sans and Sans bold 201 dpi Smoothing = Grayscale Hinting = Slight I suspect these defaults are also the optimum. Should I set subpixel smoothing and hinting? No. Subpixel smoothing will only reduce quality when used on an XO laptop. Subpixel smoothing relies on the particular geometry of a standard laptop display, and does not work on OLPC's Pixel Qi displays. --Ben signature.asc Description: OpenPGP digital signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: OLPC Policies Question Concerning Upgrading Default Installed Software
On 01/11/2012 05:21 PM, anth...@evolutionindesignz.com wrote: it is presumed that replacing XULRunner 1.9.1.9 should not cause problems in browser functionaltiy. That's an extremely dangerous thing to presume. I presume that you're actually going to test the browser extensively after performing the upgrade to ensure that the upgrade doesn't break the browser. Are there any other dependencies that we should concern ourselves with(assuming that it is not against OLPC policies to perform the upgrade)? The other activities that use Xulrunner (e.g. Wikipedia) are all very similar to Browse, so the upgrade is unlikely to cause problems in one but not another. As for dependencies of the browser, you should check that you have not caused a regression in plugin support, especially as relates to the Totem and Gnash plugins. --Ben signature.asc Description: OpenPGP digital signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-3 Announcement?
On 01/10/2012 06:28 PM, Richard A. Smith wrote: In case you missed my previous comment on 1.75 on devel@ the maximum runtime power draw of the 1.75 is 5W. (Not including the extra 5W you can draw from the USB port.) ... One difference between the XO-1.75 and XO-3 is that the XO-3 can _also_ be powered by USB On-The-Go (OTG). Cool. This will allow some slightly insane but also possibly useful power chaining. For example, it might be a reasonable backup for when a child's power brick breaks. Obviously chains longer than 2 are an iffy proposition ... but might be worth testing just to make sure they don't crash and/or burn. --Ben signature.asc Description: OpenPGP digital signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Marvell 88W8388 and 802.11s
On 09/12/2011 06:01 PM, Spencer Johnson wrote: How can one implement 802.11s into a wireless adapter? In software (firmware) on the CPU. http://wiki.laptop.org/go/88W8388#CPU --Ben signature.asc Description: OpenPGP digital signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Sugar and GTK updates
On 08/16/2011 11:49 AM, Kevin Gordon wrote: My concern is that feature creep, and with concurrent support dependency increases, it could make the footprint and hardware requirements so large on an XO-1, that it becomes untenable. Has there been discussion as to when the development cycle might stop for the older XO-1's, (perhaps strawmanning in as F14 with .94), so that this innovation and progress can continue on the more modern platforms? This is a reasonable concern. I am just watching from the sidelines, but I can tell you: 1. IMHO builds running on XO-1 already have the flavor of backports, with XO-1.5 being the primary development target. I don't think anyone is delaying Sugar development due to XO-1 constraints. 2. The system requirements (especially disk space) are affected more by changes in Fedora than changes in Sugar. A large amount of disk space is taken up by files whose presence is unnecessary. Customizing the build to exclude these files takes significant human effort to execute and test (see http://dev.laptop.org/ticket/4281), especially if the tradeoff is different for XO-1 vs. XO-1.5. 3. XO-1 support is likely to be dropped when deployments indicate that they have lost any interest in upgrading them. --Ben signature.asc Description: OpenPGP digital signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Server-devel] [Sugar-devel] copy files to/from server
On 05/17/2011 03:42 AM, Sridhar Dhanapalan wrote: How can XOs copy files to/from their Journal with a server? The simplest solution is probably HTTP. Set up a little local website with an upload/download form. Moodle, or even a generic CMS like Drupal or Wordpress, would work, but the very simplest option is probably something like http://www.net2ftp.com/ combined with an FTP server on the same host (and configured for automatic login on the local network). --Ben signature.asc Description: OpenPGP digital signature ___ Server-devel mailing list server-de...@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: WebM format for Record
On 04/09/2011 02:00 PM, Daniel Drake wrote: Ben, what are your thoughts on Theora vs WebM for Record? You mentioned at one point that Theora developers were considering focusing on the low-power arena (being displaced by WebM on the high-power high-res front), is that direction being taken? Essentially, yes. The WebM encoder (libvpx) has always been much slower than libtheora because VP8 is much more computationally intensive than Theora. The libtheora devs have been working to expand this difference by adding encoder speed optimizations. The latest versions of libtheora (1.2 alphas, and maybe even more in SVN head) contain a lot of work to speed up encoding. I have recommended several times that OLPC ship 1.2-prerelease libtheora in the default build, due to the significant speed improvements. So encoding speed is quite a big deal Indeed. I don't see WebM as being a realistic option for Record until OLPC gets WebM encoders in silicon, which will presumably be after XO-3. --Ben signature.asc Description: OpenPGP digital signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Record activity performance
Just so everyone knows, there have recently been major speedups in the Theora encoder (libtheora), which is a bottleneck for Record performance. These speedups are available in version 1.2-alpha1, which (despite the name) is the recommended version for all but the most conservative applications. It has zero known bugs and is ABI-compatible with all preceding versions. http://downloads.xiph.org/releases/theora/libtheora-1.2.0alpha1.tar.gz I don't know how to get new versions of things into OLPC builds, but if people are interested in Record performance this is probably worthwhile. Version 1.2alpha1 at speed-level 2 should be faster and better than what is currently in use. --Ben signature.asc Description: OpenPGP digital signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] customizing olpc-os-builder image
On 11/02/2010 05:13 AM, javed khan wrote: can anybody tell me how to accomplish the following using olpc-os-builder 1: install new fonts 2: change the keyboard layout and default language 3: change the boot animation sugar-devel@ is not really the right mailing list for this question. You should ask on devel@lists.laptop.org (cc'd). The people on that list are more likely to know about olpc-os-builder. I don't know anything about olpc-os-builder, but just by searching wiki.laptop.org I found http://wiki.laptop.org/go/Fonts#Installing_fonts http://wiki.laptop.org/go/Tweaking_the_boot_animation http://wiki.laptop.org/go/Customizing_NAND_images#Language signature.asc Description: OpenPGP digital signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Edit/audit wikipedia activity
On 10/21/2010 12:06 PM, Martin Langhoff wrote: Unfortunately, there is a clear need to organise a facility to audit/edit the wikipedia snapshots we have and repack the archive. Do we have any easy way to do this? I'm the wrong person to answer this question, but the activity's archive production system does already have support for an article blacklist (and indeed many articles were excluded from the current bundles). I don't know who is in possession of this list, or exactly who took responsibility for producing the most recent version. Nonetheless, excluding articles is easy. Actually editing article text is not something we have attempted AFAIK. Ideally, I think, we would fix textual problems upstream as they are discovered. The most recent available snapshots for English and Spanish are 10-14 days old, so this strategy does create a delay, during which time things can continue to change. In general, I believe that auditing wikipedia is a fool's errand. There are 3.5 million articles in English Wikipedia, growing by over a thousand a day. Spanish wikipedia has 650,000 articles. If people want to create snapshots containing only whitelisted articles, that's fine, but many of the links will be broken and the amount of information will be much reduced. --Ben signature.asc Description: OpenPGP digital signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: SD/MMC cards, a year later
On 08/18/2010 11:24 PM, John Watlington wrote: Nonetheless, we are going to try testing it with UbiFS and considering whether any durability improvement justify the increased price (now up to 2x) and built-in obsolescence of using raw NAND chips. If it hits 2x in price, I guess you might be able to start benchmarking against RAID-1 of two MicroSD cards. RAID-1 gets you reliability, repairability, and a 2x boost in read bandwidth. I suppose that's only a consideration if the Armada can support 2 (or 3!) SD controllers. --Ben signature.asc Description: OpenPGP digital signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO 1.75 screen
On 08/02/2010 08:54 AM, Bert Freudenberg wrote: Please, if at all possible, stay with a 4:3 ratio. It's easy to scale content, but to redesign it for 16:9 is hard even for professionals (*). For wide screens we'll probably want to follow Ubuntu Unity and put our menu bar on the short edge. Since the menu bar typically occupies the long edge on 4:3 screens, the activity's real content area would then experience a smaller difference in aspect ratio. --Ben signature.asc Description: OpenPGP digital signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Activity packaging
On 07/06/2010 11:51 AM, Bernie Innocenti wrote: Ok, I think the requirements for activity bundles could be: 1) Support multiple CPU architectures 2) Support multiple distros (and different versions of same distro) 3) Centralized build cluster (submit one source package, get multiple binary packages) 4) Support inter-bundle dependencies (e.g.: GCompris + voices, OOo4Kids + dictionaries) 5) Support activity - OS dependencies (e.g.: espeak for Speak, squeak for etoys...) 6) Work with any programming language (setup.py is python-centric) 7) Easy to learn for activity writers without too much distro-hacking experience These requirements would fit well both rpm and deb, with OpenSUSE Build Service or their native build clusters. I think you are missing an important requirement: installation without elevated permissions. --Ben P.S. This cross-posting is getting ridiculous. signature.asc Description: OpenPGP digital signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: #10045 HIGH 1.5-sof: XO-1.5 Record audio/video are out of sync with each other
On 05/13/2010 03:26 AM, James Cameron wrote: We discussed this briefly in team meeting this morning ... Record is writing an uncompressed stream to SD, before then compressing it in the Save step once the video recording is stopped. (I could be wrong). This means that no matter what the size of the buffer memory, if the data rate from the camera exceeds the rate at which we can write to SD, there will be skips once a recording is long enough to fill the buffer. ... So we determine the data rate by choosing height, width, and frame rate from the camera. We determine the maximum rate according to the choice of SD media. If I understand correctly, Record does compress the video on the fly. It's the audio that it writes uncompressed to disk for later compression and muxing. I don't know at what quality it performs audio recording, but it might be as low as 32 KB/s uncompressed. --Ben signature.asc Description: OpenPGP digital signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Net died
I have a XO-1.5 (C2 I think). I logged out of my ssh account, closed it up, took it to the airport, turned it on, and it wouldn't find a wifi network. Linux didn't see a network interface, or even try to load libertas. OFW's wlan test fails because it doesn't find the card. Maybe the card came unseated? Maybe this is a since-resolved manufacturing problem? My screwdriver is six time zones away, so I can't diagnose further right now. --Ben ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: The All-Singing, All-Dancing XCompMGR
On Thu, 29 Apr 2010, Chris Ball wrote: It also increased the speed of switching between windows. Agreed, and this seems like the strongest reason in favor of shipping it Before you do, please verify that there hasn't been a regression in functionality. 1. Visibility X Compositing makes it difficult for programs to work out whether they are visible to the user, and actions that rely on that information may not work. I know that I have written several activities that use visibility to disable display functionality, in order to conserve CPU. Sugar also checkpoints each activity on task-switch. If xcompmgr is interfering with that switch detection, that could create a big speedup, at a cost in reliability. 2. Video You'll at least have to test video playback, which was one of the sticking points with compositing on the XO-1. 3. VRAM On the XO-1, there were concerns that compositing could run the machine out of video memory if many windows were open, leading to all sorts of issues. That might still be an issue on XO-1.5, especially at 32bpp. XO-1.5 is also far from immune to OOM issues, so memory pressure in general is a concern. --Ben ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New keyboard layouts
On Wed, 28 Apr 2010, Walter Bender wrote: On Wed, Apr 28, 2010 at 12:24 PM, Tiago Marques tiago...@gmail.com wrote: I was just looking at the layout again and just noticed the new arrow keys placement. We debated this one. A shorter shift key would be difficult to type on. We opted to emulate the hjkl vi arrangement. Keyboard layout is virtually the ultimate bikeshed painting problem ... but here's my opinion anyway. Ins and Del are Harmful. You probably know Ins because when you accidentally bump it, your editor switches into overwrite mode, and every character you type deletes another until you figure out what happened and hit Ins again. Del is the reverse erase that nobody wants. Apple, and the XO-1, have eliminated Ins and relegated Del to Fn+Erase. I recommend removing both. Getting rid of those keys frees up valuable space that can be used, for example to move += to the top row, replaced by ?, replaced by up-arrow. No more hjkl. Some other notes: 1. fn is a bad key because software can't reuse it. For example, on the XO-1 we tried to make fn+F1 send an F1 press to the activity (instead of going to the mesh view), but it was not possible because the fn key is treated specially by the keyboard microcontroller, and not forwarded to the OS. There was no way to tell from software whether a user had pressed fn+F1 or just F1. Accordingly, on new keyboards, OLPC should consider pushing this special handling into the software keyboard mapping as much as possible. It's hard to see why fn+Spacebar needs to be a new keycode, and not just a series of standard up/down events. The only tricky spot I can think of is PageUp/PageDown/Home/End. 2. We have a lot of redundant modifier keys. fn, altgr, and hand-key could all be a single key, because they are never used together. If the keyboard controller would turn altgr+left into Home (etc.), there should be no regression of functionality, even under windows. --Ben ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New keyboard layouts
On Wed, 28 Apr 2010, Paul Fox wrote: part of the impetus for this keyboard is that it be more normal, for use by older students, perhaps in non-sugar environments. Sure. I'm actually arguing that Ins and Del are no longer normal, and mainstream computers far more popular than the XO often don't have them. Getting rid of those keys frees up valuable space that can be used, for example to move += to the top row, replaced by ?, replaced by up-arrow. No more hjkl. i'd far rather have as much of the punctuation in their correct places as possible. I suggested this change in particular because it puts += much closer to its standard location. Careful about correct though. A few minutes on a UK keyboard may remind you that even countries with the same language have widely varying common layouts. if you watch /dev/input/eventN, where N is the right device for the keyboard, you'll get a KEY_FN code for the Fn key. and if you use it to modify F1, you'll get KEY_FN_F1 instead of KEY_F1. Interesting. I don't know much about keyboard handling in X. Maybe we were just mistaken, or maybe the problem is at the X layer. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] stopwatch activity
On Tue, 27 Apr 2010, Sameer Verma wrote: I noticed something interesting with he stopwatch activity on the XO 1.5 C2 with build 120. When the XO goes into suspend, the clock stops display, but upon resume, will show actual time elapsed (clock keep counting). Mark also works correctly, displaying the time when the Mark button is clicked, irrespective of the display. I'm not sure what the behavior should be, though. I think that's fine behavior. Most stopwatches don't stop running by themselves, so I don't see why ours should. Should the activity prevent suspend? My philosophy is that suspend should be _absolutely transparent_ to the user; i.e. its effects should not be detectable, in the same way that processor voltage scaling is undetectable. This suggests that Stopwatch should inhibit suspend while it is visible onscreen. I'm reluctant to do this, though, because it feels like an ugly hack. The right solution would be for the suspend system to recognize that Stopwatch has a timer set to expire in 100 ms, and postpone suspend. --Ben ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Adobe Flash 10.1 + AIR 2.0 on the XO
Tiago Marques wrote: I don't think H.264 needs licensed codecs but I'm not sure on that. H.264 is at the top of MPEG-LA's list of codecs that require patent licensing. All the MPEG codecs are on the list, including MP3 and AAC. If you don't want to buy a license, Theora and Vorbis (the Ogg codecs) are basically the only game in town. --Ben signature.asc Description: OpenPGP digital signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Adobe Flash 10.1 + AIR 2.0 on the XO
John Watlington wrote: EVERY codec need licenses. I know that the FOSS community thinks that Theora is unencumbered, but it has never been tested in court (there hasn't ever been anybody worth suing using it.) Google, Opera, and Mozilla have all funded work on Theora and are distributing implementations of it. Over a hundred million copies. All three have performed internal legal analyses. All three have concluded that it is not a patent risk, and can be distributed royalty-free. Really. Theora and Vorbis are clear according to these three. Other distributors include Red Hat, Novell, Canonical, and every other Linux distributor. Major video games like Ghostbusters and Chronicles of Riddick use Theora and Vorbis. So there hasn't ever been anybody worth suing seems untrue to me. This becomes a real problem when we start asking hardware vendors to provide firmware supporting these free codecs. If they provide them, they then become a choice target for an infringement suit. These codecs have been out for a decade. No one has ever been sued. No one has ever been threatened with a lawsuit. No one has ever claimed to hold a patent that applies to any of them. In past jobs I've purchased codecs, and a large part of what is being purchased is indemnity against infringement lawsuits. Really? The MPEG-LA licenses explicitly contain zero indemnity. I'm not aware of anyone who actually provides indemnity for codec patent infringement. --Ben signature.asc Description: OpenPGP digital signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Adobe Flash 10.1 + AIR 2.0 on the XO
I hate to reply twice, but John Watlington wrote: it has never been tested in court This is a non sequitur. A codec cannot be proved patent-free in a court. It can only be proved that some particular patent does not apply. If this is your standard, then buying licenses doesn't help, because a court cannot prove that some other unknown company doesn't hold an applicable patent. This becomes a real problem when we start asking hardware vendors to provide firmware supporting these free codecs. If a vendor is too paranoid to provide firmware, then we can write our own. They just need to provide docs, or partial firmware source code, under an NDA if necessary. Documentation does not expose them to any patent liability. --Ben signature.asc Description: OpenPGP digital signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] RFC: change to XO sleep behavior
Paul Fox wrote: now: in the new scheme, the idle sequence has changed: after a fairly brief period of inactivity, the system will suspend, leaving the screen on. (the user may not even know this has happened.) assuming there is still no keyboard activity, a little later the screen will dim, and sometime after that, the screen will blank. Why will the screen blank? Why not just deactivate the backlight? Is the DCON's power draw sufficiently high that blanking the screen represents real savings? --Ben signature.asc Description: OpenPGP digital signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New XO-1.5 10.2.0 build 112
Mikus Grinbergs wrote: ... there is only one way to make the system reliable, and that is to implement power saving via Cpuidle. My concern is that it might be difficult to tune Cpuidle to distinguish between non-essential processing (which could tolerate suspending) versus background activity whose completion the user is nevertheless awaiting (and which should preferably avoid suspending). As far as I know it is impossible. Daniel Drake, I think, put tremendous effort into fixing our userspace, so that no non-essential wakeups occur at all. This, I think, is the best solution. I use ethernet rather than wireless. Historically, my systems have suspended despite an ongoing (via ethernet) data transfer -- that's why at home (when my XOs are plugged in to AC) I disable suspend. I am doubtful whether Cpuidle would consider the small amount of CPU processing involved with handling ethernet packet interrupts as exceeding whatever idle threshold it has been designed to recognize. It doesn't have an idle threshold. If the kernel were correctly configured, bringing up your usb ethernet connection would automatically prevent suspend. --Ben signature.asc Description: OpenPGP digital signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New XO-1.5 10.2.0 build 112
Paul Fox wrote: how exactly do we think this is supposed to work? Not to repeat myself, but there is only one way to make the system reliable, and that is to implement power saving via Cpuidle. Cpuidle is integrated with the process scheduler and kernel timers, so cpu activities (like responding to a ping) are never indefinitely delayed by sleep. I cannot imagine any userspace solution that is not susceptible to race conditions of the type you describe. --Ben signature.asc Description: OpenPGP digital signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: surprisingly early suspend
John Watlington wrote: I'm under the impression that our desire to stay with a stock operating system is one of the big remaining limitations, but could be wrong. My impression: Linux is capable of the desired behavior in general, via the cpuidle framework, which chooses to transition between sleep states based on the transition latencies, system activity, and upcoming timer events. Cpuidle separates policy from implementation by using pluggable backends in the form of cpuidle drivers that handle state transitions [1]. At present, the only cpuidle driver in the kernel is the ACPI driver (drivers/acpi/processor_idle.c). I do not know whether the XO's CPU deactivation, DCON, and timed wakeup system can be, or has been, mapped into an ACPI state. If ACPI is insufficient to represent the XO's behavior, then a new cpuidle driver will be required. I expect such a driver would be accepted into the upstream kernel. Writing it should not be hugely difficult, but I do not have enough experience to provide a good estimate of the amount of work required. --Ben [1] http://www.mjmwired.net/kernel/Documentation/cpuidle/driver.txt signature.asc Description: OpenPGP digital signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Video Chat, Video Editing and VOIP activities for Sugar
Manusheel Gupta wrote: Dear friends, 6 developers working at SEETA http://seeta.in will be spearheading the design and development of video chat, video editing and VOIP activities in Sugar starting Feb. 15. Great! 1. Video Chat - Pidgin (http://www.pidgin.im/) 3. VOIP activity - Shtoom (http://divmod.org/trac/wiki/ShtoomProject) I think you'd be better off starting from Empathy (http://live.gnome.org/Empathy), which already provides both features and is built on the same communications platform (Telepathy) that Sugar already uses. 2. Video Editor - PiTiVi (http://www.pitivi.org/) Yes. PiTiVi is the ideal starting point. Wish to have your feedback on issues, implementation strategies and external dependencies that we might have overlooked. Definitely talk to the Telepathy developers (on their mailing list and #telepathy on freenode). They are very helpful. --Ben signature.asc Description: OpenPGP digital signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: OLPC hardware: what if there was an SDR modem / chipset?
Luke Kenneth Casson Leighton wrote: if i want to write my own peer-to-peer 802.11 algorithms, doing an implementation e.g. of the Babel routing algorithm to run actually on the WIFI chip itself, can i do so, right now, _without_ being forced to sign a Marvell NDA? The 88W8686 in the XO-1.5 is basically a dumb interface. There isn't really a WIFI chip that can run anything. This means that yes, you _can_ implement Babel as a first-class mesh implementation on the XO-1.5, just by running it on the CPU. This is unlike the XO-1, which used the 88W8388's built-in ARM core to handle mesh routing without waking up the CPU. The ostensible disadvantage of mesh routing on the CPU (which, btw, was tried with Cerebro on the XO-1) is that it prevents the CPU from sleeping to save power. According to the OLPC product plan, the next laptop is supposed to be the XO-1.75, with an ARM CPU. Given ARM's ability to do fast suspend+resume, it's possible that running short tasks on the main CPU (like forwarding one packet) would be just as efficient as running them on some coprocessor. So don't be discouraged from pursuing interesting routing algorithms. Also, consider implementing them with the kernel's 802.11s stack. 802.11s allows basically any routing algorithm as long as all nodes agree. --Ben signature.asc Description: OpenPGP digital signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Android, OLPC, and native hosting
NoiseEHC wrote: What you do not want to recognize is that you are excluding a lot of developers who do not want to waste their time because of the lack of IDEs. We are trying to provide stepping stones. One of those steps is the Develop activity [1], which is a Sugar-oriented IDE for Activity development. Develop has been part of the Sugar plan from the very beginning, with the first references in 2006 [2]. In my view, Develop is by far the most important missing feature in Sugar. I don't know much about Develop's current functionality, and I can't test it this week. I do think it's important that we get it working, polished, and included by default. --Ben [1] http://wiki.laptop.org/go/Develop [2] http://wiki.laptop.org/index.php?title=Old_Develop_activityoldid=18516 signature.asc Description: OpenPGP digital signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
XO-3 official
http://www.forbes.com/2009/12/22/tablet-computer-negroponte-technology-cio-network-olpc.html It aims to make its tablet PC highly durable, all plastic, waterproof, half the thickness of an iPhone and use less than a watt of power, despite an 8-gigaherz processor. The price: an unprecedented $75. Well, that's cool. Deciphering OLPC press releases sometimes feels like I'm playing chess with Picasso, and he keeps breaking the rules, and I can't tell whether this is some kind of art or he's just cheating. --Ben signature.asc Description: OpenPGP digital signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 1.5 - gnome-packagekit?
Walter Bender wrote: Slightly off topic, but reading between the lines, it seems there is something more fundamentally broken here. 5000 packages. The Apple app store adds that many new apps every week it seems. Why aren't there 5 million packages available instead of just 5000? Money. The App Store is proprietary software. You have to buy it, and some of that money goes to the author. People write apps because they hope to make money from it. In contrast, we are reliant on the charitable motives of software engineers, which restricts us to some (particularly noble!) subset. Note that the incentive is not particularly to write _new_ software. You can duplicate the functionality of someone else's app and just hope to grab a piece of the market for that function. The incentive is also not particularly to write useful software; it's to write software that someone will pay for. In terms of useful functionality provided, I suspect Fedora's repo does at least as well as the App Store, and maybe a lot better. --Ben ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Server-devel] [IAEP] Sharing EToys projects
Dave Bauer wrote: Do you happen to know what the mime type should be for Etoys to open it? The list of mime types that the eToys activity will open is at http://dev.laptop.org/git/projects/etoys/tree/activity.info.in I'm sure one of the eToys expert can give you better advice than I on which mime type is preferred. --Ben signature.asc Description: OpenPGP digital signature ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: Wanted: List of Sugar activities for the XO-1.5
Samuel Klein wrote: [ADD UNSTAR] VNC Launcher Not sure what this category is for, but I feel like I need to put in a plug for Watch Me [1]. VNC Launcher lets an XO copy its screen to a non-Sugar client with VNC software. Watch Me, wraps this process into a pure Sugar form, so that XOs running Sugar can share their screens with each other. [1] http://activities.sugarlabs.org/sugar/addon/4205 signature.asc Description: OpenPGP digital signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Wanted: List of Sugar activities for the XO-1.5
I'd suggest Stopwatch http://dev.laptop.org/~bemasc/StopWatchActivity-3.xo --Ben signature.asc Description: OpenPGP digital signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Camera saturation - image compression level
Bastien wrote: - shots of the moon are often saturated: how to reduce the gain of the camera? Ideally one would like to do this manually... I never figured out how to control the gain from software. - is there a way to take pictures with a higher resolution? the default compression level doesn't produce great pictures. Yes, sort of. Last year I figured out a way to capture and reconstruct the raw data from the camera using a higher quality demosaicing algorithm. The process is documented here: http://lists.laptop.org/pipermail/devel/2008-February/011029.html --Ben signature.asc Description: OpenPGP digital signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Importing images in Write documents makes file huge
Philipp Kocher wrote: Is it possible to install an libabiword-olpc rpm of version 2.7.6 or newer? Note that this represents a flag day change. Users with version below and above will not be able to collaborate, at least when trying to share documents containing jpeg images. --Ben signature.asc Description: OpenPGP digital signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-1.5 slow disk writes
Daniel Drake wrote: Today I tried to figure out why running sync often takes 5-10 seconds or longer. This slows down suspend, where all data is synced to disk. On the XO-1, it was necessary to sync before suspend, because there was no guarantee that a suspended laptop would reawaken any time soon. On 1.5 (and even on XO-1 with newer software) we should have fully working timed wakeups. That means the kernel could set a policy of a sync every 5 minutes, and wake up out of suspend in order to perform the sync. This is, IMHO, actually better than a sync on every suspend policy, because it enables things like write combining that improve performance and reduce flash wear. Of course, getting sync to be very fast would also be nice. --Ben signature.asc Description: OpenPGP digital signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] On Sugar 0.84 - status of the Chat/collab leader issue...
Martin Langhoff wrote: On Tue, Nov 3, 2009 at 2:41 PM, Gary C Martin g...@garycmartin.com wrote: Other activities that support some form of collaboration like Chat, Browse, Etoys, TurtleArt, Arithmetic, Maze, Pippy, etc, etc, don't care who started the activity first, or who goes away. Are you positive about this? I don't meant to troll -- but I am seeing issues (with Chat for example) where if the leader goes, 3rd parties cannot join anymore. That is remarkable, and worth investigating. The Chat activity in particular is designed to survive loss of the initiator, and has been since the very first release. One related issue is http://bugs.sugarlabs.org/ticket/934 . Once the initiator leaves, the initiator can no longer re-join due to an issue in the GUI. That bug contains a patch, but it's unclear to me whether that patch was ever applied. Maybe Tomeu can clarify the situation. --Ben signature.asc Description: OpenPGP digital signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
XO-2 canceled, replaced by XO-1.75 and XO-3.0
The ever entertaining Prof. Negroponte surpasses all expectations in his latest performance: http://www.xconomy.com/boston/2009/11/02/negroponte-outlines-the-future-of-olpc-hints-at-paperlike-design-for-third-generation-laptop/ The usual OLPCNews analysis at http://www.olpcnews.com/people/negroponte/negroponte_xo-175_goes_arm_xo-2_is_cancelled.html --Ben signature.asc Description: OpenPGP digital signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Terminal.xo patch: do not die if the cwd is gone
Martin Langhoff wrote: use GNU Screen! :-) -- now that would be something: GNU Screen integrated with xterm. Not to toot my own horn, but GNU Screen + OpenSSH + Terminal.xo = ShareTerm : http://lists.sugarlabs.org/archive/sugar-devel/2009-May/014165.html Doesn't help you with persistence, though, unless you really want to leave Screen running forever. --Ben signature.asc Description: OpenPGP digital signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: OOM conditions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Richard A. Smith wrote: Working the table at the Boston book festival I was reminded how painful the OOM stuff is on a gen 1. The OOM problem on Gen 1 is a True Kernel Bug. The problem is that the OOM killer just isn't working. Almost all the time, it fails to kill _any_ process, and instead just locks up the machine. I believe Andres was able to connect via a serial port during one of these events, and observed the kswapd process in an uninterruptible sleep (a.k.a. state D). This should never happen. There has been a significant amount of churn in the OOM system over the past few years, and a number of bugs are known to have been created and resolved. To the best of my knowledge, no one has ever precisely identified whether the XO's problem is due to one of them. Until recently, there was no newer XO kernel with which to test. It would be worthwhile to observe the F11-XO1 builds' behavior at OOM, to see if there has been an improvement. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) iEYEARECAAYFAkrrwMsACgkQUJT6e6HFtqTW1gCdHsEpOD5djVFtq0k3h8z6BqvE aC4An3Sp0c+lpwmkNBoxDNEct3z5bfe4 =/INZ -END PGP SIGNATURE- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Sharing files among several XO
Bert Freudenberg wrote: The Distribute activity would be your best bet I guess. Where is it? http://dev.laptop.org/~bemasc/Distribute-1.xo Distribute is the barest prototype of a sharing activity, designed purely as a proof of concept. It is unmaintained, has essentially no user interface, and is not available in any language other than English. The code is a simplified derivative of the hackish HTTP-based sharing system from Read. Any attempts to revive it are welcome. This is the first time I've ever heard of anyone even attempting to use it. --Ben signature.asc Description: OpenPGP digital signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Testing] first play with new XO 1.5 machines
Martin Langhoff wrote: I now realize we'd forgotten about Cerebro. If anyone is going to take the hard road, it may be a viable option -- did we ever have a clear plan of what it'd take to integrate it fully (where 'fully' means that things just work at least roughly to where they do on 8.2.1). On the XO-1, the answer was reverse-engineer the Libertas firmware, recode Cerebro from scratch in C to run at the network layer, even when the CPU is off, and write a new kernel driver that can interface with it. Now that XO-1.5 can no longer forward packets in suspend, reaching parity is somewhat simpler. It still requires, at a minimum, that someone complete the abandoned Telepathy-Synapse connection-manager. In short, it's a major engineering effort involving 802.11 and Telepathy. I would love for someone to take it on, but I haven't heard any noise about it in months. signature.asc Description: OpenPGP digital signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Testing] first play with new XO 1.5 machines
Martin Langhoff wrote: On Thu, Oct 22, 2009 at 11:51 AM, Daniel Drake d...@laptop.org wrote: 2009/10/22 Tomeu Vizoso to...@sugarlabs.org: What would be more reliable in the under a tree use case: ad-hoc or mesh with a max of 1 hop? Mesh, since everyone does their own beaconing. That's my guess too. But the hard-to-answer question is how much more reliable? So we can answer is it worth the big effort? There is only one way to find out. Both Salut (Clique and Avahi) and 802.11 ad-hoc beaconing have complex behavior in the face of unreliable connections. I do not think we are likely to be able to predict the result of their interaction. That's why OLPC has a testing team. signature.asc Description: OpenPGP digital signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: tap-to-click feedback
Daniel Drake wrote: Really I think the biggest issue is that they press it by accident while typing or making other motions and have no idea why the screen has changed significantly (they don't understand that it's because they clicked, or that their hand was near the pad). Normally, Synaptics touchpads use logic that (1) ignores large-area contact, assuming it's an accidental touch with the palm, and (2) disables the touchpad while the keyboard is active. If those measures are not in place, there will be a problem regardless of tap-to-click. I don't know where in the stack this logic lives. If that logic is already active, then it sounds like further measures are warranted. signature.asc Description: OpenPGP digital signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-1.5 follow-on impression
Mikus Grinbergs wrote: Was able to use the XO-1.5 (os32) at another location, connected without a proxy. I don't quite understand this statement. Were you connected to the XO-1.5 over the internet, using a technique like X forwarding or VNC? The principal user-perception experience where improvement would still be welcome is video support. Changes to the screen (e.g., show/hide Frame) are not being done smoothly. And when viewing moving pictures, the currently scanty hardware acceleration (e.g., ticket #9407) is noticeable. In the case of a remote desktop session over the internet, video performance is almost always limited by the network and protocol, not the server hardware's rendering speed. signature.asc Description: OpenPGP digital signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] erasing the journal and config
Sameer Verma wrote: So, here's my request. Can someone whip up an activity that does the following: In my view, this is not appropriate for an Activity. Sugar Activities are not for managing the system. Also, as you noted, if Rainbow is active then this is difficult or impossible, and this is deliberate. Preventing Activities from wiping your system is the #1 reason for Bitfrost. This makes me *very* curious. Shouldn't there be a way to erase the configuration and journal without having to reflash the whole image? As you noted, it's trivial to do this at the Terminal. Therefore, it is also trivial to do it from the Sugar shell. The obvious place for this feature, to me, is in the Control Panel, under a label like Erase Everything with appropriate warning text. For lending libraries, a shortcut for this feature in a frame device or under the XO-man might be appropriate. --Ben signature.asc Description: OpenPGP digital signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: creating seperate dbus-tubes in a single instance of a shared actvity
Creating multiple D-Bus tubes may or may not be a good idea in your case. Each D-Bus tube can support many simultaneous parallel transmissions, because D-Bus provides a routed transport. Every D-Bus object has an interface and a path, which allows D-Bus objects to address each other individually. In this way, Gnome uses a single (local) session bus for all your desktop D-Bus needs, and an activity can typically use a single Tube. Within Sugar, there's not much incentive to use a single Tube with many objects or many Tubes. Outside of Sugar, the service type of a Tube is used to determine which applications can connect to it, so each complete service should get a single Tube, labeled with the service's well-known name. Eventually, this will be documented at http://people.collabora.co.uk/~davyd/telepathy-book/ --Ben signature.asc Description: OpenPGP digital signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Faster Multicast [was Re: WatchMe-1, a VNC activity]
Martin Langhoff wrote: - can we use multicast frames... and get the APs speeds bumped up to do a fast multicast so as to not use up all the airtime? This would be great... and I just realized that it might also be tremendously beneficial for Telepathy-Salut. Salut uses multicast for two things: presence (mDNS) and D-Bus Tubes (a homebrew network protocol called Clique). mDNS is a classic multicast/broadcast system, where if you miss a packet, you just have to wait for the next round. Clique, however, is a reliable multicast system, guaranteeing in-order delivery, etc. In other words, Clique can tolerate some packet loss, because it knows how to request retransmission. My understanding is that APs use the basic rate for multicast because they presume it is an unreliable transport, and the basic rate is the least likely to drop a packet. However, for Clique, it might actually be more effective to use the highest available rate, even if it causes occasional retransmissions due to loss. I don't know how to test this, but I think there's a chance it could be a big win. Of course, in situations where the mDNS presence information itself is overloading the network, there's not much we can do. --Ben signature.asc Description: OpenPGP digital signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Disk layout for XO-1.5
Martin Langhoff wrote: On Wed, Aug 5, 2009 at 11:52 PM, Albert Cahalanacaha...@gmail.com wrote: BTW, note that the flash disk itself is not certain to be fail-safe in the face of powerloss. Neither the firmware Sure. In practice it seems to be extremely safe, as wedged NAND is one thing we haven't seen in the field (or on our dev machines). And jffs2 is designed to survive unclean shutdowns. The XO-1.5 will not be using raw NAND, nor will it be running jffs2. There will be a microcontroller (running uneditable proprietary firmware) emulating a block device. Firmware of this type is sometimes done well, and sometimes done poorly, as regards atomicity. I would urge OLPC to search for a device whose controller firmware can be modified, but I suspect OLPC has already written off that possibility. --Ben signature.asc Description: OpenPGP digital signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Disk layout for XO-1.5
Martin Langhoff wrote: I would urge... ...you are preaching to the ultra-converted, to the frustrated. I wasn't personally involved, but I know at least Wad Mitch looked quite deep into this, and found no good offers. There is good evidence to trust them in hardware and low level firmware matters :-) Indeed; I didn't mean to suggest otherwise. If they have written off the possibility of open disk controller firmware, I am sure they have made the right decision. --Ben signature.asc Description: OpenPGP digital signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Disk layout for XO-1.5
Richard A. Smith wrote: In the end we chose to use microSDHC cards. For MP, will they be soldered down or on contacts? I like this; I think it creates the potential for all sorts of interesting hackery and upgrades. --Ben signature.asc Description: OpenPGP digital signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Disk layout for XO-1.5
Mitch Bradley wrote: The filesystem is no longer internally compressed. The current size for the XO-1.5 system is 1.1 GB. Interesting. Build 767 had an ext3 version: http://download.laptop.org/xo-1/os/official/767/ext3/xo-1-olpc-stream-8.2-build-767-20081001_1633-devel_ext3-tree.tar.bz2 Uncompressed, the tarball weighs 524 MB, less than half 1.1 GB. Every meg is precious, every meg is good. --Ben signature.asc Description: OpenPGP digital signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: A1 Motherboard specs diagram
NoiseEHC wrote: There are no free 3D drivers. I have heard nothing to indicate that there are likely to be soon. I would be surprised if OLPC were to ship the proprietary drivers, though I cannot speak for them. Then please test the xvideo extension with sleep/resume. I assumed (wrongly) that there was some way to stretch-blit bitmaps to the video memory on X (as the Geode video processor is clearly up to this rescaling task). You are mistaken. The Geode LX has a two scaler units, and neither can feed back to the main CPU. One of them is in the Geode Display Controller (not the DCON), and simply scales the entire screen to the output. The other is in the Video Controller, and can be used only for overlay scaling. Either way, the scaled output is never written to video memory. The Graphics Controller, which can manipulate video memory, does not contain a scaler. Unfortunately it turned out (or I am mistaken) that the only way to scale animations is to use the xvideo extension. However it is unusable on the XO-1 because of this bug. If the XO-1.5 will not have working OpenGL out of the box then probably it would be wise to have the only usable X feature for games in a working condition. http://dev.laptop.org/ticket/9307 I agree, it would be valuable to fix this bug. ps: If somebody could prove me wrong in that X is not a clusterfuck and can do strectch blits then I would be happy... The only way X could do stretch blits on the XO-1 hardware would be to interpolate on the CPU. --Ben signature.asc Description: OpenPGP digital signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Availability of XO-1.5 ATest-2 machines
Paul Fox wrote: but to be clear, david's right that once the laptop's in this state there's no way to turn off the screen automatically later on -- the system must be re-awakened with user input, and then put to sleep in one of the usual (power switch or lid) ways. this is simply a limitation of current s/w. I think this is one of several good reasons why moving to cpuidle would be big win for XO-1.5 It solves the problem of managing wakeup timers, and does it in a perfectly abstracted fashion, requiring no alterations to userspace. Adding wakeup timer management to OHM sounds like a big pain, and yet another maintenance burden. --Ben signature.asc Description: OpenPGP digital signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Availability of XO-1.5 ATest-2 machines
da...@lang.hm wrote: On Mon, 20 Jul 2009, Paul Fox wrote: chris wrote: Hi, my understanding from watching discussions here was that when the system went to sleep it powered down the display, because there was no way to set a timer to wake the system up a little later to then turn off the display. Your understanding is incorrect, I'm afraid. We do not power down the display going into idle-suspend. but to be clear, david's right that once the laptop's in this state there's no way to turn off the screen automatically later on -- the system must be re-awakened with user input, and then put to sleep in one of the usual (power switch or lid) ways. this is simply a limitation of current s/w. is this just a software limitation? Yes. You can use the rtcwake command to set wakeup timers for the future from userspace. However, my impression is that this is only safe if the timer is at least 2 seconds in the future at the time of suspend, due to a potential race with the EC. OHM could be modified to make use of rtcwake to, for example, wake up from sleep after 30 minutes, turn off the backlight, and suspend again. It simply hasn't been done. --Ben signature.asc Description: OpenPGP digital signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Techteam] XO-1.5 Kernel Update (i.e My Weekly Status)
Richard A. Smith wrote: In any case time based suspend is not where we want to go anyway. We need proper idle detection and some sort of API such that apps which have a workload that idle detection is difficult can specify that they need idle-suspend. I'm repeating myself (I promise I'll stop) but the method for this in Linux is cpuidle.[1] cpuidle is incredibly poorly advertised, but it's a very good system. It maintains a list of all available CPU states, along with the latency to enter and exit them. Because it operates inside the kernel, mode selection can be made with full knowledge of any upcoming timed wakeup requests from userspace. To handle unpredictable interrupts, cpuidle uses recent history to predict the frequency of future interrupts, and then chooses processor states to meet an associated latency requirement. It seems likely to me that this will avoid any need for a special idleness API. cpuidle is already used by the kernel to select the ACPI state, but it is possible to add more states as well. Therefore, it seems to me that the logical thing to do is to add the frozen state to cpuidle's menu. --Ben [1] http://lwn.net/Articles/221791/ signature.asc Description: OpenPGP digital signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Techteam] XO-1.5 Kernel Update (i.e My Weekly Status)
Paul Fox wrote: benjamin m. schwartz wrote: cpuidle is already used by the kernel to select the ACPI state, but it is possible to add more states as well. Therefore, it seems to me that the logical thing to do is to add the frozen state to cpuidle's menu. perhaps this should be obvious, but can it handle S-states as well? because i believe that's the goal -- freeze the display and then go into S3. My impression is that this has never been done, presumably due to the absence of a DCON on other ACPI machines.I know nothing about kernel internals or suspend-resume, so I cannot comment intelligently on the difficulty of supporting S3+DCON in cpuidle. --Ben signature.asc Description: OpenPGP digital signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Techteam] XO-1.5 Kernel Update (i.e My Weekly Status)
Richard A. Smith wrote: Benjamin M. Schwartz wrote: To handle unpredictable interrupts, cpuidle uses recent history to predict the frequency of future interrupts, and then chooses processor states to meet an associated latency requirement. It seems likely to me that this will avoid any need for a special idleness API. How will it do with an app like acoustic measure? I see what you're saying. (This program proved a problem in the past because it would use very little CPU while playing and recording sound, resulting in idleness detection kicking in and turning off the CPU entirely.) Audio playback and recording don't use userspace timers, but they do generate a lot of interrupts. If cpuidle does something even marginally sane with interrupt history, it should not go into a high-latency sleep state during sound playback or recording. If it does, audio will skip, but the CPU will be woken up by every interrupt delivered from the sound card. (It occurs to me that this probably should've happened for the XO-1 too, but it didn't. Maybe the EC is not handling those interrupts properly?) Hopefully, this shouldn't be a problem even if cpuidle is dumb, because drivers can specify their latency requirements explicitly using pm_qos_add_requirement(). During recording, the sound driver should set a low enough interrupt latency requirement so that buffer overruns do not occur. cpuidle will then not enter states with too high an interrupt latency. I believe the HDA audio driver code already does this. --Ben signature.asc Description: OpenPGP digital signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Techteam] XO-1.5 Kernel Update (i.e My Weekly Status)
Chris Ball wrote: Hi, perhaps this should be obvious, but can it handle S-states as well? because i believe that's the goal -- freeze the display and then go into S3. Looks like no. Oh? From looking at the code? Do you mean that it can't, or that it doesn't now? We could invent a C-state that traps to SMI and goes to S3 except I hate this idea already. I think there's a good argument that S3 with the DCON freeze is very different from the classic notion of suspend, and so warrants its own designation. More importantly, though, I don't think cpuidle is limited to ACPI states. I think you can plug in any state you like, if you have code to enter and leave it. --Ben signature.asc Description: OpenPGP digital signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Techteam] XO-1.5 Kernel Update (i.e My Weekly Status)
Benjamin M. Schwartz wrote: Audio playback and recording don't use userspace timers, but they do generate a lot of interrupts. If cpuidle does something even marginally sane with interrupt history, it should not go into a high-latency sleep state during sound playback or recording. If it does, audio will skip, but the CPU will be woken up by every interrupt delivered from the sound card. (It occurs to me that this probably should've happened for the XO-1 too, but it didn't. Maybe the EC is not handling those interrupts properly?) On second thought, the Geode's audio codec was probably powered off along with the CPU. I imagine there's a way to use the kernel's Power Management QoS to prevent this from happening, but I don't know the details. --Ben signature.asc Description: OpenPGP digital signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Techteam] XO-1.5 Kernel Update (i.e My Weekly Status)
John Watlington wrote: We have often discussed the need for an audio DCON. It wouldn't take much -- the amount of memory required for a second of playback/record could be included in the codec. wad My impression is that the codec does DMA to memory for recording and playback. If DMA works during CPU suspend, then it seems like playback should just work. In fact, if the buffer's big enough, the interrupts issued by the codec should be able to wake the CPU up in time to refill/empty the buffer without a glitch. The power domain charts for XO-1 and XO-1.5 don't quite tell me whether the codec, amplifiers, northbridge, and southbridge are enough powered in suspend for this to work. I imagine not, though, so audio playback will probably have to inhibit suspend in XO-1.5. I do not think this will be difficult to implement in software. --Ben signature.asc Description: OpenPGP digital signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Techteam] XO-1.5 Kernel Update (i.e My Weekly Status)
Paul Fox wrote: perhaps this should be obvious, but can it handle S-states as well? because i believe that's the goal -- freeze the display and then go into S3. I just stumbled across the Design Scenarios for Linux's Power Management Quality of Service system, courtesy of Intel. [1] Notable inclusion: # Platform Suspend * you can put the system into S3 or S4, as a function of acceptable wake up latency * you can specify the delay in dropping into a suspend state as an idle time out I don't know exactly what this means, if anything, but it sounds good. [1] http://www.lesswatts.org/projects/power-qos/design-scenarios.php signature.asc Description: OpenPGP digital signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: A1 Motherboard specs diagram
Carlos Nazareno wrote: Does that mean hardware acceleration of audio codec playback? No. From http://en.wikipedia.org/wiki/Audio_codec In hardware, the term audio codec refers to a single device that encodes analog audio as digital signals and vice versa. This is used in sound cards that support both audio in and out, for instance. Will there be software support for this? Also, according to the diagram, the A1 uses a Via VX855 media system processor: http://www.via.com.tw/en/products/chipsets/v-series/vx855/ This chip has a built in Via Chrome9 (formerly S3 graphics brand) 3D accelerator. Does this mean we'll now have pretty good OpenGL hardware acceleration on the XO? :) -- Compiz Fusion for Fedora or Ubuntu on the XO! ;) There are no free 3D drivers. I have heard nothing to indicate that there are likely to be soon. I would be surprised if OLPC were to ship the proprietary drivers, though I cannot speak for them. Also, the Via page mentions hardware decoding of certain video codecs. Will we see software support for any of these? (given that these are proprietary video codecs) The authors of these codecs claim they are heavily patented. In the past, OLPC has refused to ship such codecs due to the patent issues. I have heard no indication that their position is likely to change. This has a power consumption of 3.5W which is significantly higher than the AMD 0.8-1.3W of the XO-1's AMD Geode LX 700. This is why I was asking about battery life -- it's a concern for using the XO with common tasks like as a mobile e-book reader. The CPU should not be running if you are using the XO as an ebook reader. Fast suspend and resume is an integral part of the hardware design, unlike any other x86 machine. It seems likely that battery life will suffer relative to an XO-1 if suspend/resume is disabled, which is why suspend/resume should not be disabled. --Ben signature.asc Description: OpenPGP digital signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Performance hit while working with screen depth 16
shivaprasad javali wrote: My original question still remains unanswered. Is it acceptable for my activity to change the screen depth to increase its performance? Acceptable to whom? It's probably not acceptable to the hundreds of thousands of children who currently have XOs running Sugar, because the Rainbow system will prevent your activity from editing xorg.conf. In fact, because the users in Uruguay have been denied root access, they cannot change the screen depth at all. On the other hand, if this is for private deployment under your control, then it's perfectly acceptable. --Ben signature.asc Description: OpenPGP digital signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] poor man's mmap sliding window on Python 2.5.x
Martin Langhoff wrote: Along the way, found that Python 2.5.x doesn't support an offset to mmap(), which at first blush makes re-mapping with a sliding window problematic. Why is an explicit sliding window necessary? Isn't the point of mmap that you can access as you like, and the kernel will clear old caches if there's memory pressure? On the XO-1, it's the difference of churning through it and slowing the whole OS to a crawl, and then inching towards a big OOM zap. Is this (a) a kernel bug, (b) Python layering extra caching over mmap, or (c) a misunderstanding of mmap on my part? --Ben signature.asc Description: OpenPGP digital signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] poor man's mmap sliding window on Python 2.5.x
Martin Langhoff wrote: On Tue, Jul 7, 2009 at 2:06 AM, Benjamin M. Schwartzbmsch...@fas.harvard.edu wrote: Is this (a) a kernel bug, (b) Python layering extra caching over mmap, or (c) a misunderstanding of mmap on my part? money is b huh. I looked through python's mmap implementation [1] and there doesn't seem to be any caching or funny business going on. I wonder if it could be over-aggressive caching somewhere in jffs2, in an attempt to avoid repeatedly decompressing the same block. --Ben [1] http://svn.python.org/projects/python/trunk/Modules/mmapmodule.c P.S. JFFS2 appears to support read-only mmap, which I presume is what you're using. signature.asc Description: OpenPGP digital signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: The XO-1.5 software plan.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chris Ball wrote: We have some good news: OLPC has decided to base its software release for the new XO-1.5 laptop on Fedora 11. Unlike previous releases, we plan to use a full Fedora desktop build, booting into Sugar but giving users the option to switch into a standard GNOME install instead. (This will mostly be useful for older kids in high school.) I'm particularly happy about this plan because it will allow us to catch up with the awesome work present in the Sugar community's most recent release, Sugar 0.84, as well as merging the latest Fedora work and including GNOME into the mix for the first time. The new machines will have 1GB of RAM and 4GB of flash, so we have enough room for both environments at once. This raises an interesting question: should we still be using a compressed filesystem? On the XO-1, an uncompressed FS was essentially not an option. There would be almost no space left for users' files after the uncompressed system files. Unfortunately, this causes tremendous slowdowns all over the system, as it causes reads from flash to (a) be CPU-limited, and (b) compete with the rest of the system for CPU time. Writes are even worse. On the 1.5, we will have more space (so less need for compression), but more system files, and also more CPU to handle it. I think we should remember to test the final images both with and without compression. Of course, this equation gets still more complicated depending on whether we have MTD or FTL flash. Choosing a filesystem will be an interesting exercise. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) iEYEARECAAYFAkoO7LkACgkQUJT6e6HFtqTH/QCfYUitcwLq8bTF2E1g+rbwyfa8 t1sAoIcQ0FXXm16GlFriJ1A2n+Bv4Fe1 =v9fu -END PGP SIGNATURE- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Live from SugarCamp
Rodrigo Padula de Oliveira wrote: Hello my friends. How can I define groups in Sugar to share things? Can I share an activity only for a specified group of XOs ? Groups are a planned feature, but they have not yet been implemented. What is currently implemented is an invitations system. You can launch an activity, then move to the Neighborhood (or Friends) view, select a buddy, and choose Invite [buddy name] to [activity name]. In this way, the activity will only be shared with the people you invite (and the people they invite, etc.). Unfortunately, invitations have not been very reliable. If they do not work for you, I would like to hear about this. Additionally, Martin Langhoff has been working on creating a kind of group structure using Moodle. In his system, users can be formed into groups using the Moodle web interface, and then users will only see other users in their group in the Neighborhood view. I do not know the status of this work. --Ben signature.asc Description: OpenPGP digital signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Removing the 'Erase' options from activity righ click menu
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 nout...@paiwastoon.com.af wrote: After our first deployment here in Afghanistan, we had to reinstall a lot of laptops because students accidentally deleted most of their activities. I think this is a great example of why we need to make a no-regressions XO-1 build with 0.84. Among its many new features, 0.84 adds direct file transfer capability, which means that if you delete an activity, you can easily have a friend send it to you over the network. It is abundantly clear that OLPC is not going to do this work for us. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) iEYEARECAAYFAkn+blsACgkQUJT6e6HFtqRWDQCfQP3J5gyNA8KXg3ea2wTb0Ll9 4sQAniO2WPqjD6s3UpyB23h/g0RyHQZQ =1OXc -END PGP SIGNATURE- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: CL1B power distribution
John Watlington wrote: the LED trick has the advantage of not requiring a change to the case, just a single additional drive pin to be able to run it as a detector. And where would you place said detector LED, without modifying the case ? While we're bikeshedding this to death, I'll put in my vote for reusing the camera activity LED. It's well isolated from other light sources, and it's rarely on. Whenever the camera is off, it can be used a photodetector. To retain the security guarantee that the light is on when the camera is on, it might be necessary to put a diode across the camera's power supply, so that they can be reverse-biased together. If only we could get another hole in the case. --Ben signature.asc Description: OpenPGP digital signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Fwd: Gnash loves the Via C7
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Rob Savoye wrote: Benjamin M. Schwartz wrote: The XO-1 has hardware-accelerated XVideo, including YUV-RGB and scaling. Are you talking about hardware acceleration for the internal stages of video decoding, a la XvMC? Tests on a 1.0 GHz C7-M (the processor in XO-1.5) indicate that software-only rendering should be fast enough to play DVD-resolution video and audio. Sorry, I wasn't quite clear, it's the existing XO hardware that has problems with streaming video when done entirely via software. A 1.0Ghz C7 is fast enough for software rendering of streaming video, but 400Mhz seems to be a threshold for software rendering of networked video. Both the C7 settop/NetBook I have here have Unichrome support (OpenGL), which helps for YouTube. OK... but entirely via software is Doing It Wrong. With XVideo accel, the XO-1 is perfectly capable of playing back YouTube videos at full speed. Observed performance is only awful because Gnash isn't using XVideo, so YUV-RGB and scaling are being done in software. If we built a special-purpose YouTube plugin using gstreamer (with the patent-problem decoder elements...) we would have full-speed video instantly. For more evidence try olpc.dailymotion.com. Those videos are Vorbis+Theora at YouTube resolutions... and they decode beautifully on the XO-1, because they're sent through the correct pipeline. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.10 (GNU/Linux) iEYEARECAAYFAkn1154ACgkQUJT6e6HFtqT4mACgkuWrEv1En3CPXIj8slqb8SGy IXUAn2u/+XaVLvI6PbAaXdomCrlQxJo2 =EII8 -END PGP SIGNATURE- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Fwd: Gnash loves the Via C7
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Rob Savoye wrote: As of the 0.8.5 release, Gnash supports both XVideo an the MIT-SHM extension for better performance. It's just that these newer builds never seem to get built for the XO, although I drop binary snapshots as rpms on our http://www.getgnash.org site occasionally. To enable XVideo support of newer Gnash builds, just add set XVideo true in your $HOME/.gnashrc file. We added both of these over the winter because of the benefit to XO class hardware. It's not enabled by default as it's a new feature. 1. Does Gnash use XVideo for YUV-RGB, or only for scaling? 2. Has the problem of mouse interaction with Gnash-XVideo been resolved? This would be extremely helpful for Tomeu's Gnash Activity work. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.10 (GNU/Linux) iEYEARECAAYFAkn13QAACgkQUJT6e6HFtqQuWACeMIN9vIo0HWoR5ML9F5UI05/8 2cgAn0Etnqksk3PMqxgxrxO7/ci+fyNb =CuAm -END PGP SIGNATURE- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Fwd: Gnash loves the Via C7
Rob Savoye wrote: What would be truly awesome would be OpenGLES support on the XO 1.5. :-) Software rendering kills streaming video performance... I don't understand. Could you elaborate? The XO-1 has hardware-accelerated XVideo, including YUV-RGB and scaling. Are you talking about hardware acceleration for the internal stages of video decoding, a la XvMC? Tests on a 1.0 GHz C7-M (the processor in XO-1.5) indicate that software-only rendering should be fast enough to play DVD-resolution video and audio. --Ben signature.asc Description: OpenPGP digital signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: CL1B power distribution
Richard A. Smith wrote: Ideally updates could be frequent enough to pick up a waveform from an unrectified power supply. (spare audio channel?) Don't have much in the way of EC cycles available. Don't have much EC ram left to cache values either. I can make the readings available via EC commands but each command takes a few ms to complete and back to back commands will have a few ms of delay as well. I'm guessing you might be able to get a 20ms update rate. That's not fast enough for much interesting signal processing, but it's more than fast enough to do power metering. Power metering while on external power is something I've specifically been hoping for. (So please consider adding this to the end of your very long EC TODO.) --Ben signature.asc Description: OpenPGP digital signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: CL1B power distribution
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 John Watlington wrote: Quick straw poll on how many people think it is useful enough have individual control over the power supplied to each connector to raise the cost of the laptop by $0.15 ? Turning off a single port to which nothing is connected saves no power, right? I don't see the appeal. Maybe for deactivating power to passive devices (e.g. usb sticks) during suspend, but such devices are cheap to power anyway, and may not shut down cleanly if their power supply is killed. Moreover, I am persuaded by your argument that the software is unlikely to get smart enough to use it. Also, these switches are actually transistors, with some leakage current and some effective resistance, right? So it seems like we pay for the flexibility of these switches with a small increase in power requirements. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.10 (GNU/Linux) iEYEARECAAYFAknz5a4ACgkQUJT6e6HFtqRgTgCdHb+0t19AEY2VaHOaVYVqC6Fs Tr0AmwVwMtgWTTgzEPys2DpPlksdTv32 =pcyb -END PGP SIGNATURE- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Notes on service discovery XS/XO
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin Langhoff wrote: The short of it is that mdns/dns-sd make sense for a small, underutilised network of peers. They assume that the network is a cheap resource, that broadcast messages are cheap, and that there is no coordinating server. mDNS assumes all of the above things. DNS-SD does not. DNS-SD is perfectly happy to work on a standard DNS server. From the spec This document proposes no change to the structure of DNS messages, and no new operation codes, response codes, resource record types, or any other new DNS protocol values. This document simply specifies a convention for how existing resource record types can be named and structured to facilitate service discovery. (http://files.dns-sd.org/draft-cheshire-dnsext-dns-sd.txt) I'm not particularly knowledgeable about the XS service discovery requirements, nor about DNS, so I can't reasonably tell you to use DNS-SD. What I can say is that it seems like it should be workable. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.10 (GNU/Linux) iEYEARECAAYFAknsW+UACgkQUJT6e6HFtqSx5QCglzpN+96F9aTAH05KnsQszg3E vy4An0lCtq/z04OKiFVvv5TvXUcNnkZ5 =TRBq -END PGP SIGNATURE- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO Gen 1.5
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 John Watlington wrote: The enabling chipset is hot off the fab line, the VX855 [2]. This single chip provides ... a 3D graphics engine, an HD video decoder It's worth remembering that the only existing driver that supports either of these features is a pure binary blob. The Openchrome drivers have no 3D support, never mind video decode support. Even their Xv support is glitchy. In other words, this GPU represents a regression, compared to the Geode LX, unless you're willing to run with (famously unreliable, unsupported) binary-only drivers. So don't get too excited. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.10 (GNU/Linux) iEYEARECAAYFAkns6IoACgkQUJT6e6HFtqSCTQCfacYu5ZvaF1mqPga0vwiNvvUZ u5YAnRNSmM+0FtuaRL2TTCGhjU/Pk4ly =5D6T -END PGP SIGNATURE- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Server-devel] Notes on service discovery XS/XO
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin Langhoff wrote: The short of it is that mdns/dns-sd make sense for a small, underutilised network of peers. They assume that the network is a cheap resource, that broadcast messages are cheap, and that there is no coordinating server. mDNS assumes all of the above things. DNS-SD does not. DNS-SD is perfectly happy to work on a standard DNS server. From the spec This document proposes no change to the structure of DNS messages, and no new operation codes, response codes, resource record types, or any other new DNS protocol values. This document simply specifies a convention for how existing resource record types can be named and structured to facilitate service discovery. (http://files.dns-sd.org/draft-cheshire-dnsext-dns-sd.txt) I'm not particularly knowledgeable about the XS service discovery requirements, nor about DNS, so I can't reasonably tell you to use DNS-SD. What I can say is that it seems like it should be workable. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.10 (GNU/Linux) iEYEARECAAYFAknsW+UACgkQUJT6e6HFtqSx5QCglzpN+96F9aTAH05KnsQszg3E vy4An0lCtq/z04OKiFVvv5TvXUcNnkZ5 =TRBq -END PGP SIGNATURE- ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: [BULK] Re: GPS on XO
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hal Murray wrote:
p...@laptop.org said:
i guess i'd be a lot more worried if the volume name (or whatever it
is that's being used as the device name) could contain a slash ('/')
character. because that would no doubt render the device unmountable.
someone should try that...
It's the same problem. Whatever works for spaces should work for slash too.
That may be an argument for using backslash in front of funny characters
rather than quotes around the string.
In fact, this is not true. In POSIX filenames (and directory names) /
is the only character that is explicitly disallowed. In contrast, is
a perfectly valid character in a filename.
- --Ben
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.10 (GNU/Linux)
iEYEARECAAYFAknawx4ACgkQUJT6e6HFtqR/1gCeON/fhmhS3DGB2BF1gzknQNdi
9p0An34tICd2TXoqQ0LcfhwF2ePDeRVe
=e1J1
-END PGP SIGNATURE-
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: Google summer of Code?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jameson Quinn wrote: Honestly, this is news to me. (and I am the co-administrator of the Sugarlabs program). If I had to articulate my view of our priorities, it would be something like the following: 7-10 points: Key sugar core improvements. Long-standing, important gaps like versioning or unit-tests at the high end of this. As others have pointed out many times, the SoC projects that are least likely to produce useful results are the ones that are the most ambitious. In particular, it is difficult to find SoC applicants who are ready to make deep modifications to an existing codebase, or will be able to architect complex software. Remember, SoC applicants are mostly current undergrads, so most have never participated in multi-person development effort, or written anything larger than 1000 lines. 0-8 points: Proposal quality. Maybe this problem is wrapped up in Proposal quality. If I were designing a system to reflect my own internal judgment structure, I would probably add another /multiplying/ factor, the estimated probability of success (although I hope we can do selection without resorting to numerical scores.) - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkm6XnQACgkQUJT6e6HFtqSlrACgjuswY+/aYXWkfaTY3DZcls/l gLcAnRP4Rn7tGfuQoiipzFtXQfEHP1g4 =Z92W -END PGP SIGNATURE- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Collaboration test environment problem
James Simmons wrote: I have two PCs running Fedora 10 and the Sugar RPMs that come with that. One of the computers runs GNOME and the other uses Window Maker. I run sugar-emulate on both. One copy of Sugar uses the name jim and the other uses jsimmons. Both use the schoolserver.media.mit.edu jabber server. Both are connected to the same router using Ethernet cables. When I go to the neighborhood view (F1) on both I see a number of buddies. However, while on the jim machine (Window Maker) I can see and invite jsimmons. When I look at the same view on jsimmons (GNOME) I cannot see user jim, although I can see other users. Do they see the same other users? schoolserver.media.mit.edu is using the shared roster, so every user should be able to see every other user. If the asymmetric visibility that you describe persists for more than 10 minutes, then you have found an extremely bizarre bug. --Ben ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: rotate button sucks on the XO
Jordan Crouse wrote: NoiseEHC wrote: 2. An Xvideo RGB overlay displays the big nothing (black) while the screen is rotated. Indeed - XV is purposely turned off when the screen is rotated (or at least, not displayed): The LX hardware supports rotated blits, right? So in principle, rotated XV could be added to the driver if someone cared sufficiently...? Tangentially related: Anyone who uses gstreamer for video is likely using xvimagesink to display video, but IMHO this is almost always a bad idea. If another application is already using XV, your gstreamer pipeline will simply fail. Instead, use autovideosink, which attempts to use xvimagesink, and silently falls back to ximagesink if XV is not available. --Ben --Ben ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: getting mp3 sound working w/ Gnash easily
S Page wrote: However, FWIW I just purchased the Fluendo MP3 decoder for $0 and installation on 8.2 on my XO was pretty straightforward if you're moderately familiar with the command line. Now I can play .mp3 files in Browse and Totem and _some_ Flash animations have sound in Gnash (http://dev.laptop.org/ticket/8504) If anyone gets a FOSS MP3 codec installed and working, the place to document it is http://wiki.laptop.org/go/GStreamer#MP3 . The Fluendo MP3 decoder _is_ FOSS, or at least it is as nearly Free as any implementation of MP3 can be, given the patent problem. The source-code is MIT licensed. Additionally, downloading the binary conveys a patent license upon you, and upon anyone else to whom you distribute the binary. However, the binary itself is not quite Free. For example, you cannot distribute the binary codec linked into a GPL binary, because the patent protections do not extend to derived works or modified forms. Anyway, source tarball at http://core.fluendo.com/gstreamer/src/gst-fluendo-mp3/ --Ben signature.asc Description: OpenPGP digital signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: OS/X11 support for XO-1 hardware?
da...@lang.hm wrote: It would allow for much improved video performance since you could play back a 320x240 video on the full screen at considerable CPU savings. except that you would spend those CPU savings doing the scaling up from 320x240 to the higher resolution. Argh and double argh! You're both wrong. 1. Video playback in any sane player is already routed through XV, which uses the GPU's video overlay scaler (and YUV-RGB converter). The result is that playing a 320x240 video at 1200x900 full-screen already costs zero extra CPU cycles. No need to mess with screen resolution. 2. The Geode LX GPU can do both output scaling and video-overlay scaling, independently, at the same time. On the latest drivers, we should be able to set the screen resolution to 600x450, scaled up to 1200x900, and then play a 320x240 video, scaled up to 480x360 (which means 960x720 physical LCD pixels), all without using any CPU power for scaling. There are lots of good reasons to play with screen resolution. My favorite reason is that reducing the resolution to 800x600 would make all graphical operations runs twice as fast, and use half as much memory, while introducing a negligible drop in display quality (the display, remember, is not _really_ 1200x900 in color mode; the total number of color elements is equivalent to 800x450). --Ben signature.asc Description: OpenPGP digital signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
Wade Brainerd wrote: To me, Bitfrost was just one more lofty windmill OLPC tried to tilt because it seemed like an interesting challenge. I'm not clear why Sugar needs more protection from rogue activities than a normal desktop environment has from rogue applications. Reinventing the desktop as a constructivist learning environment is a big enough task for one development team / community to swallow. Reinventing security is an altogether separate cause. They are a single, indivisible cause, and also the entire reason for the existence of Sugar. Many operating systems provide users with a set of powerful tools for manipulating ideas and data. Sugar's purpose is to add another dimension: to encourage users to modify and share the tools themselves. To that end, if my friend sends me a modified copy of an activity, I must be able to run it without fear of wrecking my system. Users naturally want to do this. To see what happens when the operating system doesn't support it, just look at the wave upon wave of e-mail viruses that plagued Windows for so many years. Without support for safe collaborative development of this sort, Sugar has little to recommend it over XFCE and similar gtk-based iconic user interfaces. We are getting there, and with the latest improvements to view-source and Rainbow, we are beginning to have the basics in place. --Ben signature.asc Description: OpenPGP digital signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
Martin Langhoff wrote: Maybe my ignorance on matters selinux is showing? ;-) You are not alone. Sugar/OLPC simply never had SELinux experts who volunteered to work on Rainbow. We still don't (raise your hand if you consider yourself proficient at writing SELinux policy!). It's hard to write a sandboxer like Rainbow, since it must not only appear to work, but be verified secure to a high degree of confidence. That's harder still if one is writing in a system in which one is a novice, so the developers (principally Michael) have instead stuck to technologies with which they are already expert. --Ben P.S. The SELinux entry on Wikipedia contains the following gem: Isolation of processes can also be accomplished by mechanisms like virtualization; the OLPC project, for example, sandboxes individual applications in lightweight Vservers. signature.asc Description: OpenPGP digital signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: On optimizing Theora
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tiago Marques wrote: Can you please try both options with also the following ones:*-ftree-vectorize -funroll-loops -m3dnow (1) libtheora automatically adds the flags -O3 -fforce-addr - -fomit-frame-pointer -finline-functions -funroll-loops to any specified CFLAGS. (2) libtheora's inner loops are largely hand-optimized MMX assembly, so vectorization and 3dnow are unlikely to have a significant impact. (3) I am not particularly interested in trolling through every combination of relevant gcc flags in search of performance benefit. That's the compiler's (and compiler writers') job. My point, instead, was that gcc (at least the version in 767) does not have a good code generator for Geode, and therefore we should not expect any performance increase by rebuilding everything -march=geode. If you are interested in searching for the perfect compiler flags, perhaps you would like to try Acovea (http://www.coyotegulch.com/products/acovea/). - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmhp7AACgkQUJT6e6HFtqRt4wCgl4CpYwb3OqlxUfwkgVvuMsk6 UcYAoJ54o4Oyhgl056lF6HQbbtf245O2 =dFCy -END PGP SIGNATURE- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: On optimizing Theora
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tomeu Vizoso wrote: On Fri, Feb 20, 2009 at 06:41, qu...@laptop.org wrote: On Fri, Feb 20, 2009 at 12:28:42AM -0500, Benjamin M. Schwartz wrote: GCC 4.3 evidently does not do a very good job of optimizing for geode. What percentage of CPU time was spent in libtheora? 100%. The encoder was operating in a continuous loop. Yeah, both X and jffs2 seem to use a lot of cpu on the XO, so if they were involved during your tests, you may have seen little of theora itself. Neither X nor jffs2 was involved. The input file (y4m or ogv) was cached in memory, and the output stream (ogv or y4m) was being sent directly to /dev/null, and not displayed. The only action being taken in X was to display, in the Terminal activity, a text-only progress bar, rendered by the encoder_example, or dump_video command. These commands are part of libtheora, and were recompiled with it, so the point remains. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmevNoACgkQUJT6e6HFtqR6tACeO1ZzMrBs/u1RZiGLqS19AJEv RD4An26lFRgJ1sRxktsSlG18WjVQ92d7 =eIOq -END PGP SIGNATURE- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
On optimizing Theora
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I have been testing libtheora-1.0 on a MP XO. On build 767, using F9's gcc-4.3, I compiled libtheora with CFLAGS=-march=geode. I tested encode, with the command time encoder_example -v 1 coastguard_cif.y4m /dev/null using the test video from http://media.xiph.org/video/derf/y4m/coastguard_qcif.y4m. This test ran in 44.15 +/- 0.15 seconds (all times are user time). I then tested decode, with the command time dump_video coastguard_cif1.ogv /dev/null using the ogg video that would be produced by the encoder above were it not redirected to /dev/null. This test ran in 4.60 +/- 0.05 seconds. I then repeated these tests after recompiling with -march=i586 - -mtune=generic, which I assume are approximately the CFLAGS used by Fedora. The resultant times were 41.6 +/- 0.1 and 4.45 +/- 0.05. In conclusion, compiling libtheora with -march=geode causes it to run significantly (20 sigma, 7%) slower than -march=i586 -mtune=generic for encoding, and possibly slightly slower for decoding as well. GCC 4.3 evidently does not do a very good job of optimizing for geode. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmeP4oACgkQUJT6e6HFtqQw8wCdEhQQi0qzQNjn++HQU1uQRMXG +aIAnA/LStzVA7pSZGMRFIWXUbeQv3oc =wp55 -END PGP SIGNATURE- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Unshare an Activity
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jorge Saldivar wrote: Thanks Bert! But, even if you initiated the sharing, you can leave the shared activity. After an activity has been shared, all participants are equal. I know that I you join a shared activity you can leave it, calling the leave method but what happend if i share the activity???, how can I unshare it??, or close the connection??, or some thing link that??. This is the problem with your understanding. A shared activity is _initiated_ by one user, but this user does not _own_ the shared activity. The user who initially shared the activity can turn off his computer, and the other users can still continue to share with each other. You can see this with the Chat activity, for example. Sharing can only continue without the initiator if the sharing code for a specific activity supports it. If you are writing an activity, you must figure out how to handle the case where the initiator leaves. If you cannot support continued sharing after that point, then you may wish to notify the user that the instance is no longer shared. However, it is better to design your networking code so that sharing can continue. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmZ3rYACgkQUJT6e6HFtqTrxQCfRyxdcBovZMnozHecOu32jIph 28IAn0L6e3332NVba4oFJgg4/vHHdzl1 =mt9d -END PGP SIGNATURE- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Unshare an Activity
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hal Murray wrote: This is the problem with your understanding. A shared activity is _initiated_ by one user, but this user does not _own_ the shared activity. The user who initially shared the activity can turn off his computer, and the other users can still continue to share with each other. You can see this with the Chat activity, for example. I'm missing a key idea. Some activities have persistent data, say a document. Another example would be the high score database for a game. I'm not sure what you mean by persistent, but I believe I understand your overall point. Many activity implementations work internally by designating one of the participants as a super-node or server, and then using that machine as a central point for maintaining canonical copies of data and synchronizing communications. A good example of a current Activity written in this way is Write, in which the main copy of the document is kept on the server, which is also the machine on which the instance was initiated. In the current Sugar design, an Activity like Write that behaves in this way is considered broken. That is, the Sugar UI presents an abstraction in which all nodes of an Activity are equal, and in principle sharing continues regardless of who leaves. This is deliberate, because that's the desired behavior. Sugar was designed with an eye toward sharing on a mesh network, where all network links are unreliable, and sharing must degrade minimally in the face of connection failures. In the case of Write, the authors are attempting to reach this point by writing code to elect a new super-node if the current one leaves the shared session. I believe that code has not yet been released. The last time I checked, if the initiator of a Write session left the shared session, the remaining users would still be nominally sharing according to Sugar, but no data would actually be transferred between them. It's possible that Sugar should grow some UI to indicate if a single group member is a keystone, and sharing will break if the connection to that user drops. That is, however, a fairly ugly thing to try to communicate to a user, and given a choice we would rather make it unnecessary. Personally, I've been working on writing a communications library called Groupthink that ensures that all state is correctly replicated across all activity instances. Any Activity that can be written using Groupthink will automatically be immune to the loss of any single member. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmaQuoACgkQUJT6e6HFtqTcjQCePlhnRJiX7uI7eeQPZTG7Ih5w 0BUAn0+f1YQNHI0yQ/PBDTPb2TX+dgjp =Lk5L -END PGP SIGNATURE- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: power consumption after shutdown
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mikus Grinbergs wrote: I take this to mean that *something* was draining some power for the two days the XO was sitting in its shut down state. All rechargeable batteries lose stored energy over time. The phenomenon is called self-discharge. It is sometimes modeled as a large (but not infinite) resistance in parallel with the battery. Just be glad the batteries aren't Li-Ion. Those can self-discharge totally in a month or less. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmWRtUACgkQUJT6e6HFtqRK1QCgnMJ2bhK9AXQ3/NAvlXMINRsB aMEAn1hr7kDpxwy6LoA+UYd4EXXUyP0T =hc5N -END PGP SIGNATURE- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Guidance sought on collaboration techniques
James Simmons wrote: When I wrote collaboration into the View Slides activity I just copied the code from the base Read activity so I could copy an entire slideshow from one machine to another. That didn't work all that well No? It would be good to know why. Also, Telepathy now has a high-level File Transfer API. If you can afford to depend on the development builds of Sugar (soon to be released as 0.84), then this might make your life much easier regardless of which solution you choose. , so now I'm considering something that I think is both more practical and a better use of collaboration. The idea is to have buddies that join a slideshow passively view a show being navigated by the master user, sort of like looking over someone's shoulder when he reads. As has been noted elsewhere, this might one day be available to all Activities, by having Sugar provide a view-only VNC server. That isn't tremendously difficult (VNC over Telepathy has already been demonstrated) but no one's stepped up to implement it. In fact, implementing this might be easier than writing your own image-sharing system. What I have in mind is this: ... It occurred to me that the Chat activity must be doing something kind of like this, but I haven't been able to figure out the code in that Activity. Remember that Telepathy is providing an abstraction layer over Jabber. Chat is simply using Jabber's basic IM functionality. I doubt you'll be able to use Chat as a model for sharing images. --Ben signature.asc Description: OpenPGP digital signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Treatise on Formatting FLASH Storage Devices
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 da...@lang.hm wrote: On Wed, 4 Feb 2009, Mitch Bradley wrote: http://wiki.laptop.org/go/How_to_Damage_a_FLASH_Storage_Device Read it and weep. this completely ignores wear leveling, which is very nessasary for just about any filesystem, but especially for FAT (which appear to be the only filesystems this author is familiar with) Umm, what? To alleviate the wear out problems, the FTL must move data around so that repeated writes to a given sector don't cause too many writes to the same NAND page. Mitch is describing FLASH devices like SD cards. All such devices have a built-in microcontroller (the FTL) that performs wear-leveling. Layering additional wear-leveling filesystems like JFFS2 or UBIFS on top of the FTL requires a reverse translation (block device-MTD) and is not recommended. e.g. From http://www.linux-mtd.infradead.org/doc/ubifs.html : UBIFS was designed to work on top of raw flash, which has nothing to do with block devices. This is why UBIFS does not work on MMC cards and the like - they look like block devices to the outside world because they implement FTL (Flash Translation Layer) support in hardware, which simply speaking emulates a block device As for the author only being familiar with FAT, that is hilarious. Mitch implemented JFFS2 support in OFW, and wrote this page to explain how he produced optimal ext2 formatting of FTL FLASH. Indeed, that is the subject of http://wiki.laptop.org/go/How_to_Damage_a_FLASH_Storage_Device#Screwed-Up_Formatting - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmJq7wACgkQUJT6e6HFtqT4sACdH/YR07Eq+l+i2M53HuWlZbF3 6bYAn3Aw3X7+k+cThHg9elaI/Jjiokp/ =6lfi -END PGP SIGNATURE- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Treatise on Formatting FLASH Storage Devices
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mitch Bradley wrote: It has been my experience that USB sticks and SD cards with intact factory formatting tend to last longer and run faster than ones that have been reformatted with random layouts. This gives us Linux users a bit of a dilemma if we want to use FTL flash for primary storage. FAT does not provide the file access permissions, symlinks, hardlinks, or even case sensitivity, that we desire for most filesystems on unixy systems. However, FTL devices behave as a sort of FAT-oriented black box, full of secret proprietary firmware that loves FAT. One obvious proposal, therefore, would be to use FAT for storage, but wrap it with a layer that implements all our favorite POSIX stuff. This has been done before for Linux, in the guise of UMSDOS/UVFAT [1][2]. Although that work has fallen out of date, I suspect one could reimplement it quickly using new linux features such as FUSE. The question is: would such an approach be worthwhile? - --Ben [1] http://linux.voyager.hr/umsdos/ [2] http://en.wikipedia.org/wiki/UMSDOS -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmKBJ0ACgkQUJT6e6HFtqR8kwCfc9MlcbGv1yaSEog6lNJoqmey kE0AmwRxwXtORZSITzyDUW5gqu9xBpoq =Kxa1 -END PGP SIGNATURE- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: OLPC upgrades
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 da...@lang.hm wrote: the fact that KDE and GNOME (both desktops that are considered pigs on normal machines) make a XO laptop seem snappy by comparison to Sugar (as of December) means that there is a significant problem with Sugar. I'm not happy to simply take this as fact. It's either a measurement or an opinion. when people ask about how to fix things, the answers that keep coming back all appear to be python related. The whole system is in Python! Everything is going to be python-related! so it's not FUD to say that the dependance on Python is hurting performance. It's not FUD, but it's not exactly substantiated. We have some understanding of where we are spending our cycles, and it's not as simple as in the python interpreter. For example, measurements of activity startup time indicate that we're spending a lot of time in SVG rendering and Cairo. This isn't too surprising, since Sugar uses SVGs much more intensively than most desktop environments, and often renders many different versions of the same icon for the purposes of recolorization or animation. There are certainly many improvements we could make to perceived speed. Some, like fixing upstream modules (e.g. dbus-python) not to do any computation at import time, are python-related, though they have little to do with the language itself. Some, like switching to a better filesystem or testing LZO support in JFFS2, are entirely separate. Many, like rewriting the Journal GUI to minimize redrawing of widgets and enable smarter scrolling, are large projects. Blaming Python for our user-experience speed problems is not scientific, and it's not helpful. Have you found some critical piece of code that you can rewrite in C for speed? We'd love that. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmIyVUACgkQUJT6e6HFtqSgFgCfdmmKz5qoy7AdDw7XVq1lh0/t NmMAnij1vpH7oGOa/9h2z/fvrlP745gs =VpmM -END PGP SIGNATURE- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Aside: Neighborhood participants
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Morgan Collett wrote: Also don't blame avahi for the fact that we send out updates every time you alt-tab between shared activities, so that your icon can jump to the appropriate snowflake on everyone else's Neighborhood Views... I _strongly_ object to this behavior. Not only is this flooding the mesh with useless broadcasts, but it provides exactly the _wrong_ result in the UI. When I look at the Neighborhood view, I want to see who is participating in each shared instance. Instead, the view shows me who is in that particular window at this time. It's as if IRC clients only showed you as present in the room that is currently visible on your screen. We should remove this feature and instead show each person in the ring around each activity they have joined. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmHIr0ACgkQUJT6e6HFtqSr6QCfVIKVafX44TFETpmNao8mGevr ldUAoJ+q09kT87G/PzJDdT2ND3HzE0Fl =yxQR -END PGP SIGNATURE- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Is it possible to disable sharing for an Activity?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Eben Eliason wrote: I think that the addition of a new property in the activity.info file would be logical here. Make it an integer indicating the maximum number of supported participants. OK, but as an Activity author I might like to specify that cap at runtime, depending on many things, such as the size of the document. I might even want to let the initiator choose the number of participants. I think we should also have a runtime API, so that the cap that can be varied at any time. In fact, it might be nice to have a a generic solution for defining config variables that can be controlled either statically or at runtime. We have mentioned a wide variety of such variables, including things like whether screen rotation is supported. Scott (CC'd) has already come up with some really nice proposals for adding VNC as an alternate colaboration mechanism for all activities. In my mind, this would work perfectly with the above scheme, whereby any activity that already has max_participants in it could be viewed in that manner. I don't see why any Activity should be excluded from such VNC sharing, regardless of max_participants. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmHkNIACgkQUJT6e6HFtqQBlQCdF4AhUy+NWkwYqVR/qMyl/m2H UpAAniXtXxWRQuM8o8iqtiyJ0uB4o05Z =BI5d -END PGP SIGNATURE- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
