Re: [Olpc-france] extend the memory flash space with an SD card to build open80211s
You may want to check out the Debina pages in the Sugar Labs wiki, which tend to be kept reasonably up to date. http://sugarlabs.org/go/Community/Distributions/Debian -walter 2009/3/13 Aime Vareille aime.varei...@wanadoo.fr: p...@laptop.org a écrit : rekik wrote: Hi, I tried to build the kernel open80211s on a group of machines which use ubuntu 8.10 and it's work. Now I had to build it on an XO. The problem is that I don't have enough space on my flash memory ( 1Go ). So, I had to extend it with an SD card ( to have a space 1024 Mo), but I don't know the steps to make this solution and the minimum size of the SD card.. can anyone help me !!! it sounds like you're trying to do the build of open80211s on the XO itself. most people don't do development for the XO that way -- we build on another machine, and move the binaries onto the XO. for simple programs, you can build on most any modern linux distribution and your binary will work on the XO, because the libraries and environment tend to be compatible. (you could perhaps build a static binary to be sure.) the XO is based on fedora, so a fedora machine will be the best build host. Yes, but debian can also run on XO. However I found http://wiki.laptop.org/go/Ubuntu_On_OLPC_XO not good because it puts the fedora kernel on the ubuntu which works with some discrepencies ; it takes also some time because of qemu and the boot is not optimal. Today, the stuff with debian on XO is cleaner and very fast to install and test ; http://wiki.laptop.org/go/DebXO is the best page I found about it : # zcat debxo-$DESKTOP.ext3.img.gz /dev/sdX (for instance, sdb; not sdb1) And update the firmware to q2e34.rom at http://dev.laptop.org/pub/firmware/ Then it works fine either on SD card or USB pendrive of 2 GB minimum and you can still boot and use the native fedora XO build. With SD cards you could need some swap that can be made with a file /swap.bin as explained at http://www.olpcnews.com/forum/index.php?topic=4053.0 However, I have to compile a more recent kernel because the 2.6.25 version on that debian lenny is not sufficient for some of my experiments. With all the wiki documentation pages I don't know on which I should write. Regards Aimé paul =- paul fox, p...@laptop.org ___ Olpc-france mailing list olpc-fra...@lists.laptop.org http://lists.laptop.org/listinfo/olpc-france ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: announce: alternate power management
mikus wrote: configurable timeouts for screen dim and sleep. the dim level is configurable. My XO systems are plugged in to the AC, so I normally leave them running 24/7. But in the middle of the night if I happen to walk by, I notice if they are acting as light sources. Two concerns (for which I don't know whether doing anything is feasible): - Rawhide. AFAIK there currently is no dimming support at all. I either have to power off such an XO overnight, or have to close the lid while the backlight is still lit. It would be useful if rawhide supported dimming/shutting_off the screen when no one is looking at it (irrespective of whether the CPU is doing work or not). i'm sure rawhide will gain a power management solution of some sort. probably ohmd will be added. i wouldn't be surprised if olpc-kbdshim and olpc-powerd would work fine as well, but if you'd like to test that to confirm it, i wouldn't object. ;-) - Suspend. It was functioning well only with Joyride - but I hope it gets implemented other places as well. The problem is - the CPU may suspend because it is idle (and partly dim the screen), but the user may still continue looking at that screen (in color mode) while the XO is suspended. After a decent interval at half-bright, it is reasonable to assume the user has seen enough, and the screen could now be dimmed all the way off. BUT since the system is sleeping, the current implementation has no way to wake up the system just so it can execute 'screen dim' instructions. The result is that if I don't intervene at the keyboard, my suspended (Joyride) XO's screen remains half-bright throughout the night. I think it yes, clearly it would be good to have two (or maybe three) more stages available for idleness. we should be able to extend current behavior like this: dim (exists) sleep, screen on (exists) sleep, screen off (can't be done currently) shutdown (can't be done currently) or, alternatively, this sequence, which is more like a normal laptop behaves: dim screen off sleep, screen off shutdown (can't be done currently) i think all but the last step could be done currently. what's missing is a) a wakeup when closing the lid, and/or b) the ability for the system to set an alarm clock with which to wake up at some time in the future, in order to let it go back to (a deeper) sleep. i spoke with richard about the wakeup alarm recently -- implementing this requires changes to both the EC (embedded controller) and to the kernel. but maybe we can push something along. it's a feature which has been long-planned, but never finished. counter-productive to suspend the rest of the system (to save power!) when no one is using it, but to leave the screen lit (still drawing power!) once it can be presumed no one is using it any more. different power behavior when in ebook mode (though detection may be unreliable -- i think the ebook switch suffers from some issues we previously noticed with the lid switch). What issues ? I thought the lid switch could be fooled by people with magnets - but that an actual shut would always be recognized as being a shut (and a failure to recognize an open could be overcome by momentarily pressing the power button). the lid issues i was referring to are covered in #5703 and #7536. a) we get no wakeup when closing the lid, only opening. i believe this is a regression from some time ago, possibly a result of the fixes described in #5703, but also possibly a side-effect of #7536. (i haven't yet examined the actual code for either one to see what's going on.) this keeps us from noticing that the lid is being closed with the screen still on, and it stays like that. (#7536 was a change to keep us from waking on lid close when the screen was off -- in that case the wakeup was needless.) b) i've seen out-of-sync ebook switch behavior -- i.e., the event being reported (ebook open/close) exactly mismatches the physical condition of ebook mode. since this behavior was described for the lid switch in #5703 (and fixed), i'm guessing the ebook switch needs similar love. again, i haven't looked at the code yet. c) we still sometimes get empty sci as the wakeup source after a lid open. i (in powerd) currently treat empty sci the same as lid, but that might not fly if we were to fix a). paul =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: announce: alternate power management
i wrote: b) i've seen out-of-sync ebook switch behavior -- i.e., the event being reported (ebook open/close) exactly mismatches the physical condition of ebook mode. since this behavior was described for the lid switch in #5703 (and fixed), i'm guessing the ebook switch needs similar love. again, i haven't looked at the code yet. i've now looked at the code -- ebook mode tracking is completely separate from and different than lid state tracking. (sigh :-) it seems the condition i saw could be caused by an early failed read of the ebook state by the kernel, or a subsequent loss of one of the SCI events which indicates that the state changed. (this is a really good example of why just reporting something has changed, without reporting what it has changed _to_, is a bad idea from a robustness point of view.) paul =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: announce: alternate power management
On Sat, 2009-03-14 at 09:37 -0400, p...@laptop.org wrote: mikus wrote: - Rawhide. AFAIK there currently is no dimming support at all. I either have to power off such an XO overnight, or have to close the lid while the backlight is still lit. It would be useful if rawhide supported dimming/shutting_off the screen when no one is looking at it (irrespective of whether the CPU is doing work or not). i'm sure rawhide will gain a power management solution of some sort. probably ohmd will be added. i wouldn't be surprised if olpc-kbdshim and olpc-powerd would work fine as well, but if you'd like to test that to confirm it, i wouldn't object. ;-) Rawhide status: 1. Only by using an OLPC kernel (such as the one from staging release 801) is the kernel is capable of power management on the XO 2. with an OLPC kernel, ohmd does not work. Closing the lid, hitting the power button, these are not detected. I don't know why at the moment... 3. with the OLPC kernel and this olpc-kbdshim and olpc-powerd (which by the way are really realy nice, thanks a million pgf!) the XO suspends when via lid switch and the power button. 4. In a GNOME session, this behaves oddly, as gnome-power-manager also intercepts the power button press and pops up a hibernate/suspend/yadayada/ dialog, and then your XO suspends anyway :-) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: announce: alternate power management
scott wrote: On Sat, 2009-03-14 at 09:37 -0400, p...@laptop.org wrote: i'm sure rawhide will gain a power management solution of some sort. probably ohmd will be added. i wouldn't be surprised if olpc-kbdshim and olpc-powerd would work fine as well, but if you'd like to test that to confirm it, i wouldn't object. ;-) Rawhide status: thanks for testing! 1. Only by using an OLPC kernel (such as the one from staging release 801) is the kernel is capable of power management on the XO 2. with an OLPC kernel, ohmd does not work. Closing the lid, hitting the power button, these are not detected. I don't know why at the moment... odd. ohmd uses dbus for various things, but i would have assumed that would work. 3. with the OLPC kernel and this olpc-kbdshim and olpc-powerd (which by the way are really realy nice, thanks a million pgf!) the XO suspends when via lid switch and the power button. great! did you try the grab keys and rotation? (those are just olpc-kbdshim.) olpc-rotate should spin the display, even if the buttons don't work. 4. In a GNOME session, this behaves oddly, as gnome-power-manager also intercepts the power button press and pops up a hibernate/suspend/yadayada/ dialog, and then your XO suspends anyway :-) yeah, i kind of expected that. similar issues happen if you run ohmd alongside powerd as well. is g-p-m (easily) uninstallable? paul =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: announce: alternate power management
3. with the OLPC kernel and this olpc-kbdshim and olpc-powerd (which by the way are really realy nice, thanks a million pgf!) the XO suspends when via lid switch and the power button. great! did you try the grab keys and rotation? (those are just olpc-kbdshim.) olpc-rotate should spin the display, even if the buttons don't work. Pressing the rotation button does nothing in GNOME or Sugar. Should this be a general X rotation that should work in any X session? What are grab keys? I am not seeing any functionality for the gamepad keys. In the OLPC Fedora/Sugar these enable me to get around the scroll bar is not draw even though content is larger than frame fun. 4. In a GNOME session, this behaves oddly, as gnome-power-manager also intercepts the power button press and pops up a hibernate/suspend/yadayada/ dialog, and then your XO suspends anyway :-) yeah, i kind of expected that. similar issues happen if you run ohmd alongside powerd as well. is g-p-m (easily) uninstallable? Yes. Very easy to remove. One additional point related to power management, the control panel in the current Sugar RPMs (for rawhide/F11) doesn't have the power settings (extreme power management etc.) icon. Perhaps there is a gconf key to enable that? I asked in #sugar but got no reply. Or, is this functionality removed on purpose? ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: announce: alternate power management
scott wrote: 3. with the OLPC kernel and this olpc-kbdshim and olpc-powerd (which by the way are really realy nice, thanks a million pgf!) the XO suspends when via lid switch and the power button. great! did you try the grab keys and rotation? (those are just olpc-kbdshim.) olpc-rotate should spin the display, even if the buttons don't work. Pressing the rotation button does nothing in GNOME or Sugar. Should this be a general X rotation that should work in any X session? hmm. i wouldn't expect the button to work in gnome, but i'd expect the sugar bindings to continue working. the first check, though, it to see if the olpc-rotate command works from terminal. when olpc-kbdshim installs, it patches sugar to run that command rather than do its normal internal calls to xrandr. so if the command works, but the key doesn't, the debug path is pretty short, at least, i think. (is is possible that sugar installed after olpc-kbdshim? that would explain it.) What are grab keys? I am not seeing any functionality for the gamepad keys. In the OLPC Fedora/Sugar these enable me to get around the scroll bar is not draw even though content is larger than frame fun. the grab keys are the two with the little hands, at either side of the space bar. on an industry standard keyboard, they would be the bear the industry monopolist logo. :-) when you hold either down, a using the touchpad should cause whatever you're looking at to scroll. (if it's capable, of course -- i.e., wide or tall web pages, or terminal sessions with any amount of scrollback.) 4. In a GNOME session, this behaves oddly, as gnome-power-manager also intercepts the power button press and pops up a hibernate/suspend/yadayada/ dialog, and then your XO suspends anyway :-) yeah, i kind of expected that. similar issues happen if you run ohmd alongside powerd as well. is g-p-m (easily) uninstallable? Yes. Very easy to remove. One additional point related to power management, the control panel in the current Sugar RPMs (for rawhide/F11) doesn't have the power settings (extreme power management etc.) icon. Perhaps there is a gconf key to enable that? I asked in #sugar but got no reply. Or, is this functionality removed on purpose? don't know. i have several questions about how XO-specific hardware will be supported going forward. i assume the sugar folks would rather not continue carrying hardware specific key-bindings for rotation and brightness for instance, but i don't know what their current thoughts are. paul =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
