Re: summary of current paraguayan XO OS customisations
Awesome summary. Especially the journal-restore script will come in
handy right now. The info came at exactly the right time.
This reminds me about the thread started by Michael Stone about
sharing info between deployments. I think we should really put this
kind of technical info up on the l.o wiki, for other deployments and
also as a reference for people making future releases. It's quite
valuable info and there's already quite some duplication of effort
going on. It's all idle talk atm from my part, but hope to find some
time soon in the next week to document some of our stuff up there.
/Ties
On Fri, Mar 13, 2009 at 3:11 AM, Daniel Drake d...@laptop.org wrote:
Hi,
I decided that it's worth sharing a summary of the customisations that
we are making to OLPC OS 801 here in paraguay. Many of these things
would probably be useful for other deployments too, so I'm hoping this
mail makes some recent work of myself and others slightly
better-known. Also I would be interested in helping OLPC include these
in 8.2.1 or 8.2.2...
I expect this list may grow a bit more before we finalize our image,
so I may end up sending another list soon.
-bundles and activities
http://wiki.paraguayeduca.org/index.php/Actividades_y_contenidos
- version number
/boot/olpc_build customised with paraguay branding which then appears in sugar
- acquire leases from the school server over standard 802.11 wireless networks
http://dev.laptop.org/ticket/9289
- customise browse homepage
http://dev.laptop.org/~dsd/20090219/py_home.png
(screenshot is slightly outdated, latest one has non-pixellated
paraguayeduca logo)
(we don't have content to sit behind the 3 links yet)
- make gcompris a favourite activity by default
echo net.gcompris.gcomprisActivity \
${pristine}/usr/share/sugar/data/activities.defaults
- disable unintuitive first boot You should update your activities message
sed -i -e 's/\.sugar-update/\.sugar-update-hackedout/g' \
${pristine}/etc/init.d/olpc-configure
- backup initial sound state, and restore on every reboot
fixes a common but not completely understood problem where sound
completely stops working until reflash
http://dev.laptop.org/ticket/9248
- hook up the Discard network history button to also unregister from the XS
we're in a pickle because current builds deployed to teachers don't
let us unregister easily...this may help us to avoid future pickles
http://dev.sugarlabs.org/ticket/362
- add scripts for journal restore
the current XS restore web interface is sub-standard (can access
everyones files) and doesnt seem like it will offer a single-click
restore my entire journal any time soon
http://dev.laptop.org/ticket/9250
- speed up the activity updater by greatly reducing the number of
requests it has to make over the internet (to 0, assuming that the
user hasn't installed any extra activities)
http://dev.laptop.org/ticket/9259
- implement the client side of lease updates through the theft
deterrence protocol
http://dev.laptop.org/ticket/9288
- make shutdown 15 seconds quicker
http://dev.laptop.org/ticket/9289
Daniel
___
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: Google summer of Code?
2009/3/8 Jameson Quinn jameson.qu...@gmail.com: No definite agreement has been made, but in preliminary chats, it seems that both organizations agree that anything for XS or specific to XO hardware should go in OLPC, and everything else (general Sugar improvements, frameworks, or activities) should go in Sugarlabs. We discussed this at XO camp, and people from Sugar Labs were considering not supporting activity development and focusing on core sugar development. This is correct. Has this changed? In general, do you expect that priorities for toolchain and activity development will be the same? In general, sugar-core and toolchain development is a higher priority than generative Activity development (Activities that lower the barrier to Activity development). It's highly unlikely that non-generative Activity development will be supported. I expect that many activity development and student projects interested in working with current schools will apply for both OLPC and Sugar Labs projects; they are welcome to apply to both, and those doing work relevant to Sugar should be encouraged to! Applying to multiple GSOC groups is standard practice; students do not need to choose. We had a couple of students last year who ended up working on OLPC related projects for other orgs. Yup, I remember that. :) We talked with Cjb about shuttling relevant apps back and forth as needed - what we're doing right now is setting up guidelines that will hopefully minimize the amount of sorting that's needed, then waiting for students to come in, then sorting. Double-apping is not a problem. --Mel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Removing perl from the build
Hi Chris, I've gone through what's been pulling in the perl dependency and narrowed down the packages that are dependant on it to the following list. There's a number of easy fix ones and two that I need to dig further on. The first four should be a matter of just blocking them out of the kickstart file. w3m logwatch lftp fbset This one is because cronie wants a mailer. Daniel and I fixed this one on joyride by explicitly adding ssmtp (a 50K mailer) exim These two will be a little more interesting. I'm going to file some bugs against them. The second one I can't see why it needs perl. The first one we'll see. deltarpm libgnomeprint22 As a followup to this email I filed bugs for the two issues above, I was given permission to fix libgnomeprint22 (BZ 489227) which has been done and should show up in the next rawhide. Still awaiting response for the deltarpm one (BZ 489231). I can create a patch for the kickstart if that makes it easier for you too. As another follow up to this the gnome-python2-evince package (needed from sugar-read) incorrectly required evince-devel which in turn pulls in a chunk of the devel stack plus perl, I've filed RH bug 490112 to get this fixed so hopefully it should be done before too long. If you think its work doing quickly it might be worthwhile adding it to the F11Beta tracker. Peter ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Google summer of Code?
On Fri, Mar 13, 2009 at 1:56 AM, Mel Chua m...@melchua.com wrote: 2009/3/8 Jameson Quinn jameson.qu...@gmail.com: No definite agreement has been made, but in preliminary chats, it seems that both organizations agree that anything for XS or specific to XO hardware should go in OLPC, and everything else (general Sugar improvements, frameworks, or activities) should go in Sugarlabs. We discussed this at XO camp, and people from Sugar Labs were considering not supporting activity development and focusing on core sugar development. This is correct. Has this changed? In general, do you expect that priorities for toolchain and activity development will be the same? In general, sugar-core and toolchain development is a higher priority than generative Activity development (Activities that lower the barrier to Activity development). It's highly unlikely that non-generative Activity development will be supported. Honestly, this is news to me. (and I am the co-administrator of the Sugarlabs program). If I had to articulate my view of our priorities, it would be something like the following: 7-10 points: Key sugar core improvements. Long-standing, important gaps like versioning or unit-tests at the high end of this. 6-9 points: Activity frameworks to open new forms of activity development (in descending priority: javascript/AJAX, swf, improved PyGTK tools such as Develop activity, mono or java) 4-8 points: Core activities: For instance, Nepal has expressed the need for an improved Read. 3-6 points: Quality non-core educational activities: a physics sim or other creative idea. 0-8 points: Proposal quality. In other words, an excellent proposal from a highly-qualified student could very well make the cut, even if it were a non-core activity. Jameson (whose daughter likes colors) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Google summer of Code?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jameson Quinn wrote: Honestly, this is news to me. (and I am the co-administrator of the Sugarlabs program). If I had to articulate my view of our priorities, it would be something like the following: 7-10 points: Key sugar core improvements. Long-standing, important gaps like versioning or unit-tests at the high end of this. As others have pointed out many times, the SoC projects that are least likely to produce useful results are the ones that are the most ambitious. In particular, it is difficult to find SoC applicants who are ready to make deep modifications to an existing codebase, or will be able to architect complex software. Remember, SoC applicants are mostly current undergrads, so most have never participated in multi-person development effort, or written anything larger than 1000 lines. 0-8 points: Proposal quality. Maybe this problem is wrapped up in Proposal quality. If I were designing a system to reflect my own internal judgment structure, I would probably add another /multiplying/ factor, the estimated probability of success (although I hope we can do selection without resorting to numerical scores.) - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkm6XnQACgkQUJT6e6HFtqSlrACgjuswY+/aYXWkfaTY3DZcls/l gLcAnRP4Rn7tGfuQoiipzFtXQfEHP1g4 =Z92W -END PGP SIGNATURE- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Removing perl from the build
As another follow up to this the gnome-python2-evince package (needed from sugar-read) incorrectly required evince-devel which in turn pulls in a chunk of the devel stack plus perl, I've filed RH bug 490112 to get this fixed so hopefully it should be done before too long. If you think its work doing quickly it might be worthwhile adding it to the F11Beta tracker. Continuing the thread by talking to myself. This has been fixed and I've asked if we can get it tagged into the F11 beta. Peter ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Google summer of Code?
On Fri, Mar 13, 2009 at 7:24 AM, Benjamin M. Schwartz bmsch...@fas.harvard.edu wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jameson Quinn wrote: Honestly, this is news to me. (and I am the co-administrator of the Sugarlabs program). If I had to articulate my view of our priorities, it would be something like the following: 7-10 points: Key sugar core improvements. Long-standing, important gaps like versioning or unit-tests at the high end of this. As others have pointed out many times, the SoC projects that are least likely to produce useful results are the ones that are the most ambitious. In particular, it is difficult to find SoC applicants who are ready to make deep modifications to an existing codebase, or will be able to architect complex software. Remember, SoC applicants are mostly current undergrads, so most have never participated in multi-person development effort, or written anything larger than 1000 lines. Agreed. However, I think that a relatively-skilled GSoC student could take on one of the tasks I mentioned. Versioning could build on CScott's OLPCFS2, which AFAIK works remarkably well; it really only needs an interface and maybe a converter. Unit tests require a harness (and Sugarbot already exists) and a couple of demo self-tests of the harness; the tests themselves would be a separate story. Yet it is true, both of these would still be ambitious, and would probably be scored down because of it. 0-8 points: Proposal quality. Maybe this problem is wrapped up in Proposal quality. If I were designing a system to reflect my own internal judgment structure, I would probably add another /multiplying/ factor, the estimated probability of success (although I hope we can do selection without resorting to numerical scores.) I agree. The numbers are only a way of communicating, not a proposed system for choosing. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
2PM EDT Friday: BRIEF Contributors Program Mtg (#olpc-meeting)
Contributor Program v2.0 is off to a Great start this month, thanks to So Many of You, including: * almost 15 active (dare I saw AWESOME) Mentors * several Laptop Lending Libraries Right Now getting underway this month in Australia, New Zealand beyond * a far more accessible reviewing process volunteers are increasingly helping me roll out (you know who you are, thank Mafe all!!) Join us reviewing the latest OLPC/Sugar community projects today 2PM EDT in just over an hour from now: http://forum.laptop.org/chat Then type at bottom: /join #olpc-meeting 1. We'll review these 4 new projects: NLP tools for OLPC, Meaning to Word Multi-lingual Dictionary by Ervin [ALBANIA] http://rt.laptop.org/Ticket/Display.html?id=35617 PROJECT i-TEACH, Philippines by Emmanuel [PHILIPPINES] http://rt.laptop.org/Ticket/Display.html?id=35665 OLPC Jericho by Sebastian [WEST BANK, PALESTINIAN TERRITORY, ISRAEL, GERMANY, SWITZERLAND] http://rt.laptop.org/Ticket/Display.html?id=35743 Ghana olpc by Eric [GHANA] http://rt.laptop.org/Ticket/Display.html?id=35942 (*) site passworded to protect personal privacy of applicants; if you can help, please do join http://wiki.laptop.org/go/Support_Gang ! NEW: Project summaries of pre-approved projects will soon be posted here, as they bubble up to maturity: http://wiki.laptop.org/go/Projects 2. Revising Prior Proposals Integrate CRM Web form using XO by benbas [MALAYSIA] http://rt.laptop.org/Ticket/Display.html?id=35391 Loan Laptop to students and lecturers by benbas [MALAYSIA] http://rt.laptop.org/Ticket/Display.html?id=35393 AND OTHERS! http://rt.laptop.org/Search/Results.html?Query=Queue=%27contributors%27 3. Hone our Mentoring Process! * Our Science fair garden is growing fast for springtime, watch (and help!) /many/ ongoing inspiring changes Hullaw others sparking here --* help all worthy projects past/present/future take root!* http://wiki.laptop.org/go/Projects * Application process clarified regarding privacy/sharing options -- Title, Objectives, and Mentor Preferences must be web-published: http://wiki.laptop.org/go/Contributors_program/Project_proposal_form * Build Awareness around our new: http://wiki.laptop.org/go/Contributors * Mentor More Projects-- Help Us Resolve several dozen Project Proposals dating from 2008: http://rt.laptop.org/Search/Results.html?Query=Queue=%27contributors%27 * Keep stress-testing our new CP v2.0 to make sure it continues to scale** * Craft RTFM's and email to all older/ongoing projects asking them how it's going, how we can help! * Craft email to the many who registered over the last year expecting hardware, but failed to to complete the 2nd step applying :( 4. Projecting Futurism * Several Laptop Lending Libraries are Right Now getting underway. Help us provide them the best ideas towards organic growth (Project Pools) by commenting here: http://wiki.laptop.org/go/Contributors_program_criteria * Contributors Program v3.0 arising springtime? http://wiki.laptop.org/go/Support_meetings/20090301#Agenda_Item_2:_Contributors_Program.2B.2B.3B_Radical_Overhaul_Advances * Your Other Questions! ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
announce: alternate power management
hi --
i had an itch that needed scratching, and the result is a
reimplementation of much (but not all) of what ohmd does
currently.
i've thought for some time (and i believe cjb agrees) that ohmd
is needlessly difficult to maintain and modify for our purposes
on the XO. small improvements are difficult to implement
quickly.
since my heart is with more quasi-embedded systems than the XO's
current incarnation, part of my goal was to do a rewrite which
was not dependent on hald, dbus, or X11 -- power management
should work well from a console screen, and be available even if
none of those services is running.
i call the service i wrote powerd. it gets user idle/active
reports from the olpc-kbdshim daemon (which is watching all
user keypress and touchpad activity in any case), and it gets
reports regarding the hardware inputs (power button, lid and
ebook switches, ac adapter status, battery level, etc) either
from another small daemon that monitors /dev/input/event{0,1,2},
or from /sys nodes directly.
it basically recreates ohmd's dim after a bit, then sleep
behavior, with some additions:
- a power button splash screen: a second press of the power
button invokes shutdown, simply waiting for a brief timeout
invokes suspend, and any user activity cancels. (i even
managed to kinda sorta convey all that with graphics. i'm
sure every UI person that sees it will roll their eyes.)
- configurable timeouts for screen dim and sleep. the dim
level is configurable.
- different power management behavior when on wall power vs.
battery -- many laptop owners don't need to be miserly with
power when running from an external source. powerd makes
this behavior selectable.
- different power behavior when in ebook mode (though detection
may be unreliable -- i think the ebook switch suffers from
some issues we previously noticed with the lid switch). this
should let you configure things like a very short timeout until
idle-suspend, and/or no screen dimming, when in ebook mode. (i
find the frequent on/off nature of the backlight when reading
in ebook mode to be a distraction.)
- clean shutdown on critically low battery. (currently set at
a reported 5%, at which point my laptop would only run for
another couple of minutes.)
- the ability to run arbitrary scripts after a resume. (perhaps
to reinit usb devices that don't suspend/resume properly? haven't
used this much yet.)
- ease of customization, given that it's written in everyone's
favorite interpreted language.
unimplemented:
- inhibiting idle suspend based on system or network load.
i.e., the system will dim or suspend when watching a video.
(there are hooks in place where these features should be
implemented -- they're just not coded at all.) there's
no /etc/ohmd directory, so it honors /var/run/inhibit-idle-suspend
instead.
- no special support for the wireless mesh, whatsoever. i
couldn't remember how it was supposed to work, and i recall
cjb saying it's hard to figure out whether the mesh is active
or not.
- there's some support for wake-on-wlan, but it's not well tested.
finally a big one:
- proper support for USB keyboards and mice. i recently
realized that since olpc-kbdshim only monitors the built-in
keyboard and touchpad, powerd will think the user is idle
while they type on a USB keyboard, and cheerfully suspend
regardless. (in my case, most of the time i want to
auto-suspend is when i'm running on battery, and not using
external devices, so i sort of forgot about this case.)
anyway, code is available here:
http://dev.laptop.org/git/users/pgf/powerd/
and rpms are here:
http://dev.laptop.org/~pgf/rpms/
you'll need to install both olpc-kbdshim and olpc-powerd (in that
order). when installed, olpc-powerd disables ohmd, and reenables
it when uninstalled. (so it's relatively safe to try.)
there's no gui or other convenience for configuration --
see/etc/powerd/powerd.conf. the installed defaults should be
reasonable. and you'll need to run:
echo reconfig /var/run/powerevents
after making changes to the config file.
paul
=-
paul fox, p...@laptop.org
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] announce: alternate power management
Very cool!
How well will this integrate with the power management systems other
distros are using? Can it become a 'Value Added' for other netbook
manufacturers?
david
On Fri, Mar 13, 2009 at 4:33 PM, p...@laptop.org wrote:
hi --
i had an itch that needed scratching, and the result is a
reimplementation of much (but not all) of what ohmd does
currently.
i've thought for some time (and i believe cjb agrees) that ohmd
is needlessly difficult to maintain and modify for our purposes
on the XO. small improvements are difficult to implement
quickly.
since my heart is with more quasi-embedded systems than the XO's
current incarnation, part of my goal was to do a rewrite which
was not dependent on hald, dbus, or X11 -- power management
should work well from a console screen, and be available even if
none of those services is running.
i call the service i wrote powerd. it gets user idle/active
reports from the olpc-kbdshim daemon (which is watching all
user keypress and touchpad activity in any case), and it gets
reports regarding the hardware inputs (power button, lid and
ebook switches, ac adapter status, battery level, etc) either
from another small daemon that monitors /dev/input/event{0,1,2},
or from /sys nodes directly.
it basically recreates ohmd's dim after a bit, then sleep
behavior, with some additions:
- a power button splash screen: a second press of the power
button invokes shutdown, simply waiting for a brief timeout
invokes suspend, and any user activity cancels. (i even
managed to kinda sorta convey all that with graphics. i'm
sure every UI person that sees it will roll their eyes.)
- configurable timeouts for screen dim and sleep. the dim
level is configurable.
- different power management behavior when on wall power vs.
battery -- many laptop owners don't need to be miserly with
power when running from an external source. powerd makes
this behavior selectable.
- different power behavior when in ebook mode (though detection
may be unreliable -- i think the ebook switch suffers from
some issues we previously noticed with the lid switch). this
should let you configure things like a very short timeout until
idle-suspend, and/or no screen dimming, when in ebook mode. (i
find the frequent on/off nature of the backlight when reading
in ebook mode to be a distraction.)
- clean shutdown on critically low battery. (currently set at
a reported 5%, at which point my laptop would only run for
another couple of minutes.)
- the ability to run arbitrary scripts after a resume. (perhaps
to reinit usb devices that don't suspend/resume properly? haven't
used this much yet.)
- ease of customization, given that it's written in everyone's
favorite interpreted language.
unimplemented:
- inhibiting idle suspend based on system or network load.
i.e., the system will dim or suspend when watching a video.
(there are hooks in place where these features should be
implemented -- they're just not coded at all.) there's
no /etc/ohmd directory, so it honors /var/run/inhibit-idle-suspend
instead.
- no special support for the wireless mesh, whatsoever. i
couldn't remember how it was supposed to work, and i recall
cjb saying it's hard to figure out whether the mesh is active
or not.
- there's some support for wake-on-wlan, but it's not well tested.
finally a big one:
- proper support for USB keyboards and mice. i recently
realized that since olpc-kbdshim only monitors the built-in
keyboard and touchpad, powerd will think the user is idle
while they type on a USB keyboard, and cheerfully suspend
regardless. (in my case, most of the time i want to
auto-suspend is when i'm running on battery, and not using
external devices, so i sort of forgot about this case.)
anyway, code is available here:
http://dev.laptop.org/git/users/pgf/powerd/
and rpms are here:
http://dev.laptop.org/~pgf/rpms/
you'll need to install both olpc-kbdshim and olpc-powerd (in that
order). when installed, olpc-powerd disables ohmd, and reenables
it when uninstalled. (so it's relatively safe to try.)
there's no gui or other convenience for configuration --
see/etc/powerd/powerd.conf. the installed defaults should be
reasonable. and you'll need to run:
echo reconfig /var/run/powerevents
after making changes to the config file.
paul
=-
paul fox, p...@laptop.org
___
Sugar-devel mailing list
sugar-de...@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] announce: alternate power management
david wrote:
Very cool!
How well will this integrate with the power management systems other
distros are using? Can it become a 'Value Added' for other netbook
manufacturers?
while i'd love to say i did a lot of research and prep in order
to make sure my little project was api compliant and future
compatible with other power management systems, i can't say that.
my goal's were small: to produce a lighter weight skeleton on
which to hang XO power management, in order to reduce the effort
needed to add some small features (that i wanted) to the current
functionality, and to make sure it was distro, desktop, and UI
independent. (i also wanted to prove to myself that it could
really be done the way i was picturing it).
paul
david
On Fri, Mar 13, 2009 at 4:33 PM, p...@laptop.org wrote:
hi --
i had an itch that needed scratching, and the result is a
reimplementation of much (but not all) of what ohmd does
currently.
i've thought for some time (and i believe cjb agrees) that ohmd
is needlessly difficult to maintain and modify for our purposes
on the XO. Â small improvements are difficult to implement
quickly.
since my heart is with more quasi-embedded systems than the XO's
current incarnation, part of my goal was to do a rewrite which
was not dependent on hald, dbus, or X11 -- power management
should work well from a console screen, and be available even if
none of those services is running.
i call the service i wrote powerd. Â it gets user idle/active
reports from the olpc-kbdshim daemon (which is watching all
user keypress and touchpad activity in any case), and it gets
reports regarding the hardware inputs (power button, lid and
ebook switches, ac adapter status, battery level, etc) either
from another small daemon that monitors /dev/input/event{0,1,2},
or from /sys nodes directly.
it basically recreates ohmd's dim after a bit, then sleep
behavior, with some additions:
 - a power button splash screen:  a second press of the power
  button invokes shutdown, simply waiting for a brief timeout
  invokes suspend, and any user activity cancels.  (i even
  managed to kinda sorta convey all that with graphics.  i'm
  sure every UI person that sees it will roll their eyes.)
 - configurable timeouts for screen dim and sleep.  the dim
  level is configurable.
 - different power management behavior when on wall power vs.
  battery -- many laptop owners don't need to be miserly with
  power when running from an external source.  powerd makes
  this behavior selectable.
 - different power behavior when in ebook mode (though detection
  may be unreliable -- i think the ebook switch suffers from
  some issues we previously noticed with the lid switch).  this
  should let you configure things like a very short timeout until
  idle-suspend, and/or no screen dimming, when in ebook mode.  (i
  find the frequent on/off nature of the backlight when reading
  in ebook mode to be a distraction.)
 - clean shutdown on critically low battery.  (currently set at
  a reported 5%, at which point my laptop would only run for
  another couple of minutes.)
 - the ability to run arbitrary scripts after a resume.  (perhaps
  to reinit usb devices that don't suspend/resume properly?  haven't
  used this much yet.)
 - ease of customization, given that it's written in everyone's
  favorite interpreted language.
 unimplemented:
 - inhibiting idle suspend based on system or network load.
  i.e., the system will dim or suspend when watching a video.
  (there are hooks in place where these features should be
  implemented -- they're just not coded at all.)  there's
  no /etc/ohmd directory, so it honors /var/run/inhibit-idle-suspend
  instead.
 - no special support for the wireless mesh, whatsoever.  i
  couldn't remember how it was supposed to work, and i recall
  cjb saying it's hard to figure out whether the mesh is active
  or not.
 - there's some support for wake-on-wlan, but it's not well tested.
 finally a big one:
 - proper support for USB keyboards and mice.  i recently
  realized that since olpc-kbdshim only monitors the built-in
  keyboard and touchpad, powerd will think the user is idle
  while they type on a USB keyboard, and cheerfully suspend
  regardless.  (in my case, most of the time i want to
  auto-suspend is when i'm running on battery, and not using
  external devices, so i sort of forgot about this case.)
anyway, code is available here:
  http://dev.laptop.org/git/users/pgf/powerd/
and rpms are here:
  http://dev.laptop.org/~pgf/rpms/
you'll need to install both olpc-kbdshim and olpc-powerd
Re: [Olpc-france] extend the memory flash space with an SD card to build open80211s
p...@laptop.org a écrit : rekik wrote: Hi, I tried to build the kernel open80211s on a group of machines which use ubuntu 8.10 and it's work. Now I had to build it on an XO. The problem is that I don't have enough space on my flash memory ( 1Go ). So, I had to extend it with an SD card ( to have a space 1024 Mo), but I don't know the steps to make this solution and the minimum size of the SD card.. can anyone help me !!! it sounds like you're trying to do the build of open80211s on the XO itself. most people don't do development for the XO that way -- we build on another machine, and move the binaries onto the XO. for simple programs, you can build on most any modern linux distribution and your binary will work on the XO, because the libraries and environment tend to be compatible. (you could perhaps build a static binary to be sure.) the XO is based on fedora, so a fedora machine will be the best build host. Yes, but debian can also run on XO. However I found http://wiki.laptop.org/go/Ubuntu_On_OLPC_XO not good because it puts the fedora kernel on the ubuntu which works with some discrepencies ; it takes also some time because of qemu and the boot is not optimal. Today, the stuff with debian on XO is cleaner and very fast to install and test ; http://wiki.laptop.org/go/DebXO is the best page I found about it : # zcat debxo-$DESKTOP.ext3.img.gz /dev/sdX (for instance, sdb; not sdb1) And update the firmware to q2e34.rom at http://dev.laptop.org/pub/firmware/ Then it works fine either on SD card or USB pendrive of 2 GB minimum and you can still boot and use the native fedora XO build. With SD cards you could need some swap that can be made with a file /swap.bin as explained at http://www.olpcnews.com/forum/index.php?topic=4053.0 However, I have to compile a more recent kernel because the 2.6.25 version on that debian lenny is not sufficient for some of my experiments. With all the wiki documentation pages I don't know on which I should write. Regards Aimé paul =- paul fox, p...@laptop.org ___ Olpc-france mailing list olpc-fra...@lists.laptop.org http://lists.laptop.org/listinfo/olpc-france signature.asc Description: OpenPGP digital signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Olpc-france] extend the memory flash space with an SD card to build open80211s
On Fri, Mar 13, 2009 at 07:27:47PM +0100, Aime Vareille wrote: However I found http://wiki.laptop.org/go/Ubuntu_On_OLPC_XO not good because it puts the fedora kernel on the ubuntu which works with some discrepencies ; it takes also some time because of qemu and the boot is not optimal. Fedora and Ubuntu use the same upstream source for the kernel. What are these discrepencies, and why aren't they fixed? -- James Cameronmailto:qu...@us.netrek.org http://quozl.netrek.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Olpc-france] extend the memory flash space with an SD card to build open80211s
look at using debxo to give you a debian install on the XO David Langp...@laptop.org a écrit : rekik wrote: Hi, I tried to build the kernel open80211s on a group of machines which use ubuntu 8.10 and it's work. Now I had to build it on an XO. The problem is that I don't have enough space on my flash memory ( 1Go ). So, I had to extend it with an SD card ( to have a space 1024 Mo), but I don't know the steps to make this solution and the minimum size of the SD card.. can anyone help me !!! it sounds like you're trying to do the build of open80211s on the XO itself. most people don't do development for the XO that way -- we build on another machine, and move the binaries onto the XO. for simple programs, you can build on most any modern linux distribution and your binary will work on the XO, because the libraries and environment tend to be compatible. (you could perhaps build a static binary to be sure.) the XO is based on fedora, so a fedora machine will be the best build host. Yes, but debian can also run on XO. However I found http://wiki.laptop.org/go/Ubuntu_On_OLPC_XO not good because it puts the fedora kernel on the ubuntu which works with some discrepencies ; it takes also some time because of qemu and the boot is not optimal. Today, the stuff with debian on XO is cleaner and very fast to install and test ; http://wiki.laptop.org/go/DebXO is the best page I found about it : # zcat debxo-$DESKTOP.ext3.img.gz /dev/sdX (for instance, sdb; not sdb1) And update the firmware to q2e34.rom at http://dev.laptop.org/pub/firmware/ Then it works fine either on SD card or USB pendrive of 2 GB minimum and you can still boot and use the native fedora XO build. With SD cards you could need some swap that can be made with a file /swap.bin as explained at http://www.olpcnews.com/forum/index.php?topic=4053.0 However, I have to compile a more recent kernel because the 2.6.25 version on that debian lenny is not sufficient for some of my experiments. With all the wiki documentation pages I don't know on which I should write. Regards Aimé paul =- paul fox, p...@laptop.org ___ Olpc-france mailing list olpc-fra...@lists.laptop.org http://lists.laptop.org/listinfo/olpc-france signature.asc Description: OpenPGP digital signature ___ 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: announce: alternate power management
configurable timeouts for screen dim and sleep. the dim level is configurable. My XO systems are plugged in to the AC, so I normally leave them running 24/7. But in the middle of the night if I happen to walk by, I notice if they are acting as light sources. Two concerns (for which I don't know whether doing anything is feasible): - Rawhide. AFAIK there currently is no dimming support at all. I either have to power off such an XO overnight, or have to close the lid while the backlight is still lit. It would be useful if rawhide supported dimming/shutting_off the screen when no one is looking at it (irrespective of whether the CPU is doing work or not). - Suspend. It was functioning well only with Joyride - but I hope it gets implemented other places as well. The problem is - the CPU may suspend because it is idle (and partly dim the screen), but the user may still continue looking at that screen (in color mode) while the XO is suspended. After a decent interval at half-bright, it is reasonable to assume the user has seen enough, and the screen could now be dimmed all the way off. BUT since the system is sleeping, the current implementation has no way to wake up the system just so it can execute 'screen dim' instructions. The result is that if I don't intervene at the keyboard, my suspended (Joyride) XO's screen remains half-bright throughout the night. I think it counter-productive to suspend the rest of the system (to save power!) when no one is using it, but to leave the screen lit (still drawing power!) once it can be presumed no one is using it any more. different power behavior when in ebook mode (though detection may be unreliable -- i think the ebook switch suffers from some issues we previously noticed with the lid switch). What issues ? I thought the lid switch could be fooled by people with magnets - but that an actual shut would always be recognized as being a shut (and a failure to recognize an open could be overcome by momentarily pressing the power button). mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
