Re: debxo 0.3 release
Hi Luke, On Sunday 16 November 2008 04:14, Luke Faraone wrote: Something strange when installing/removing packages under the base installation: http://pastebin.ca/1254906 This warning/error also occured when I was using the olpc-update debian installation. you can fix this by running export LANG=C before you do so. regards, Holger pgpfpOUGSDkaF.pgp Description: PGP signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: debxo 0.3 release
On Sat, Nov 15, 2008 at 07:14:23PM -0800, Luke Faraone wrote: Andres Salomon-4 wrote: - A new 'base' desktop has been added. This is a minimal install, with no graphics or X at all. It's good for rescue situations, or where you have a local package mirror and don't want to waste bandwidth downloading a graphical desktop image. Something strange when installing/removing packages under the base installation: http://pastebin.ca/1254906 This warning/error also occured when I was using the olpc-update debian installation. I believe you can resolve these warnings by running the locale-gen utility. Erik ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: debxo 0.3 release
On 2008-11-17, Erik Garrison [EMAIL PROTECTED] wrote: I believe you can resolve these warnings by running the locale-gen utility. I had already run that, and the discouraging results pasted in the top of the pastebin. -lf ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: debxo 0.3 release
On Mon, Nov 17, 2008 at 01:42:17PM -0500, [EMAIL PROTECTED] wrote:
On 2008-11-17, Erik Garrison [EMAIL PROTECTED] wrote:
I believe you can resolve these warnings by running the locale-gen
utility.
I had already run that, and the discouraging results pasted in the top
of the pastebin.
The error message and its location in the source [1]:
/* Map the header and all the administration data structures. */
p = mmap64 (NULL, total, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
if (p == MAP_FAILED)
{
int errval = errno;
unlink (fname);
error (EXIT_FAILURE, errval, _(cannot map archive header));
}
... suggest that the problem is that localegen is trying to do a shared
writeable mmap. These do not work on jffs2 [2].
I don't know the best way to proceed, but it would appear we need to
raise the issue with upstream. It will not be fixed in jffs2.
That said, I am running debxo 0.3 base and not seeing the same error
messages. (I see that the locale is set to POSIX immediately after
installation.)
Erik
[1] http://ftp.gnu.org/gnu/glibc/glibc-2.7.tar.gz
[2] http://www.infradead.org/pipermail/linux-mtd/2003-March/007166.html
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: debxo 0.3 release
On Mon, Nov 17, 2008 at 15:04, Erik Garrison [EMAIL PROTECTED] wrote:
On Mon, Nov 17, 2008 at 01:42:17PM -0500, [EMAIL PROTECTED] wrote:
On 2008-11-17, Erik Garrison [EMAIL PROTECTED] wrote:
I believe you can resolve these warnings by running the locale-gen
utility.
I had already run that, and the discouraging results pasted in the top
of the pastebin.
The error message and its location in the source [1]:
/* Map the header and all the administration data structures. */
p = mmap64 (NULL, total, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
if (p == MAP_FAILED)
{
int errval = errno;
unlink (fname);
error (EXIT_FAILURE, errval, _(cannot map archive header));
}
... suggest that the problem is that localegen is trying to do a shared
writeable mmap. These do not work on jffs2 [2].
I don't know the best way to proceed, but it would appear we need to
raise the issue with upstream. It will not be fixed in jffs2.
That said, I am running debxo 0.3 base and not seeing the same error
messages. (I see that the locale is set to POSIX immediately after
installation.)
This is very odd.
I do not experience this problem right after install, but only after
updating, locale is set to a new version, which may be when this bug is
introduced.
-lf
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: debxo 0.3 release
On Mon, Nov 17, 2008 at 03:43:27PM -0500, Luke Faraone wrote:
On Mon, Nov 17, 2008 at 15:04, Erik Garrison [EMAIL PROTECTED] wrote:
On Mon, Nov 17, 2008 at 01:42:17PM -0500, [EMAIL PROTECTED] wrote:
On 2008-11-17, Erik Garrison [EMAIL PROTECTED] wrote:
I believe you can resolve these warnings by running the locale-gen
utility.
I had already run that, and the discouraging results pasted in the top
of the pastebin.
The error message and its location in the source [1]:
/* Map the header and all the administration data structures. */
p = mmap64 (NULL, total, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
if (p == MAP_FAILED)
{
int errval = errno;
unlink (fname);
error (EXIT_FAILURE, errval, _(cannot map archive header));
}
... suggest that the problem is that localegen is trying to do a shared
writeable mmap. These do not work on jffs2 [2].
I don't know the best way to proceed, but it would appear we need to
raise the issue with upstream. It will not be fixed in jffs2.
That said, I am running debxo 0.3 base and not seeing the same error
messages. (I see that the locale is set to POSIX immediately after
installation.)
This is very odd.
I do not experience this problem right after install, but only after
updating, locale is set to a new version, which may be when this bug is
introduced.
Immediately after install my glibc version is glibc-2.7-1. This is
where I have found the above lines of code.
I updated, upgraded, and I still don't get the error.
I did notice this error when building a base image, but it goes away as
soon as the locale package is installed in the chroot.
Erik
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: debxo 0.3 release
Andres Salomon-4 wrote: - A new 'base' desktop has been added. This is a minimal install, with no graphics or X at all. It's good for rescue situations, or where you have a local package mirror and don't want to waste bandwidth downloading a graphical desktop image. Something strange when installing/removing packages under the base installation: http://pastebin.ca/1254906 This warning/error also occured when I was using the olpc-update debian installation. -- View this message in context: http://n2.nabble.com/debxo-0.3-release-tp1392012p1504816.html Sent from the OLPC Software development mailing list archive at Nabble.com. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: debxo 0.3 release
luke wrote: Andres Salomon-4 wrote: - A new 'base' desktop has been added. This is a minimal install, with no graphics or X at all. It's good for rescue situations, or where you have a local package mirror and don't want to waste bandwidth downloading a graphical desktop image. Something strange when installing/removing packages under the base installation: http://pastebin.ca/1254906 This warning/error also occured when I was using the olpc-update debian installation. fwiw, i've used the base desktop and not seen these locale errors. paul =- paul fox, [EMAIL PROTECTED] give one laptop, get one laptop --- http://www.amazon.com/xo ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: debxo 0.3 release
Hey all, tidbits: http://olpcnews.com/forum/index.php?topic=2240.msg26267;topicseen#msg26267 * working power management(tested) modprobe olpc_battery * enables battery level detection - grab battery-status script from an XO running 8.2 sudo ifconfig eth0 up * makes the eth0 interface show up if it's otherwise hidden or 'down' Can someone please wikify this stuff? Enjoy! -- Ian Daniher -- OLPC Support Volunteer OLPCinci Repair Center Coordinator -- [EMAIL PROTECTED] Skype : it.daniher irc.freenode.net: Ian_Daniher On Mon, Nov 3, 2008 at 12:24 PM, Erik Garrison [EMAIL PROTECTED] wrote: This sounds right. The OHM packages aren't in any debian repo afaik, so we'll have to package them. Then we'd need a debian repository for these packages. On Mon, Nov 03, 2008 at 11:53:40AM -0500, Ian Daniher wrote: RE Suspend / Resume : talk to CJB(Chris Ball) about OHM. I spoke with him a few weeks ago and, if I recall correctly, all one needs to do is use the official OLPC Kernel and install the OHM packages. On Mon, Nov 3, 2008 at 1:20 AM, [EMAIL PROTECTED] wrote: 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/http://dev.laptop.org/%7Equozl/xodist.git/ http://dev.laptop.org/%7Equozl/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 -- Ian Daniher -- OLPC Support Volunteer OLPCinci Repair Center Coordinator -- [EMAIL PROTECTED] Skype : it.daniher irc.freenode.net: Ian_Daniher -- c: 513.290.4942 ___ Devel mailing list Devel@lists.laptop.org
Re: debxo 0.3 release
ian wrote: Hey all, tidbits: http://olpcnews.com/forum/index.php?topic=2240.msg26267;topicseen#msg26267 * working power management(tested) modprobe olpc_battery * enables battery level detection - grab battery-status script from an XO running 8.2 sudo ifconfig eth0 up * makes the eth0 interface show up if it's otherwise hidden or 'down' Can someone please wikify this stuff? don't you have a wiki login? :-) paul =- paul fox, [EMAIL PROTECTED] give one laptop, get one laptop --- http://www.amazon.com/xo ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: debxo 0.3 release
RE Suspend / Resume : talk to CJB(Chris Ball) about OHM. I spoke with him a few weeks ago and, if I recall correctly, all one needs to do is use the official OLPC Kernel and install the OHM packages. On Mon, Nov 3, 2008 at 1:20 AM, [EMAIL PROTECTED] wrote: 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/http://dev.laptop.org/%7Equozl/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 -- Ian Daniher -- OLPC Support Volunteer OLPCinci Repair Center Coordinator -- [EMAIL PROTECTED] Skype : it.daniher irc.freenode.net: Ian_Daniher -- c: 513.290.4942 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: debxo 0.3 release
This sounds right. The OHM packages aren't in any debian repo afaik, so we'll have to package them. Then we'd need a debian repository for these packages. On Mon, Nov 03, 2008 at 11:53:40AM -0500, Ian Daniher wrote: RE Suspend / Resume : talk to CJB(Chris Ball) about OHM. I spoke with him a few weeks ago and, if I recall correctly, all one needs to do is use the official OLPC Kernel and install the OHM packages. On Mon, Nov 3, 2008 at 1:20 AM, [EMAIL PROTECTED] wrote: 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/http://dev.laptop.org/%7Equozl/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 -- Ian Daniher -- OLPC Support Volunteer OLPCinci Repair Center Coordinator -- [EMAIL PROTECTED] Skype : it.daniher irc.freenode.net: Ian_Daniher -- c: 513.290.4942 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 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: 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: 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: 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
Re: debxo 0.3 release
Or, as I found out, if you have the developer key on a pen drive, you can boot into debxo from that, and copy develop.sig into /boot/security/, and have security enabled and debxo at the same time, should you want to. Thanks, all. I'll see what I can do about creating a wiki page if there isn't one already. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: debxo 0.3 release
kawk wrote: Or, as I found out, if you have the developer key on a pen drive, you can boot into debxo from that, and copy develop.sig into /boot/security/, and have security enabled and debxo at the same time, should you want to. Thanks, all. I'll see what I can do about creating a wiki page if there isn't one already. http://wiki.laptop.org/go/Activation_and_developer_keys already had this information about recovery when you lose develop.sig. I reorganized it into a If you wipe out your developer key section. There's a http://wiki.laptop.org/go/DebXO page, edit away. Regards, -- =S Page ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: debxo 0.3 release
Every time I try one of the debxo 0.3 or debxo 0.2 JFFS2 images, I get the error message [EMAIL PROTECTED]:75: Error writing to NAND FLASH and it fails. From 0.3, I've tried JFFS2 base and kde, and from 0.2 I've tried KDE. Same error message. I've re-downloaded the images, tried a md5sum on them (I can't find a md5sum for the images anywhere . . . could someone post them?). The steps I am taking to install debxo: - Install base 703 image - Download developer.sig and stick it in /security - Reboot and press ESC to get into OFW - In OFW, type update-nand sd:\imagename.img - Wait - Watch it fail If I'm not doing anything correctly, could someone help me out here? Thanks. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: debxo 0.3 release
Hi, Every time I try one of the debxo 0.3 or debxo 0.2 JFFS2 images, I get the error message [EMAIL PROTECTED]:75: Error writing to NAND FLASH and it fails. You need to upgrade Open Firmware to q2e20. - Chris. -- Chris Ball [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: debxo 0.3 release
On Fri, Oct 31, 2008 at 03:10:08PM -0400, Chris Ball wrote: Hi, Every time I try one of the debxo 0.3 or debxo 0.2 JFFS2 images, I get the error message [EMAIL PROTECTED]:75: Error writing to NAND FLASH and it fails. You need to upgrade Open Firmware to q2e20. You can do so by downloading http://dev.laptop.org/pub/firmware/q2e20/q2e20.rom to a usb key, booting into the the OFW prompt, and typing: flash disk:q2e20.rom You'll need to have external power connected to complete the reflash. Erik ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: debxo 0.3 release
On Fri, Oct 31, 2008 at 03:26:35PM -0400, Erik Garrison wrote: You can do so by downloading http://dev.laptop.org/pub/firmware/q2e20/q2e20.rom to a usb key, booting into the the OFW prompt, and typing: flash disk:q2e20.rom You can also do this from the OFW prompt without using any USB key, provided you have an open wireless network nearby ... Assuming your open wireless network ESSID is frodo, the sequence is: essid frodo flash http:\\dev.laptop.org\pub\firmware\q2e20\q2e20.rom Take careful note that the slashes are reversed. I've often used this method, though I usually bring the file onto a local web server and use a shorter path ... http:\\x\y You'll need to have external power connected to complete the reflash. The same applies. -- 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
I have updated the firmware to Q2E20, and that error message is gone. Instead, once its complete, and I try to boot into debxo, it gives me a sad face and powers off after 10 seconds. Is this because it's an unsigned build, and I have no devel key after the reflash? If so, how can I put a devel key onto an unbootable XO? Thanks. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: debxo 0.3 release
On Fri, Oct 31, 2008 at 06:52:34PM -0400, [EMAIL PROTECTED] wrote: I have updated the firmware to Q2E20, and that error message is gone. Instead, once its complete, and I try to boot into debxo, it gives me a sad face and powers off after 10 seconds. Is this because it's an unsigned build, and I have no devel key after the reflash? Yes, probably. You apparently didn't disable-security, and so by flashing debxo you erased the developer key you had on the NAND flash. If so, how can I put a devel key onto an unbootable XO? Here is what you should do now: 1. put the develop.sig on a USB key again, in a security/ directory, as described in the Wiki page for Developer Keys, 2. put the USB key in the XO, and power up, you should get the OpenFirmware messages, at which you press ESC, and get the ok prompt, 3. type disable-security and press ENTER, there will be a power cycle, 4. press ESC again to cancel the automatic boot, 5. type disable-security and press ENTER. -- 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
[EMAIL PROTECTED] wrote: I have updated the firmware to Q2E20, and that error message is gone. Instead, once its complete, and I try to boot into debxo, it gives me a sad face and powers off after 10 seconds. Is this because it's an unsigned build, and I have no devel key after the reflash? If so, how can I put a devel key onto an unbootable XO? Yes. If you installed you blew away your dev key. Do you have a back up? If not then you can get your key again via the collector key. Details here: http://wiki.laptop.org/go/Activation_and_Developer_Keys#If_the_machine_won.27t_boot Put the key on USB disk in the /security dir and boot the machine with the USB disk inserted. That will unlock your XO. then at the OFW ok prompt type disable-security After that your XO will be forever unlocked unless you enable-security -- Richard Smith [EMAIL PROTECTED] One Laptop Per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
debxo 0.3 release
Hi, Here's a (mostly) bugfix release of DebXO. There was a nasty bug related to JFFS2 and kernel upgrades in 0.2; this release fixes it. Note that there's a known bug on first boot with the gnome install on JFFS2. A warning will pop up due to dbus not starting quickly enough. This can safely be ignored, and shouldn't adversely affect anything. CHANGES: - Disable LZO compression in the JFFS2 driver. This was causing machines to fail to boot after upgrading the kernel. If you're still running DebXO 0.2 on the nand, do not upgrade the kernel. Instead, reflashing is recommended. - A new 'base' desktop has been added. This is a minimal install, with no graphics or X at all. It's good for rescue situations, or where you have a local package mirror and don't want to waste bandwidth downloading a graphical desktop image. - Some programs (including kde and gnome's logout/reboot functions) had problems in previous releases due to lack of loopback interface (oops). Thanks to James Cameron for spotting this. 0.3 sets up 'lo' properly. - Custom DebXO packages are put on hold; this means you can safely 'apt-get dist-upgrade' without having to fear things like initramfs-tools being upgraded. - JFFS2 images uses DOS 8.3 filenames. This is primarily to ensure that when running update-nand disk:\gnome.img using a USB stick that's been formatted using vfat, OFW won't complain about not being able to find the gnome.dat file. As such, the JFFS2 images are named with their desktop names - awesome.img, kde.img, etc. EXT3 images still retain the old naming scheme. - James Cameron added a script that is capable of creating an auto-install USB key (onto nand). - A debxo-latest symlink now points to the latest release. Please use that in wiki/doc pages for download links. Other changes can be seen at: http://lunge.mit.edu/cgi-bin/gitweb.cgi?p=xodist;a=summary INSTALLATION ONTO NAND FLASH: The release can be found here (note that the URL has changed): http://lunge.mit.edu/~dilinger/debxo-0.3/images/ To install onto the XO's flash, download the jffs2/$DESKTOP.dat and jffs2/$DESKTOP.img to a USB or SD stick (where $DESKTOP is one of the various desktops - gnome, kde, lxde, sugar, base, or awesome). Boot into OFW (make sure your XO is unlocked!), and run update-nand disk:\$DESKTOP.img or update-nand sd:\$DESKTOP.img (depending upon whether you downloaded to an SD or USB disk). If update-nand spits out any errors, make sure you're running an appropriately up-to-date version of OFW. The q2d* series do not support update-nand, and versions q2e18 and q2e19 are known to be buggy with partitions. Firmware and instructions for upgrading can be found here: http://wiki.laptop.org/go/Firmware INSTALLATION ONTO SD/USB: To install onto an SD or USB device, download the ext3/debxo-$DESKTOP.ext3.img.gz file, and run zcat debxo-$DESKTOP.ext3.img.gz /dev/mmcblk0 or zcat debxo-$DESKTOP.ext3.img.gz /dev/sdX (depending upon whether you're writing to an SD or USB disk). Note that this will overwrite any data that is on the SD or USB disk. USAGE: By default, a user 'olpc' is created (with no password, and sudo access). Some desktops automatically start a display manager and log you in; some do not. The root password is disabled by default. This is a stock Debian Lenny system with only a few modifications, so it can obviously be tailored. HACKING: xodist is the name of the collection of scripts that are used to produce DebXO. The git repository can be downloaded via: git clone git://lunge.mit.edu/git/xodist There's also a web interface to that: http://lunge.mit.edu/cgi-bin/gitweb.cgi?p=xodist;a=summary There's a TODO file in the repository, but really... just scratch whatever itch you happen to have. Patches are much appreciated. Additional desktops (XFCE, for example?), better handling of the default user/password, boot/runtime optimizations, suggestions for missing packages, etc.. Enjoy! ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
