Re: idea for running out of RAM
On Sat, Nov 1, 2008 at 11:01 AM, Benjamin M. Schwartz [EMAIL PROTECTED] wrote: Albert Cahalan wrote: Memory reservations are a different beast entirely. Running out of memory becomes approximately impossible because the user is blocked from starting too many activities. This seems like a silly statement to me. Almost every activity on the XO is capable of exceeding the hardware memory limit all on its own. If so, then most are broken. Tux Paint doesn't suffer from this defect. The only semi-respectible excuse is that the activity accepts arbitrary input. The web browser is the obvious example. It's only semi-respectible because the activity can often have an internal limit (enforced in the easy code paths) for this, and because partial document rendering can prevent activities like Read from having this problem. If the activity can not be modified to limit itself, then it can't legitimately specify a reservation. Sugar can make these badly behaved activities run by themselves. Per-activity memory reservations are also per-activity limits, and they are only safe if those limits are set higher than the maximum amount of memory required by that activity, and that maximum value is simply far too large. The difference is that activities never get killed under a reservation system unless one is malicious or horribly buggy. Under a limit system, activities will die. It's unacceptable. I like the idea of memory reservations, and they were part of the original design, but if we set them high enough to be safe, we would have a single-tasking (and maybe zero-tasking!) operating system. No, although there are massive usability advantages for the elimination of being able to run multiple things at once. When a kid runs multiple activities, 100% of the time it was unintentional. The kid got confused, probably because the damn frame popped up under his mouse and stole a click. I should also be clear that I don't think Activities should receive the low-mem signal. I think Sugar should catch the low-mem signal, so that it can attempt to do something smarter than the OOM killer because it knows much more about the system. For example, it can choose to kill the activity instance that is using the most memory, or the least-recently-used activity instance, or even the instance that has most recently saved its state. Destroying the user's work by killing an activity: FAIL This works especially well if we also use the knobs on the OOM killer. For example, the low-mem signal, after pausing all other processes, could cause Sugar to (1) select an activity to kill, (2) set that activity's oomadj parameter to make sure that it will be the first one killed if we hit OOM (3) ask that instance to save its state to the datastore, (4) close the activity instance, and (5) pop up a notification to the user about what just happened. In a fit of rage, the kid throws his XO out the window. It just ate his work for the eleventy-seventh time today. Lots of things are wrong with that. You may kill an activity that could have survived; there is no good way to tell when OOM will be hit until you hit it. Setting oomadj doesn't prevent the laptop from getting so slow that the user decides to hard reboot. There is no reasonable way to ask an activity to save state. People don't write perfectly modeless code with atomic operations on a database. Since we can often determine an upper bound for the RAM usage of an activity, we can trivially determine if a given set of activities is capable of causing OOM. If we determine that starting a new activity would place the XO in danger of OOM, then there is no excuse for allowing that activity to start. The cgroups stuff could also help here, since the OOM killer by default thinks in terms of processes, but each Activity can be multiple processes. That would cause activities to die. Work is lost. FAIL ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: debxo 0.3 release
thanks for doing this. I never thought that putting KDE or Gnome on any system would seem like a speedup, but it definantly does. so now that the basic system is working, where do I get started to enable the less common features of the XO? specificly 1. controlling the backlight (and therefor the video mode between monocrome and color) 2. recognising the game keys and mapping them to keys/actions 3. switch out the audio filters on the mic input 4. accessing data from the stylis portions of the trackpad I also tried the lxde build, but couldn't figure out how to get the network running, and the brower wouldn't come up. David Lang ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: debxo 0.3 release
On Sun, 2 Nov 2008 06:44:14 -0800 (PST) [EMAIL PROTECTED] wrote: thanks for doing this. I never thought that putting KDE or Gnome on any system would seem like a speedup, but it definantly does. so now that the basic system is working, where do I get started to enable the less common features of the XO? specificly 1. controlling the backlight (and therefor the video mode between monocrome and color) 2. recognising the game keys and mapping them to keys/actions I haven't worked on either of these yet. If you (or anyone else) get it working, please either email me or edit the DebXO wiki page to describe the process. I'm more than happy to include that stuff in the next release. 3. switch out the audio filters on the mic input Kernel stuff that I need to look into.. 4. accessing data from the stylis portions of the trackpad This won't happen, as the touchpad's Advanced mode is too buggy (and newer XOs won't have stylus hardware at all). I also tried the lxde build, but couldn't figure out how to get the network running, and the brower wouldn't come up. David Lang I use the gnome build (for now); I'm relying entirely on others for fixes to the other desktops. Patches gratefully accepted. :) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: debxo 0.3 release
andres wrote: On Sun, 2 Nov 2008 06:44:14 -0800 (PST) [EMAIL PROTECTED] wrote: thanks for doing this. I never thought that putting KDE or Gnome on any system would seem like a speedup, but it definantly does. so now that the basic system is working, where do I get started to enable the less common features of the XO? specificly 1. controlling the backlight (and therefor the video mode between monocrome and color) i suggest searching olpcnews.com/forum for things like this -- last year's g1g1 users have done a lot of work supporting the XO h/w under non-sugary environments. my variation on the backlight thing: http://dev.laptop.org/~pgf/brightness.sh.txt 2. recognising the game keys and mapping them to keys/actions I haven't worked on either of these yet. If you (or anyone else) get it working, please either email me or edit the DebXO wiki page to describe the process. I'm more than happy to include that stuff in the next release. on a couple of ubuntu-based thin client machines i have i run a very simple daemon that eavesdrops on an /dev/input/eventN node in order to support special multi-media keyboard keys. i suspect it would be easy to adapt this to supporting the XO special keys if there's not already a packaged way of doing it. (the keys invoke arbitrary scripts, and iirc, they're active in either console or X11 modes.) (btw, if there's very much debxo talk, it might be worth setting up a separate list, since support for other distributions is somewhat off-topic for this one.) paul =- paul fox, [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Pycon'09 CFP
Folks, Turns out that the Pycon'09 deadline for proposal submission is tomorrow. Are we giving any talks? Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
os 8.2 on SD for boot?
I would like to put the current 8.2 release onto an SD card for booting (with a developer's key) to allow me to better support my family and friends XOs. Right now, any customizations such as printer support or additional applications get wiped whenever there is an os update. The thought was to maintain the official XO os on the internal NAND as a safe default but to use the SD card OS for routine use. The catch is I haven't gotten far enought up the learning curve to tweak the ofw and the default config of the release distribution for this purpose. If anyone has a recipe to follow for this modification or even a list of things to fix (item by item) so I can research the wiki and mailing lists it would be a huge help. I visit my folks this weekend and would like to set things up then if possible. Thanks, Chris ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: os 8.2 on SD for boot?
I would like to put the current 8.2 release onto an SD card for booting (with a developer's key) to allow me to better support my family and friends XOs. Right now, any customizations such as printer support or additional applications get wiped whenever there is an os update. The thought was to maintain the official XO os on the internal NAND as a safe default but to use the SD card OS for routine use. The catch is I haven't gotten far enought up the learning curve to tweak the ofw and the default config of the release distribution for this purpose. If anyone has a recipe to follow for this modification or even a list of things to fix (item by item) so I can research the wiki and mailing lists it would be a huge help. I visit my folks this weekend and would like to set things up then if possible. It should be possible using the same procedures and installing Fedora 10 on an SD card. Details to do that can be found here https://fedoraproject.org/wiki/QA/TestPlans/Fedora10_On_XO Peter ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: debxo 0.3 release
On Sun, 2 Nov 2008, [EMAIL PROTECTED] wrote: andres wrote: On Sun, 2 Nov 2008 06:44:14 -0800 (PST) [EMAIL PROTECTED] wrote: thanks for doing this. I never thought that putting KDE or Gnome on any system would seem like a speedup, but it definantly does. so now that the basic system is working, where do I get started to enable the less common features of the XO? specificly 1. controlling the backlight (and therefor the video mode between monocrome and color) i suggest searching olpcnews.com/forum for things like this -- last year's g1g1 users have done a lot of work supporting the XO h/w under non-sugary environments. well, I was hoping that with an open hardware platform running opensource software there would not be a need to search forums for reverse engineered 'secrets' or 'hacks', but instead such information would be readily available (ideally already documented, but possibly in the that's so obvious that we didn't think to write it up catagory for the folks who are experts on the system. my variation on the backlight thing: http://dev.laptop.org/~pgf/brightness.sh.txt thanks, this is exactly the type of thing I was looking for. why did you store the brightness in a file instead of reading the beightness and mode from the /sys hooks? 2. recognising the game keys and mapping them to keys/actions I haven't worked on either of these yet. If you (or anyone else) get it working, please either email me or edit the DebXO wiki page to describe the process. I'm more than happy to include that stuff in the next release. on a couple of ubuntu-based thin client machines i have i run a very simple daemon that eavesdrops on an /dev/input/eventN node in order to support special multi-media keyboard keys. i suspect it would be easy to adapt this to supporting the XO special keys if there's not already a packaged way of doing it. (the keys invoke arbitrary scripts, and iirc, they're active in either console or X11 modes.) is this the 'right' way to do this on a linux system? or is there some way that is more seamless (at least for cases where we want button presses to become normal keys instead of invoking scripts)? (btw, if there's very much debxo talk, it might be worth setting up a separate list, since support for other distributions is somewhat off-topic for this one.) true, but this information is not specific to debxo, it's specific to the hardware, and I don't think that there's a seperate 'hardware support/development' mailing list. if the details of how to deal with the hardware specifics have not already been written up on the wiki somewhere that would reduce my query to a simple URL link, then they should be. I'll gather up the information that I find and am pointed at to try to create such a page. things that I can see as possibly needed game keys extra keyboard keys lid sensors the 'slider' function keys (I seem to remember hearing Jim Getty say something along the lines of the standard X input mechanism can't handle them) the four items above should be available with or without X running, including some ability to set things so that they become 'normal' keystrokes EC interface (battery info and charge status). this may show up under the power interfaces, but from what I've seen on this list the firmware - system API is still being tweaked with, so I don't see how a standard system would know it. backlight controls (documented in the script pointed to above, thanks again) stylis pad (another comment said that this feature was going to just disappear from future versions, I'm disappointed to hear that) information on accessing the mesh mode of the wireless (normal mode works just fine). given the state of mesh networking, and the ability to do ad-hoc normal networking, I'm not sure of how needed this is, but for completeness it should be documented) hardware encryption engine (does this show up to the kernel as an available encryption device? (it would be handy if at least the development builds of the kernel enabled /proc/config.gz for all xo distros (including the OLPC builds) it costs about 10k compressed, 40k raw) things that probably work, but I'm not doing something right the camera is showing up, but I'm not getting usable images from it with the default kde tools mic input (kmix sees the sound device, including DC input mode, which I didn't expect, but I haven't sucessfully recorded anything yet) is there anything else that may need special handling? David Lang ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: idea for running out of RAM
On 2 Nov 2008, at 06:07, Albert Cahalan wrote: On Sat, Nov 1, 2008 at 11:01 AM, Benjamin M. Schwartz [EMAIL PROTECTED] wrote: Albert Cahalan wrote: Memory reservations are a different beast entirely. Running out of memory becomes approximately impossible because the user is blocked from starting too many activities. This seems like a silly statement to me. Almost every activity on the XO is capable of exceeding the hardware memory limit all on its own. If so, then most are broken. Tux Paint doesn't suffer from this defect. The only semi-respectible excuse is that the activity accepts arbitrary input. The web browser is the obvious example. It's only semi-respectible because the activity can often have an internal limit (enforced in the easy code paths) for this, and because partial document rendering can prevent activities like Read from having this problem. If the activity can not be modified to limit itself, then it can't legitimately specify a reservation. Sugar can make these badly behaved activities run by themselves. Per-activity memory reservations are also per-activity limits, and they are only safe if those limits are set higher than the maximum amount of memory required by that activity, and that maximum value is simply far too large. The difference is that activities never get killed under a reservation system unless one is malicious or horribly buggy. Under a limit system, activities will die. It's unacceptable. I like the idea of memory reservations, and they were part of the original design, but if we set them high enough to be safe, we would have a single-tasking (and maybe zero-tasking!) operating system. No, although there are massive usability advantages for the elimination of being able to run multiple things at once. When a kid runs multiple activities, 100% of the time it was unintentional. The kid got confused, probably because the damn frame popped up under his mouse and stole a click. I should also be clear that I don't think Activities should receive the low-mem signal. I think Sugar should catch the low-mem signal, so that it can attempt to do something smarter than the OOM killer because it knows much more about the system. For example, it can choose to kill the activity instance that is using the most memory, or the least-recently-used activity instance, or even the instance that has most recently saved its state. Destroying the user's work by killing an activity: FAIL This works especially well if we also use the knobs on the OOM killer. For example, the low-mem signal, after pausing all other processes, could cause Sugar to (1) select an activity to kill, (2) set that activity's oomadj parameter to make sure that it will be the first one killed if we hit OOM (3) ask that instance to save its state to the datastore, (4) close the activity instance, and (5) pop up a notification to the user about what just happened. In a fit of rage, the kid throws his XO out the window. It just ate his work for the eleventy-seventh time today. Lots of things are wrong with that. You may kill an activity that could have survived; there is no good way to tell when OOM will be hit until you hit it. Setting oomadj doesn't prevent the laptop from getting so slow that the user decides to hard reboot. There is no reasonable way to ask an activity to save state. People don't write perfectly modeless code with atomic operations on a database. Since we can often determine an upper bound for the RAM usage of an activity, we can trivially determine if a given set of activities is capable of causing OOM. If we determine that starting a new activity would place the XO in danger of OOM, then there is no excuse for allowing that activity to start. The cgroups stuff could also help here, since the OOM killer by default thinks in terms of processes, but each Activity can be multiple processes. That would cause activities to die. Work is lost. FAIL Just to chime in on this thread, the 4 conditions that I have (knowingly) encountered OOM in order of importance (personal opinion) are: 1) Read (when zooming in several or more times, zooming on a map is a good use case) 2) Browse (large pages, or long usage, using Google reader for ~20min is a good use case) 3) olpc-update (used to OOM often but seems much better now that 8.2 is final, hoping this is resolved) 4) Control Panel - Software Update (used to OOM often but seems much better now that 8.2 is final, hoping this is resolved) I do think it's still way to easy to double click, or re-click, to multi-launch/resume an activity due to the laggy launch screen appearance (there's plenty of floating trac tickets about this still), but it is much better than it was during some of the 81 unstable dev cycle. However, ** as an adult **, I rarely encounter OOM due to launching too many activities –
Re: debxo 0.3 release
[EMAIL PROTECTED] wrote: On Sun, 2 Nov 2008, [EMAIL PROTECTED] wrote: ... i suggest searching olpcnews.com/forum for things like this -- last year's g1g1 users have done a lot of work supporting the XO h/w under non-sugary environments. well, I was hoping that with an open hardware platform running opensource software there would not be a need to search forums for reverse engineered 'secrets' or 'hacks', but instead such information would be readily available (ideally already documented, but possibly in the that's so obvious that we didn't think to write it up catagory for the folks who are experts on the system. sorry -- i didn't understand which information you were lacking. olpcnews is still a good place to start when doing aftermarket research. the XO is an open system, to be sure, but our focus has been on creating deployment-focused releases, and not on the h/w API documentation. i'm sure this will be get better over time, with the help of motivated helpers. my variation on the backlight thing: http://dev.laptop.org/~pgf/brightness.sh.txt thanks, this is exactly the type of thing I was looking for. why did you store the brightness in a file instead of reading the beightness and mode from the /sys hooks? i think you must have skimmed too quickly -- it's exactly those /sys hooks that it reads and writes.) on a couple of ubuntu-based thin client machines i have i run a very simple daemon that eavesdrops on an /dev/input/eventN node in order to support special multi-media keyboard keys. i suspect it would be easy to adapt this to supporting the XO special keys if there's not already a packaged way of doing it. (the keys invoke arbitrary scripts, and iirc, they're active in either console or X11 modes.) is this the 'right' way to do this on a linux system? or is there some way that is more seamless (at least for cases where we want button presses to become normal keys instead of invoking scripts)? i confess i don't really know that the right way is, since i suspect the right way has changed many times since linux was born, and probably a couple of times before that. i do recall that when i came up with my current solution, i couldn't find a hotkey solution that wasn't completely wedded to either X, or worse, to a specific window manager. i didn't even want the keys to be attached to a specific user login session. (specifically, i wanted the volume/play/pause/mute buttons on my keyboards to control the livingroom stereo no matter who or what was using the computer.) (btw, if there's very much debxo talk, it might be worth setting up a separate list, since support for other distributions is somewhat off-topic for this one.) true, but this information is not specific to debxo, it's specific to the hardware, and I don't think that there's a seperate 'hardware support/development' mailing list. if the details of how to deal with the you're right -- whatever new list might be created shouldn't be aimed at a single distribution. i'll also bet there's overlap with the fedora-on-XO work -- i've misplaced the url for that list at the moment. hardware specifics have not already been written up on the wiki somewhere that would reduce my query to a simple URL link, then they should be. I'll gather up the information that I find and am pointed at to try to create such a page. you might start with this: http://wiki.laptop.org/go/Xfce_keybindings which contains a few of the things you're looking for. things that I can see as possibly needed game keys on a traditional PC keyboard, the keypad area to the right contains duplicate arrow, pgup/down and home/end keys that are operational when numlock is not in effect. the gamepad produces the same keycodes that those keypad keys do. i.e., the dpad produces keypad up/down/left/right, and the square/check/circle/ cross keys produce the traditional keypad page up/down and home/end. (not necessarily in that order -- i don't have an XO handy to verify which are which.) paul extra keyboard keys lid sensors the 'slider' function keys (I seem to remember hearing Jim Getty say something along the lines of the standard X input mechanism can't handle them) the four items above should be available with or without X running, including some ability to set things so that they become 'normal' keystrokes EC interface (battery info and charge status). this may show up under the power interfaces, but from what I've seen on this list the firmware - system API is still being tweaked with, so I don't see how a standard system would know it. backlight controls (documented in the script pointed to above, thanks again) stylis pad (another comment said that this feature was going to just disappear from future versions, I'm disappointed to hear that) information on accessing
Re: debxo 0.3 release
[EMAIL PROTECTED] wrote: well, I was hoping that with an open hardware platform running opensource software there would not be a need to search forums for reverse engineered 'secrets' or 'hacks', but instead such information would be readily available (ideally already documented, I couldn't find a page with this information so I made http://wiki.laptop.org/go/Enabling_XO_features_on_other_distributions , edit away. (Scientific studies have proven this is the only way to arrive at Hopefully this is documented passive-voice happy land. :-) ) Presumably the modifications the XO needs are in the OLPC build of Fedora, either in olpc-specific packages or changes pushed upstream to Fedora. So something in http://xs-dev.laptop.org/~cscott/xo-1/streams/joyride/latest/devel_jffs2/build.log has the modifications? -- =S Page ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: debxo 0.3 release
Hello all, I have a collection of useful XO scripts at daniher.com/shscripts/. Anything in the format of conf.* is a media-setup script. While /extremely/ useful, consider everything beta with no warranty explicit or implicit. The script titled b is one you want to look at - b 0 will set the backlight to black and white and b 15 will set the backlight to max, with a literal value of 15. In other news, daniher.com/shscripts is a generic collecition of day to day scripts which I personally find extremely useful. Enjoy! -- Ian Daniher -- OLPC Support Volunteer OLPCinci Repair Center Coordinator -- [EMAIL PROTECTED] Skype : it.daniher irc.freenode.net: Ian_Daniher On Sun, Nov 2, 2008 at 4:34 PM, [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: On Sun, 2 Nov 2008, [EMAIL PROTECTED] wrote: ... i suggest searching olpcnews.com/forum for things like this -- last year's g1g1 users have done a lot of work supporting the XO h/w under non-sugary environments. well, I was hoping that with an open hardware platform running opensource software there would not be a need to search forums for reverse engineered 'secrets' or 'hacks', but instead such information would be readily available (ideally already documented, but possibly in the that's so obvious that we didn't think to write it up catagory for the folks who are experts on the system. sorry -- i didn't understand which information you were lacking. olpcnews is still a good place to start when doing aftermarket research. the XO is an open system, to be sure, but our focus has been on creating deployment-focused releases, and not on the h/w API documentation. i'm sure this will be get better over time, with the help of motivated helpers. my variation on the backlight thing: http://dev.laptop.org/~pgf/brightness.sh.txthttp://dev.laptop.org/%7Epgf/brightness.sh.txt thanks, this is exactly the type of thing I was looking for. why did you store the brightness in a file instead of reading the beightness and mode from the /sys hooks? i think you must have skimmed too quickly -- it's exactly those /sys hooks that it reads and writes.) on a couple of ubuntu-based thin client machines i have i run a very simple daemon that eavesdrops on an /dev/input/eventN node in order to support special multi-media keyboard keys. i suspect it would be easy to adapt this to supporting the XO special keys if there's not already a packaged way of doing it. (the keys invoke arbitrary scripts, and iirc, they're active in either console or X11 modes.) is this the 'right' way to do this on a linux system? or is there some way that is more seamless (at least for cases where we want button presses to become normal keys instead of invoking scripts)? i confess i don't really know that the right way is, since i suspect the right way has changed many times since linux was born, and probably a couple of times before that. i do recall that when i came up with my current solution, i couldn't find a hotkey solution that wasn't completely wedded to either X, or worse, to a specific window manager. i didn't even want the keys to be attached to a specific user login session. (specifically, i wanted the volume/play/pause/mute buttons on my keyboards to control the livingroom stereo no matter who or what was using the computer.) (btw, if there's very much debxo talk, it might be worth setting up a separate list, since support for other distributions is somewhat off-topic for this one.) true, but this information is not specific to debxo, it's specific to the hardware, and I don't think that there's a seperate 'hardware support/development' mailing list. if the details of how to deal with the you're right -- whatever new list might be created shouldn't be aimed at a single distribution. i'll also bet there's overlap with the fedora-on-XO work -- i've misplaced the url for that list at the moment. hardware specifics have not already been written up on the wiki somewhere that would reduce my query to a simple URL link, then they should be. I'll gather up the information that I find and am pointed at to try to create such a page. you might start with this: http://wiki.laptop.org/go/Xfce_keybindings which contains a few of the things you're looking for. things that I can see as possibly needed game keys on a traditional PC keyboard, the keypad area to the right contains duplicate arrow, pgup/down and home/end keys that are operational when numlock is not in effect. the gamepad produces the same keycodes that those keypad keys do. i.e., the dpad produces keypad up/down/left/right, and the square/check/circle/ cross keys produce the traditional keypad page up/down and home/end. (not necessarily in that order -- i don't have an XO handy to verify which are which.) paul extra
Re: debxo 0.3 release
[EMAIL PROTECTED] wrote: you might start with this: http://wiki.laptop.org/go/Xfce_keybindings which contains a few of the things you're looking for. Also , Screen Brightness/Rotation, Sound Volume, and Battery Status Control in http://wiki.laptop.org/go/XFCE references olpc-keybind and genmon packages. Maybe they're not specific to switching OLPC Sugar Fedora to XFCE. -- =S ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: os 8.2 on SD for boot?
Right now, any customizations such as printer support or additional applications get wiped whenever there is an os update. I've been wrestling with concepts like this ever since I got my G1G1. The XO-1 limitation is the available storage. Sooner or later, both the executables and the data will exceed what the base XO-1 keeps on hand. Plus, I now have multiple XOs and need to keep their customizations all up to date. My solution so far has been a permanent SD card. I 'offload' all huge directories that bundles place in /home/olpc to my SD card, and replace them with symbolic links. Likewise with ported Linux applications that are not sugarized. [I've made up setup scripts that insert those links into the base system (plus install some kernel packages from repositories on the SD card) -- that allows me to copy a *single* SD card image to each of several XOs - add one environmental variable that defines the local SD card's hardware ID, run the setup scripts - and it all works.] The result: *all* my additional support is on the permanent SD card - by now, totaling multiple GBs. [When I add/replace the SD card, I need to enter its ID into a canned location based on /home/olpc.] Whenever there is an os update, I just re-run my setup scripts which link in (into the new os) the additional support I have. [Takes minutes instead of hours to get the new os customized the way I want it.] When I add more facilities, I do so to the SD card on my master XO. [Of course, I have to update my setup scripts as well - they too are on the SD card.] Then I simply copy the SD card contents from the master XO to my other XOs (I have a wired connection, so the time taken is not huge), and re-run the setup scripts on each other XO for whatever has changed. mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: debxo 0.3 release
On Sun, 2 Nov 2008, [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: On Sun, 2 Nov 2008, [EMAIL PROTECTED] wrote: ... i suggest searching olpcnews.com/forum for things like this -- last year's g1g1 users have done a lot of work supporting the XO h/w under non-sugary environments. well, I was hoping that with an open hardware platform running opensource software there would not be a need to search forums for reverse engineered 'secrets' or 'hacks', but instead such information would be readily available (ideally already documented, but possibly in the that's so obvious that we didn't think to write it up catagory for the folks who are experts on the system. sorry -- i didn't understand which information you were lacking. olpcnews is still a good place to start when doing aftermarket research. the XO is an open system, to be sure, but our focus has been on creating deployment-focused releases, and not on the h/w API documentation. i'm sure this will be get better over time, with the help of motivated helpers. no problem, I may have been wishing too hard my variation on the backlight thing: http://dev.laptop.org/~pgf/brightness.sh.txt thanks, this is exactly the type of thing I was looking for. why did you store the brightness in a file instead of reading the beightness and mode from the /sys hooks? i think you must have skimmed too quickly -- it's exactly those /sys hooks that it reads and writes.) you are right, for some reason I read that as reading in a local file, sorry. on a couple of ubuntu-based thin client machines i have i run a very simple daemon that eavesdrops on an /dev/input/eventN node in order to support special multi-media keyboard keys. i suspect it would be easy to adapt this to supporting the XO special keys if there's not already a packaged way of doing it. (the keys invoke arbitrary scripts, and iirc, they're active in either console or X11 modes.) is this the 'right' way to do this on a linux system? or is there some way that is more seamless (at least for cases where we want button presses to become normal keys instead of invoking scripts)? i confess i don't really know that the right way is, since i suspect the right way has changed many times since linux was born, and probably a couple of times before that. i do recall that when i came up with my current solution, i couldn't find a hotkey solution that wasn't completely wedded to either X, or worse, to a specific window manager. i didn't even want the keys to be attached to a specific user login session. (specifically, i wanted the volume/play/pause/mute buttons on my keyboards to control the livingroom stereo no matter who or what was using the computer.) exactly things that I can see as possibly needed game keys on a traditional PC keyboard, the keypad area to the right contains duplicate arrow, pgup/down and home/end keys that are operational when numlock is not in effect. the gamepad produces the same keycodes that those keypad keys do. i.e., the dpad produces keypad up/down/left/right, and the square/check/circle/ cross keys produce the traditional keypad page up/down and home/end. (not necessarily in that order -- i don't have an XO handy to verify which are which.) hmm, I don't think they are the same keycodes at the hardware level. if they were then they would work the same in all software, and what I'm seeing is that on the debxo systems the game keys are doing nothing. given that the system can tell the difference between booting and holding down a game key, or booting and holding down an arrow key, they have to be different at some point. the OLPC builds then map them to the same thing, but I don't think they must be that way (and I've had a ticket in since last december asking for info on how to map them to other keys) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: debxo 0.3 release
On Sun, 2 Nov 2008, [EMAIL PROTECTED] wrote: mic input (kmix sees the sound device, including DC input mode, which I didn't expect, but I haven't sucessfully recorded anything yet) I found that I had the mic muted. once that was changed I got feedback :-) everthing seems to be supported by the standard alsa aware tools. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: debxo 0.3 release
[EMAIL PROTECTED] wrote: On Sun, 2 Nov 2008, [EMAIL PROTECTED] wrote: on a traditional PC keyboard, the keypad area to the right contains duplicate arrow, pgup/down and home/end keys that are operational when numlock is not in effect. the gamepad produces the same keycodes that those keypad keys do. i.e., the dpad produces keypad up/down/left/right, and the square/check/circle/ cross keys produce the traditional keypad page up/down and home/end. (not necessarily in that order -- i don't have an XO handy to verify which are which.) hmm, I don't think they are the same keycodes at the hardware level. if they were then they would work the same in all software, and what I'm seeing is that on the debxo systems the game keys are doing nothing. given that the system can tell the difference between booting and holding down a game key, or booting and holding down an arrow key, they have to be different at some point. yes, i see what you mean -- just tried it. i stand corrected -- i didn't think there was much magic there, but i guess there's more than i thought. paul =- paul fox, [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: debxo 0.3 release
things that I can see as possibly needed: hardware encryption engine (does this show up to the kernel as an available encryption device? (it would be handy if at least the development builds of the kernel enabled /proc/config.gz for all xo distros (including the OLPC builds) it costs about 10k compressed, 40k raw) The Geode hardware encryption engine is useless for Unix user programs. It was apparently designed for/by hardware engineers who had no idea how an operating system or a crypto library works. It can only be accessed via DMA using physical addresses, which means a user program that wanted to do AES would have to do a kernel call and the kernel would have to copy the data to reside in contiguous physical memory, then copy the results back and return to user space. It's much faster to simply do AES in software for virtually every application (and that software's already coded and tested). If the Geode designers had only made the engine accessible via unprivileged instructions that took operands from registers or virtual memory, we'd have seen a very different result. is there anything else that may need special handling? Suspend/resume, e.g. when you close the lid. John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: debxo 0.3 release
On Sun, 2 Nov 2008, [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: On Sun, 2 Nov 2008, [EMAIL PROTECTED] wrote: on a traditional PC keyboard, the keypad area to the right contains duplicate arrow, pgup/down and home/end keys that are operational when numlock is not in effect. the gamepad produces the same keycodes that those keypad keys do. i.e., the dpad produces keypad up/down/left/right, and the square/check/circle/ cross keys produce the traditional keypad page up/down and home/end. (not necessarily in that order -- i don't have an XO handy to verify which are which.) hmm, I don't think they are the same keycodes at the hardware level. if they were then they would work the same in all software, and what I'm seeing is that on the debxo systems the game keys are doing nothing. given that the system can tell the difference between booting and holding down a game key, or booting and holding down an arrow key, they have to be different at some point. yes, i see what you mean -- just tried it. i stand corrected -- i didn't think there was much magic there, but i guess there's more than i thought. doing a little more digging with xbindkeys I am finding that some keys do not show up the x/, frame, alt-gw, left and right hand buttons, and the four game keys on the right all produce keycodes, but the rotate key, game direction pad, the key next to the frame key, the key between escape and F1 do not produce any output. David Lang ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: debxo 0.3 release
On Sun, 2 Nov 2008, John Gilmore wrote: things that I can see as possibly needed: hardware encryption engine (does this show up to the kernel as an available encryption device? (it would be handy if at least the development builds of the kernel enabled /proc/config.gz for all xo distros (including the OLPC builds) it costs about 10k compressed, 40k raw) The Geode hardware encryption engine is useless for Unix user programs. It was apparently designed for/by hardware engineers who had no idea how an operating system or a crypto library works. It can only be accessed via DMA using physical addresses, which means a user program that wanted to do AES would have to do a kernel call and the kernel would have to copy the data to reside in contiguous physical memory, then copy the results back and return to user space. It's much faster to simply do AES in software for virtually every application (and that software's already coded and tested). If the Geode designers had only made the engine accessible via unprivileged instructions that took operands from registers or virtual memory, we'd have seen a very different result. what about the kernel encryption modules? those aren't suitable for a lot of userspace code, but for other things (like network encryption where they kernel is already processing the data) can the CPU support replace/supplement the software versions? is there anything else that may need special handling? Suspend/resume, e.g. when you close the lid. the lid buttons handle detection of closing the lid for suspend/resume what special cases are needed? or are you just saying that we need to check the suspend/resume support for all the hardware and make sure it's in the upstream kernel (and test it regularly so that they don't make a change that breaks it)? David Lang ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: debxo 0.3 release
The TODO file in the xodist git repository has a hardware enablement section that I added last week, which covers some of the things this thread has discussed. -- cut -- hardware enablement --- keymap for the extra keyboard keys and game buttons key to right of esc, second from start of first row key to right of f12, second from end of first row fn, first key on last row multiply divide, last key on second last row brightness control keys (conflicts with function key usage) volume control keys (conflicts with function key usage) turn off backlight on suspend or hibernate hibernate on lid close -- cut -- Yes, it may be just a matter of finding out how the OLPC OS builds do the task and ensuring that the patch goes upstream far enough ... but if not, the other solutions are: 1. producing .deb forms of the OLPC specific .rpm packages, (repackaging work), or 2. producing short hacks that make configuration changes to the generated root filesystem before making the image. The latter method is how xodist's initchroot.sh script does some features ... like setting up /etc/modules, xorg.conf, and so forth. If you would like to help, then research how to get the effect you desire, test it on a laptop, then adjust initchroot to do it, try generating new images, and send us the patch. -- On the weekend I had two visits by five kids and four adults, and I left a collection of XOs lying around for them to play with, half with the G1G1 activity set, and half with a debxo KDE build. The younger kids who had not used computers much before certainly selected the G1G1 units. The older kids and adults who have used computers extensively found the KDE builds more fascinating. It's what they knew. -- James Cameronmailto:[EMAIL PROTECTED] http://quozl.netrek.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: debxo 0.3 release
On Mon, 3 Nov 2008, James Cameron wrote: The TODO file in the xodist git repository has a hardware enablement section that I added last week, which covers some of the things this thread has discussed. link to xodist please? keymap for the extra keyboard keys and game buttons key to right of esc, second from start of first row key to right of f12, second from end of first row do you have the direction and rotate game keys working? xbindkeys shows the O game key as as m:0x0 + c:229 xbindkeys shows the X game key as as m:0x0 + c:230 xbindkeys shows the [] game key as as m:0x0 + c:231 xbindkeys shows the check game key as as m:0x0 + c:222 fn, first key on last row xbindkeys shows this as m:0x0 + c:157 multiply divide, last key on second last row xbindkeys shows this as m:0x0 + c:211 brightness control keys (conflicts with function key usage) volume control keys (conflicts with function key usage) these don't need system changes, just deciding which function those keys should do, the brightness and volume functions are strictly in software (and done via X hooks, as can be shown by the fact that these do not work in a console, and in fact crash the system if you hit them there) turn off backlight on suspend or hibernate I don't use suspend or hibernate enough to help, but now that we have the script to control the backlight this should be fairly easy (although you really want to turn off the entire screen, not just the backlight, at least for hibernate, don't you?) hibernate on lid close once we find a way to get key input from those magnetic sensors this should be pretty easy. Yes, it may be just a matter of finding out how the OLPC OS builds do the task and ensuring that the patch goes upstream far enough ... but if not, the other solutions are: 1. producing .deb forms of the OLPC specific .rpm packages, (repackaging work), or 2. producing short hacks that make configuration changes to the generated root filesystem before making the image. The latter method is how xodist's initchroot.sh script does some features ... like setting up /etc/modules, xorg.conf, and so forth. I'm actually not happy with how the OLPC currently handles these things, they are too X (and sugar) specific. we need to get a layer lower if we can. If you would like to help, then research how to get the effect you desire, test it on a laptop, then adjust initchroot to do it, try generating new images, and send us the patch. that's what I'm working on, I figured I'd ask first on the chances that someone had already done the research ;-) On the weekend I had two visits by five kids and four adults, and I left a collection of XOs lying around for them to play with, half with the G1G1 activity set, and half with a debxo KDE build. The younger kids who had not used computers much before certainly selected the G1G1 units. The older kids and adults who have used computers extensively found the KDE builds more fascinating. It's what they knew. interesting. David Lang ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: debxo 0.3 release
On Sun, Nov 02, 2008 at 09:27:52PM -0800, [EMAIL PROTECTED] wrote: On Mon, 3 Nov 2008, James Cameron wrote: The TODO file in the xodist git repository has a hardware enablement section that I added last week, which covers some of the things this thread has discussed. link to xodist please? xodist is the git repository name for the scripts that generate debxo images. git://lunge.mit.edu/git/xodist (per Andres' mail of 28th Oct) or http://dev.laptop.org/~quozl/xodist.git/ (my repo, sync'ed) do you have the direction and rotate game keys working? I don't know. brightness control keys (conflicts with function key usage) volume control keys (conflicts with function key usage) these don't need system changes, just deciding which function those keys should do, the brightness and volume functions are strictly in software (and done via X hooks, as can be shown by the fact that these do not work in a console, and in fact crash the system if you hit them there) Seems more logical to handle these keys in the kernel. turn off backlight on suspend or hibernate I don't use suspend or hibernate enough to help, but now that we have the script to control the backlight this should be fairly easy (although you really want to turn off the entire screen, not just the backlight, at least for hibernate, don't you?) If you're saying the OLPC XO build also turns off the screen hardware, then the next question is how? ... presumably this can be found by examining it. The latter method is how xodist's initchroot.sh script does some features ... like setting up /etc/modules, xorg.conf, and so forth. I'm actually not happy with how the OLPC currently handles these things, they are too X (and sugar) specific. we need to get a layer lower if we can. Good. But the general purpose solutions in Debian are perhaps too general for this situation. Things like the discover package. -- James Cameronmailto:[EMAIL PROTECTED] http://quozl.netrek.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: debxo 0.3 release
On Mon, 3 Nov 2008, James Cameron wrote: On Sun, Nov 02, 2008 at 09:27:52PM -0800, [EMAIL PROTECTED] wrote: On Mon, 3 Nov 2008, James Cameron wrote: The TODO file in the xodist git repository has a hardware enablement section that I added last week, which covers some of the things this thread has discussed. link to xodist please? xodist is the git repository name for the scripts that generate debxo images. sorry, I missed that (and I even have that repository cloned, shame on me :-) git://lunge.mit.edu/git/xodist (per Andres' mail of 28th Oct) or http://dev.laptop.org/~quozl/xodist.git/ (my repo, sync'ed) do you have the direction and rotate game keys working? I don't know. they do not in the 0.3 build brightness control keys (conflicts with function key usage) volume control keys (conflicts with function key usage) these don't need system changes, just deciding which function those keys should do, the brightness and volume functions are strictly in software (and done via X hooks, as can be shown by the fact that these do not work in a console, and in fact crash the system if you hit them there) Seems more logical to handle these keys in the kernel. I don't think so. since the hardware produces the function keys, if the kernel does the functions instead of userspace, you loose the flexibility to use these as normal function keys. the tendancy is to push more of this sort of thing to userspace anyway. the volume keys onthe thinkpads recently changed from being handled by the hardware to be intercepted by the kernel and treated as normal keys (with the default bindings being to control the volume) a few months ago this worked in Gnome, but not KDE, with the ubuntu release a few days ago it works in both (I don't use sound enough to have tried it outside of X) turn off backlight on suspend or hibernate I don't use suspend or hibernate enough to help, but now that we have the script to control the backlight this should be fairly easy (although you really want to turn off the entire screen, not just the backlight, at least for hibernate, don't you?) If you're saying the OLPC XO build also turns off the screen hardware, then the next question is how? ... presumably this can be found by examining it. the thought just hit me that we don't always want to turn off the screen on suspend, unlike normal systems the XO is designed to be able to run the display when the main processor is suspended (although I remember being told that this isn't working due to software limitations today) The latter method is how xodist's initchroot.sh script does some features ... like setting up /etc/modules, xorg.conf, and so forth. I'm actually not happy with how the OLPC currently handles these things, they are too X (and sugar) specific. we need to get a layer lower if we can. Good. But the general purpose solutions in Debian are perhaps too general for this situation. Things like the discover package. ideally I want to figure out how to get these keys into the kernel, at that point any userspace can deal with them. David Lang ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Game keys
David Lang wrote: ideally I want to figure out how to get these keys into the kernel, at that point any userspace can deal with them. The game keys produce scancodes that are folded into the keyboard data stream. The kernel sees them interspersed with ordinary keyboard scan codes. What it does with them depends on a lot of factors that I haven't bothered to understand in detail. I think there are several different ways that scancodes can be mapped into ASCII or other events, depending on whether you are using a console or X or whatever. I respectfully submit that getting the codes from the kernel to any userspace is quite a bit more complicated in practice than the above assertion seems to imply. Here is an OFW recipe you can use to see the scancode sequences: ok disable-interrupts ok stdin @ iselect ok 20 0 do begin get-data? until . loop they type some keys or press some game buttons. That will display 32 (0x20) scancodes. You can re-execute it (up-arrow, enter) to see more. OFW uses scan set 1, so the codes that you will see are from that set. It turns out that the game keys codes are always from scan set 1; they don't change if you tell the keyboard to use scan set 2, and they don't change if you tell the EC to translate or not translate from set 2 to set 1. The general form of scanset 1 is: [ optional 0xe0 prefix ] make-code [ optional 0xe0 prefix ] break-code For a given key, break-code is 0x80 | make-code The 0xe0 prefix is generally used to distinguish between multiple copies of the same key. For example, a full sized keyboard has two 1 keys, one in the row above the alpha keys and one in the numeric keypad. If you try the above program with the game keys, you will see that the left and right game key clusters use the same base codes, but the right cluster has prefixes. It's also possible to ask the embedded controller to tell you which game keys are currently depressed; the return value is a bitmask of which ones are down. That's useful for early firmware tests before the keyboard event stream is initialized, but not particularly useful in the Linux event-driven regime. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: setup for XO development
On Fri, Oct 31, 2008 at 2:25 PM, Bobby Powers [EMAIL PROTECTED] wrote: very interesting. you mentioned working to integrate rainbow with sugar-jhbuid. It seems like that should be using this native version. If we're not using the d-bus daemon, would we then have to start jhbuild with 'sudo'? Do you have any further pointers on what to look out for when trying to integrate it into jhbuild? I think the idea is to make it trivial to install rainbow in the system by providing deb and rpms of it. Then jhbuild can run using rainbow. Marco ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
