re: [support-gang] spectacular new XO-1.5 disassembly guides
i've taken a lot of XO laptops apart, and i've almost _never_ found it necessary to remove the screen completely. the two ribbon connectors that connect the screen and the backlight have a limited lifetime and should not be opened and closed needlessly. unless you're planning on removing the motherboard, removing the screen is unnecessary. the screws that attach the back can be reached without remove the screen: - first remove the four screws attaching the screen. - lift the bottom of the screen to get access to the lower pair of screws holding the back. remove them. (you can see how this can be done in page 6 of the pdf. - _without_ undoing the screen's connectors, let the bottom edge of the screen drop down in order to get at the upper pair of screws that hold the back. you can see how this works on page 7 of the pdf. the screen's ribbon cables are just long enough for this to work. remove the second pair of screws that hold the back on. - now, before doing anything else, tuck the top edge of the screen back into position, and secure the screen with at at least one of the lower screws that hold it in place. this keeps it from flopping around while you remove the back. you can now remove the back, to get access to most connectors, the RTC battery, etc. paul holt wrote: Mafe Mago marife.m...@gmail.com wrote: Hi Folks, Just sharing this pdf file of Dissecting an XO 1.5 created by Peter Domanski who just been introduced to XO. http://wiki.laptop.org/go/File:XO_Disassembly_%28Bottom%29.pdf [20p, 1.7MB] http://wiki.laptop.org/go/File:XO_Disasembly_%28Top%29.pdf [33p, 4.1MB] Thanks Peter! -- Cheers, @marife mm...@ekindling.org http://www.ekindling.org http://wiki.laptop.org/go/ekindling http://wiki.laptop.org/go/OLPC_NYC Plz write to Mafe if you have suggested revisions, for her friend Peter if he has time! ___ support-gang mailing list support-g...@lists.laptop.org http://lists.laptop.org/listinfo/support-gang =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Suspend: RTC wakeup, sleep
oops. typo correction, below: i wrote: hal wrote: Can somebody give me a pointer to some sample code that will wake up a suspended system in 5 minutes? I'm assuming there is some way to do this using the alarm interrupt from the RTC. use: rtcwake -s 600 -m mem to wake the system in 600 seconds, after suspending it to S3. see the man page -- but other -m options work, including no, i i meant to write: ...but NO other -m options work, ... i should also point out that powerd uses rtcwake for its own purposes, so if you want exclusive control, you should disable it. paul believe. (although, if someone tries it and it does work, i'll stand corrected.) Can somebody confirm that sleep does what I expect on suspended systems? My expectation is that the sleep timer logically ticks when suspended, but that the system won't get woken up when the sleep timer expires. For example, suppose my program does a sleep(100), and shortly after that the system suspends. If the next wakeup is 200 seconds after the start of the sleep, my program should run then (along with whatever caused the wakeup). Or if the system wakes up after 50 seconds and doesn't suspend again, my program should run 100 seconds after it started to sleep. i'm afraid not. your sleep will be stretched by the duration of the suspend. see the following. a 30 second sleep starts at 15:42:41. the system suspends for 15 seconds, and wakes (that's where the +r gets printed) at 15:43:01 (2 seconds later than it expected to, btw). the sleep terminates, and prints sleep ended and the date at 15:43:25. that's roughly 45 seconds after the 30 second sleep started. [r...@xo-a7-2a-c8 dev]# touch /var/run/powerd-inhibit-suspend/1 [r...@xo-a7-2a-c8 dev]# (date; sleep 30; echo sleep ended; date) [2] 3122 Wed Jul 28 15:42:41 GMT 2010 [r...@xo-a7-2a-c8 dev]# rtcwake -s 15 -m mem; date rtcwake: assuming RTC uses UTC ... rtcwake: wakeup from mem using /dev/rtc0 at Wed Jul 28 15:42:59 2010 +rWed Jul 28 15:43:01 GMT 2010 [r...@xo-a7-2a-c8 dev]# sleep ended Wed Jul 28 15:43:25 GMT 2010 =- paul fox, p...@laptop.org =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Dead Production WLAN card
it seems i was mistaken. the card was disabled using gnome's nm-applet. paul i wrote: nate wrote: Looks like the ESD bug strikes again... http://wiki.laptop.org/go/XO1.5_WLAN_ESD_protection On Wed, May 19, 2010 at 6:54 PM, John Watlington w...@laptop.org wrote: On May 19, 2010, at 9:11 PM, Richard A. Smith wrote: I've got bad news from our tester in Canada. The production laptop we sent him has lost its wireless. It only took one trip in his backpack. In discussion with him a new piece of information was discovered. He is using the Network Manager wireless disable function prior to suspending the card. The wireless disable function is supposed to just turn off the power to the WLAN but perhaps it is the reason he is able to kill the WLAN so quickly. Does anyone do this on a regular basis to their XO-1.5 ? to be clear, the mechanism he was using wasn't via NM, but via the sugar network control panel Radio checkbox. (that checkbox is directly hooked up to the shell command rfkill un/block wifi.) paul =- paul fox, p...@laptop.org =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: resizing rootfs to fit the disk
i'm moving a discussion-in-progress to the devel list. as background: because XO-1.5 uses an internal micro-SD for mass storage, we don't know the exact size filesystem to create at image build time. not only do we ship laptops with (currently) 2G and 4G cards, but cards of a quoted size from different vendors vary in useable size (by quite a bit). so we currently build otherwise-identical 2G and 4G images, both undersized to accomodate vendor variations. we'd prefer not to have to do this -- it would make the builds easier, and would let users use any size card they'd like. thus far in our story: - several people think we should be trying to do a full filesystem resize at boot -- advantage is that we can ship a single image, and have it work on all SD cards. it would require a new 'please wait' splash screen (which should be a good one, with seamless transition -- this may be the first user experience), and adds some risk to the boot process. first linux boot happens at the factory for new laptops, but in the child's hands in most deployment scenarios (where nandblaster or usb sticks are used). - several people think we should separate the base OS from the user data, by giving /home a separate, variable, partition. we would then build images to match a fixed root fs size. would we size the root fs? having a hard constraint that we must fit into wouldn't be bad thing, as long as we don't pick an unreasonably small value, and as long as there's a fallback plan when we blow it. olpc-update may double the space requirement in the worst case, right? i've never used LVM -- could it help make the boundary moveable? - we could put resize-at-boot code in place (with or without a splash screen), and continue shipping multiple, somewhat undersized images. any image could be used on any bigger SD card, and the right thing would happen, but in the usual case where an image is correctly sized, the resize time wouldn't take too long. perhaps we could suppress the splash screen for resizes that we think won't take too long? - we could make the resizing a manual step, from the control panel or elsewhere. we sort of need a simple disk management screen anyway. (btw, regardless of our decision, this is clearly more than a simple bug fix.) paul =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
slow wiki?
anyone know why the olpc wiki is responding so slowly? every new page i load is taking a really long time. paul =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: How to get sugar config values without a console?
martin wrote:
I'm working on olpc-update-query, a script that runs without a tty
(from NM hooks and cron) and needs to query Sugar configuration stuff.
To make things more complicated, it runs as root :-/
It's a good thing that we have sugar-control-panel, but at least on
0.82 it doesn't work unless you're in Terminal. Strangely enough, it
tries to load gtk.
if you're root, use the force:
#!/bin/sh
get_x_credentials()
{
# fetch the local X server's XAUTHORITY variable
eval $( xargs -n 1 -0 /proc/$(pidof X)/environ | grep '^XAUTHORITY=')
export XAUTHORITY
export DISPLAY=:0
}
test $XAUTHORITY || get_x_credentials
sugar-control-panel -blah
=-
paul fox, p...@laptop.org
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: overhead in a G1G1 environment
mikus wrote: The default that comes with the OS causes the probabilities to come true about once per day. This can be changed by the theft deterrence server for future requests in the update part of the response. olpc-update-query is also called by cron every 15 minutes. I seem to remember with 8.2.x and earlier that, all too often, when I ran 'top' it would show 'olpc-update-query' using resources. My XO was gotten through G1G1, and I am not using it in any kind of a server environment. [Given the communications setup at my house, cron by itself does not even have the resources to successfully make a connection to the internet.] In that situation, is it truly necessary for 'olpc-update-query' to be run ? as i recall, there was/is a provision for OLPC to push (via that polling mechanism) updates to the g1g1 machines. i don't believe it's ever been turned on, and, in my opinion, is unlikely to be. so the answer is no, it's not necessary. paul =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: VGA questions
guylhem wrote: Hello On Sun, May 17, 2009 at 20:54, Bobby Powers bobbypow...@gmail.com wrote: on a B4 (which just needed the VGA connector, no other components), Same here. I have a spare B4 board for these tests (I would like to reproduce the identical picture of the XO on a projector for a formation - and I'm talking about openfirmare and all) I was able to drive full screen video on a large LCD from the XO, so its not useless That's just what I want to do. No internal LCD mirroring - plain VGA output only So far I've been stopped by : - the video routing question (CN18) - the plug. I would like to avoid soldering wires to a VGA plug. Soldering the plug should take less than 5 minutes once I get the correct type from digikey/mouser looking at an A-test board, the connector is a Suyin part (marking very tiny, on the front face). the back has a number 26147. looking at their website, it seems like it might be one of these: http://www.suyinusa.com/Parts%5CDesktop%5C070435FR015S2164U.pdf http://www.suyinusa.com/Parts%5CDesktop%5C070922FR015S201CY.pdf (i found these under All Desktop Connectors at http://www.suyinusa.com/all_products.asp ) i can't find the calipers right now, so i can't verify any dimensions from the technical drawings. i can do that, though. paul =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: ffreep support on Geode LX (XO-1)
noiseehc wrote: I have just tested it on my XO and the Geode DOES NOT support the ffreep instruction. It could explain the halting shutdown when it stalls with a signal 15 (which happens to be SIGILL) and only continuing it when I switch to the other console (as I reported in [1]). So fixing it and creating a 803 is absolutely necessary IMHO. [1] http://lists.laptop.org/pipermail/devel/2009-May/024356.html please file a ticket at dev.laptop.org, with details on how to reproduce the ffreep issue using build 802. (if it's only reproducible with debxo (unclear from what's been written so far), then the priority (and the fix) will likely be very different.) the failure to switch to the UL-warning screen during shutdown is a secondary effect of whatever it is you're seeing, and if reproducible should have a second ticket filed. paul Sascha Silbe wrote: Hi! While trying to use sugar-jhbuild on DebXO (Debian on XO-1), I encountered several programs that crashed with SIGILL, apparently during execution of ffreep. While the AMD Athlon Processor x86 Code Optimization Guide [1] claims that although insufficiently documented in the past, [ffreep] is supported by all 32-bit x86 processors, the AMD Geode LX datasheet [2] doesn't list ffreep. As ffreep was added to gcc 3.4 [3] and Build 801 seems to use 4.3.0, I'm wondering whether it has been patched/configured in some way to avoid this issue or whether the processor actually supports it and something else on my machine is broken. [1] http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/22007.pd f [2] http://www.amd.com/files/connectivitysolutions/geode/geode_lx/33234d_lx_ds.pdf [3] http://gcc.gnu.org/ml/gcc-patches/2002-11/msg01386.html CU Sascha =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: ffreep support on Geode LX (XO-1)
daniel wrote: 2009/5/7 NoiseEHC noise...@freemail.hu: please file a ticket at dev.laptop.org, with details on how to reproduce the ffreep issue using build 802. (if it's only reproducible with debxo (unclear from what's been written so far), then the priority (and the fix) will likely be very different.) I cannot reproduce it reliably so I do not know what should I file as a bug. What I have seen with 800 (months ago) can be seen here: http://wiki.laptop.org/go/Image:Xo_freeze_on_shutdown.png I think that it is sure that at least some parts of the 80x versions contain some code compiled with illegal instructions. I'm pretty sure the shutdown freeze (which can be unfrozen by using ctrl+alt+f1/f2 to change terminals) is totally unrelated to any instruction problems. I am pretty sure I have an explanation of the shutdown freeze, it's a race that occurs when 2 processes try to chvt at the same time (the 2 processes being X as it terminates and moves to the console, and ul-warning as it tries to move to the graphical terminal). Examining chvt source code makes it pretty obvious why this might happen... The switch process is actually switch-and-wait, performed by 2 separate ioctls, and hence is not atomic. I tried adding appropriate diagnostics once but this occurs frustratingly rarely that I never got to see if my theory is correct. i think you're exactly right -- the fact that ul-warning completes when you manually switch screens is pretty convincing. i'm amazed the vt system has never grown a new api of some sort to fix this problem. because powerd puts up an additional shutdown splash screen prior to the ul-warning screen, the sequencing is perturbed, and i see it (the race) more often. i think we should apply the bandaid of a retry to the chvt code -- i.e., add a timeout to the wait, and retry (or, at the very least, exit) if it expires. i actually went in to make the code changes the other day, but i backed off when i realized the source was in pyrex, not C. i realized i wasn't sure i'd be able to do the signal handling successfully (in the time i'd allotted myself, at any rate). paul Daniel =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Ambient light sensing via LED response
john wrote: By the way, has anyone really thought about this feature ? I grok the intent, but you have to make sure that kids who happen to be in brightly lit rooms (glaring fluourescents aren't uncommon) don't loose their backlight, and wonder why ? The keyboard lighting on my mac is a good idea, but they only allow adjusting the amount of light output, not the sensitivity to ambient light. i've been wondering about usage, as well. we had a dedicated light sensor on the last product i worked on (which, in retrospect, given that it had 15 watts (!) of backlight seems like maybe the wrong place to have started trying to save power ;-). i implemented a proof-of-concept algorithm for automatic control, but found it a little weird -- it always felt like there was something wrong with the backlight as it shifted up and down in brightness, even with a fair amount of averaging and/or delay. plus we never resolved how it should interact with the actual brightness buttons. after all, if you adjust manually, you're probably unhappy with the setting that was chosen automatically. so should manual control abort any automatic algorithm? or maybe the buttons should tune the algorithm? how? i'm suspect there are answers to all of these, but one of the feature's champions should be thinking about it... (in the end we never finished or released the photosensor support, because it turned out the usage pattern of the device (an automotive diagnostic tool) meant it was almost always fully powered, either from the wall or the vehicle it was troubleshooting.) paul =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Fixing bash script bogosity - help?
bert wrote:
On 28.04.2009, at 13:37, Martin Langhoff wrote:
On Tue, Apr 28, 2009 at 1:19 PM, Ignacio Vazquez-Abrams
ivazquez...@gmail.com wrote:
Ah, I see now.
Try this:
bash -c 'touch $@' ${c...@]}
Riiight, that works better... but
Or in the case of the full script:
bash -c $ERL' $@' ${erl_comma...@]}
...it doesn't work for runuser -- which is the real target. Runuser
looks at the added params after -c and tries to parse them. There
doesn't seem to be any support for passing parameters.
hm.
Maybe you should use su directly instead of runuser?
won't that have the same problem? it still wants a command
passed via a -c STRING convention.
i think this is somewhat intractable, and any time spent on it
would be better spent creating a patch to runuser that lets it
take its command as strace does, or as xterm does with -e, which
avoids the vector-string-vector translations which are the real
issue.
paul
=-
paul fox, p...@laptop.org
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: Fixing bash script bogosity - help?
bert wrote:
On 28.04.2009, at 14:27, p...@laptop.org wrote:
bert wrote:
On 28.04.2009, at 13:37, Martin Langhoff wrote:
On Tue, Apr 28, 2009 at 1:19 PM, Ignacio Vazquez-Abrams
ivazquez...@gmail.com wrote:
Ah, I see now.
Try this:
bash -c 'touch $@' ${c...@]}
Riiight, that works better... but
Or in the case of the full script:
bash -c $ERL' $@' ${erl_comma...@]}
...it doesn't work for runuser -- which is the real target. Runuser
looks at the added params after -c and tries to parse them. There
doesn't seem to be any support for passing parameters.
hm.
Maybe you should use su directly instead of runuser?
won't that have the same problem? it still wants a command
passed via a -c STRING convention.
i think this is somewhat intractable, and any time spent on it
would be better spent creating a patch to runuser that lets it
take its command as strace does, or as xterm does with -e, which
avoids the vector-string-vector translations which are the real
issue.
No, su passes all arguments after -c to the program you specify.
can you give an example?
$ su root -c /bin/echo one two three
Password:
$ su root -c '/bin/echo one two three'
Password:
one two three
$
paul
=-
paul fox, p...@laptop.org
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: Fixing bash script bogosity - help?
bert wrote: On 28.04.2009, at 15:09, p...@laptop.org wrote: bert wrote: On 28.04.2009, at 14:27, p...@laptop.org wrote: bert wrote: Maybe you should use su directly instead of runuser? won't that have the same problem? it still wants a command passed via a -c STRING convention. i think this is somewhat intractable, and any time spent on it would be better spent creating a patch to runuser that lets it take its command as strace does, or as xterm does with -e, which avoids the vector-string-vector translations which are the real issue. No, su passes all arguments after -c to the program you specify. can you give an example? $ su root -c /bin/echo one two three Password: $ su root -c '/bin/echo one two three' Password: one two three $ It's not a problem in su but in bash. See man bash: -c string If the -c option is present, then commands are read from string. If there are arguments after the string, they are assigned to the positional parameters, starting with $0. Note it starts with $0 not $1. So this works: $ su root -c '/bin/echo $@' /bin/echo one two three thanks -- i'd never seen that done before. (and it certainly wasn't possible with the original shells.) whenever someone teaches me something like that, i always wonder how long ago i missed the memo announcing the new feature. :-) martin: switch from runuser to su, just like bert said. :-) paul =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Fixing bash script bogosity - help?
martin wrote: On Tue, Apr 28, 2009 at 4:30 PM, Martin Langhoff martin.langh...@gmail.com wrote: On Tue, Apr 28, 2009 at 3:28 PM, Bert Freudenberg b...@freudenbergs.de wrote: $ su root -c '/bin/echo $@' /bin/echo one two three Interesting - seems to work as runuser root -c '/bin/touch $@' /bin/touch one two thre\ee but for some reason it doesn't work on my script. Any ideas on how to apply this to the runuser line on the ejabberdctl script? The plot thickens. Both sudo and runuser do pass parameters to the shell, but no parameter that looks like an option is accepted. So # this works runuser root -c '/bin/touch $@' /bin/touch one two thre\ee # this does not work - runuser root -c '/bin/touch $@' /bin/touch one two -d but this does: $ su root -c '/bin/touch $@' -- /bin/touch one two -d Password: /bin/touch: option requires an argument -- 'd' is there a reason to use runuser? it doesn't look like it's being used for anything su can't handle. paul =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Server-devel] Fixing bash script bogosity - help?
andrew wrote:
On Tue, 2009-04-28 at 23:25 +1200, Andrew McMillan wrote:
Hi Martin,
Perhaps:
=
#!/bin/bash -x
[ -n $DEBUG ] set -o xtrace
declare -a inparms
declare -i i=0
while true; do
inparms[$i]=${1/\/\\\}
Sorry, that should have read:
inparms[$i]=${1//\/\\\}
so that all instances of were replaced by \, rather than just the
first one :-)
i went down a similar path and even sent martin a modified
version of his script before realizing the general case is much
worse than that. you have to deal with escaping existing
backslashes, and single quotes, and i think all of the other
special shell characters as well.
the one bright spot of the exercise (if you can call it that) was
that in re-learing the pattern subustitution thing, i found that
you can do that ugly hack pattern replacement without the
surrounding loop, because it can be applied to all elements of an
array at once:
newARGS=( ${ar...@]//\/\\\} )
small pleasures, i know.
(i didn't retest that, but it's close.)
paul
Cheers,
Andrew.
shift || break
i=$(( $i + 1 ))
done
printargs() {
local -i j=0
while [ $j -lt $i ] ; do
printf ' %s' ${inparms[$j]}
j=$(( $j + 1 ))
done
}
# in the script, the CMD is built up as a string
CMD=touch `printargs`
# in practice we somtimes use /sbin/runuser -c
# and other times plain bash -c
bash -c $CMD
=
Line 9 is an ugly hack, and quite possibly a bashism.
Hope this is some use,
Andrew McMillan.
On Mon, 2009-04-27 at 22:37 +0200, Martin Langhoff wrote:
Hi all,
I have a simple shell scripting problem :-) you'll find attached a
shell script that ships with ejabberd. It is a fairly straightforward
bit of code, and allows us to control bits of the ejabberd internals
with a nice cli interface. (Feel free to skip the start / stop bits of
the code, I'm fighting with the ctrl function.)
The problem it has is that the parameters are passed to a bash or
runas invocation -- at which point the quoting is a mess. Currently I
am working around it in the caller by doing some stupid
nested-quoting. But this should be easy to cure -- if anyone knows a
bit more bash (or portable shell!) than me :-)
A minimal exposition of the problem is as follows:
$ cat sample.sh
#!/bin/bash -x
# in the script, the CMD is built up as a string
CMD=touch $@
# in practice we somtimes use /sbin/runuser -c
# and other times plain bash -c
bash -c $CMD
# this invokation does the wrong thing -
$ ./sample.sh ./sample.sh this is file one this is file two
# the ugly workaround is
./sample.sh 'this is file one' 'this is file two'
Any hints that don't involve a rewrite?
cheers,
martin-who's-easily-stumped-with-shell-backwardnesss
andrew (AT) morphoss (DOT) com+64(272)DEBIAN
You will be awarded a medal for disregarding safety in saving someone.
___
Server-devel mailing list
server-de...@lists.laptop.org
http://lists.laptop.org/listinfo/server-devel
andrew (AT) morphoss (DOT) com+64(272)DEBIAN
You have the power to influence all with whom you come in contact.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
=-
paul fox, p...@laptop.org
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: [Server-devel] Fixing bash script bogosity - help?
bert wrote:
On 28.04.2009, at 13:37, Martin Langhoff wrote:
On Tue, Apr 28, 2009 at 1:19 PM, Ignacio Vazquez-Abrams
ivazquez...@gmail.com wrote:
Ah, I see now.
Try this:
bash -c 'touch $@' ${c...@]}
Riiight, that works better... but
Or in the case of the full script:
bash -c $ERL' $@' ${erl_comma...@]}
...it doesn't work for runuser -- which is the real target. Runuser
looks at the added params after -c and tries to parse them. There
doesn't seem to be any support for passing parameters.
hm.
Maybe you should use su directly instead of runuser?
won't that have the same problem? it still wants a command
passed via a -c STRING convention.
i think this is somewhat intractable, and any time spent on it
would be better spent creating a patch to runuser that lets it
take its command as strace does, or as xterm does with -e, which
avoids the vector-string-vector translations which are the real
issue.
paul
=-
paul fox, p...@laptop.org
___
Server-devel mailing list
Server-devel@lists.laptop.org
http://lists.laptop.org/listinfo/server-devel
Re: CL1B power distribution
chris wrote: Hi, the most likely case i can think of involves being able to allow USB input devices to remain alive during suspend (for wakeup purposes), while powering down other devices (disks?) for power savings. Hm, I think the USB controller probably turns off by necessity in suspend, as it does on the Geode, so I don't think keeping power going to individual ports would achieve anything. perhaps i've been inferring something different than i should from wad's initial mail, which said: - The SD slot and USB ports may be powered in suspend This is just in case some SD cards or USB devices don't handle being suspended aggressively. We will support laptop wakeup on interrupt from any of these ports (SD or USB). Under software control they may also be powered down during suspend. paul =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Fixing bash script bogosity - help?
hi martin -- I have a simple shell scripting problem :-) you'll find attached a shell script that ships with ejabberd. It is a fairly straightforward bit of code, and allows us to control bits of the ejabberd internals with a nice cli interface. (Feel free to skip the start / stop bits of the code, I'm fighting with the ctrl function.) The problem it has is that the parameters are passed to a bash or runas invocation -- at which point the quoting is a mess. Currently I am working around it in the caller by doing some stupid nested-quoting. But this should be easy to cure -- if anyone knows a bit more bash (or portable shell!) than me :-) A minimal exposition of the problem is as follows: $ cat sample.sh #!/bin/bash -x # in the script, the CMD is built up as a string CMD=touch $@ # in practice we somtimes use /sbin/runuser -c # and other times plain bash -c bash -c $CMD first, you want to preserve the original quoting of the args by using $@. it must look just like that. second, you don't need the bash -c there. just run $CMD directly. so, the invocation you want is: CMD=touch $CMD $@ in your original script looks like this ERL_COMMAND=$ERL \ $NAME ejabberdctl \ -noinput \ -pa $EJABBERD_EBIN \ -s ejabberd_ctl -extra $ERLANG_NODE $@ \ W=`whoami` if [ $W != ejabberd ]; then /sbin/runuser -s /bin/bash - ejabberd -c $ERL_COMMAND result=$? else bash -c $ERL_COMMAND result=$? fi a) remove $@ from the ERL_COMMAND definition b) change the bash -c line to be: $ERL_COMMAND $@ c) to fix the runuser invocation (assuming it's broken, and i guess it probably is), i think will be trickier. i'm sure we can fix it though. how's this so far? paul =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Server-devel] Fixing bash script bogosity - help?
hi martin -- I have a simple shell scripting problem :-) you'll find attached a shell script that ships with ejabberd. It is a fairly straightforward bit of code, and allows us to control bits of the ejabberd internals with a nice cli interface. (Feel free to skip the start / stop bits of the code, I'm fighting with the ctrl function.) The problem it has is that the parameters are passed to a bash or runas invocation -- at which point the quoting is a mess. Currently I am working around it in the caller by doing some stupid nested-quoting. But this should be easy to cure -- if anyone knows a bit more bash (or portable shell!) than me :-) A minimal exposition of the problem is as follows: $ cat sample.sh #!/bin/bash -x # in the script, the CMD is built up as a string CMD=touch $@ # in practice we somtimes use /sbin/runuser -c # and other times plain bash -c bash -c $CMD first, you want to preserve the original quoting of the args by using $@. it must look just like that. second, you don't need the bash -c there. just run $CMD directly. so, the invocation you want is: CMD=touch $CMD $@ in your original script looks like this ERL_COMMAND=$ERL \ $NAME ejabberdctl \ -noinput \ -pa $EJABBERD_EBIN \ -s ejabberd_ctl -extra $ERLANG_NODE $@ \ W=`whoami` if [ $W != ejabberd ]; then /sbin/runuser -s /bin/bash - ejabberd -c $ERL_COMMAND result=$? else bash -c $ERL_COMMAND result=$? fi a) remove $@ from the ERL_COMMAND definition b) change the bash -c line to be: $ERL_COMMAND $@ c) to fix the runuser invocation (assuming it's broken, and i guess it probably is), i think will be trickier. i'm sure we can fix it though. how's this so far? paul =- paul fox, p...@laptop.org ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: CL1B power distribution
john wrote: Quick straw poll on how many people think it is useful enough have individual control over the power supplied to each connector to raise the cost of the laptop by $0.15 ? the most likely case i can think of involves being able to allow USB input devices to remain alive during suspend (for wakeup purposes), while powering down other devices (disks?) for power savings. but any use usage sounds complicated enough that the current all or none approach seems like it would cover most needs, and be relatively easy to manage: Leave USB devices powered on during idle suspend? yes/no paul =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: CL1B power distribution
smith wrote: Additional changes from Gen 1 include the ability to both measure DC input current and VIN voltage, as well as EC control over the current drawn from the DC input. The intent was to better support charging directly from solar panels. I hope that this will be available to activities like Measure. Interesting point. That would require extending the EC API, as they go to an A/D not directly addressable by the main processor. Ideally updates could be frequent enough to pick up a waveform from an unrectified power supply. (spare audio channel?) Don't have much in the way of EC cycles available. Don't have much EC ram left to cache values either. I can make the readings available via EC commands but each command takes a few ms to complete and back to back commands will have a few ms of delay as well. I'm guessing you might be able to get a 20ms update rate. The best method would be to leave indexed IO enable and tell the EC to quit reading from the ports. Then you could use indexed IO to read the AD registers directly. I'm not sure what update speed you can get that way but it should be pretty fast. i would think Measure would be more interested in (short-term) averages of voltage and current than in seeing power supply noise. (will an XO even run properly from an unrectified, or even unfiltered, supply?) paul =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: CL1B power distribution
wad wrote: This is the current power distribution diagram for A-phase CL1B, identifying what we can power, when, and how. wad -- a few questions -- for some i can guess at the answer, but better to ask and be sure: - if there are no USB devices inserted, is there an advantage to powering down USB? i.e., does it affect anything more than the devices themselves? - same question for SD? - the keyboard/touchpad are now optionally powered in suspend and run. do you have a specific use case in mind? the only case i can think of is turning them off if we're suspended and don't want their wakeups anyway. - will we have (approximate) numbers at some point for how much power any given subsystem takes? (e.g., for the above case, how much would powering down the kbd/tpad save? this will inform decisions like how much effort is it worth?) - i can't believe i'm asking this, but is it feasible to only power half the ram? would that help the power budget? i have no idea how that feature would be put to use. or, perhaps more manageable: half the flash? if half were unmounted when not in use, for instance. - comparing with http://wiki.laptop.org/images/1/1c/Tinderbox_C2.png (which i'm assuming is correct for XO-1), i see the audio amp could be powered down before. is that integral to the HD Audio Codec box now? - also comparing with that page, the RTC battery charger is always on now, and wasn't before. from our conversation on IRC, it sounds like the circuit hasn't changed -- is that right? (and that it's less a charge circuit than an anti-discharge circuit.) paul =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Notes on service discovery XS/XO
martin wrote: On Tue, Apr 21, 2009 at 2:05 AM, da...@lang.hm wrote: also note that this will require that you run some sort of DNS cache on the The standard dns resolver libs on linux (part of glibc?) caches alright. All platforms I know cache things alright, and it's fairly serious bug if your OS doesn't. really? while that was the original design intent of the resolver library, i didn't think it was ever implemented that way in practice (on unix, at any rate) -- user programs tend to only look up a name once, so caching in the resolver library wouldn't do much good. i believe caching is usually only done by servers. paul =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Server-devel] [Sugar-devel] Notes on service discovery XS/XO
martin wrote: On Tue, Apr 21, 2009 at 2:05 AM, da...@lang.hm wrote: also note that this will require that you run some sort of DNS cache on the The standard dns resolver libs on linux (part of glibc?) caches alright. All platforms I know cache things alright, and it's fairly serious bug if your OS doesn't. really? while that was the original design intent of the resolver library, i didn't think it was ever implemented that way in practice (on unix, at any rate) -- user programs tend to only look up a name once, so caching in the resolver library wouldn't do much good. i believe caching is usually only done by servers. paul =- paul fox, p...@laptop.org ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: #9307 NORM Not Tri: 100% reliable way to test a DCON creates the wrong colors bug
noiseehc wrote: I am not sure if anybody reads the OLPC trac anymore but this demo can show us a DCON bug which probably should be fixed in the gen 1.5 version. Since the program reproduces the bug in 100% of the time, I wish you good debugging. (If it turns out to be just an X bug then I do not know whether it will be fixed ever so never mind.) i've tried this, and you're right, the colors for your program are wrong after the resume. but they're only wrong for your program -- neither my xfce desktop nor a full color image displayed by xv exhibit the problem. i'm not sure what this suggests, but my feeling is that it's not a DCON problem. paul Zarro Boogs per Child wrote: #9307: 100% reliable way to test a DCON creates the wrong colors bug -+-- Reporter: NoiseEHC | Owner: jg Type: defect |Status: new Priority: normal | Milestone: Not Triaged Component: x window system | Version: Mass Production Hardware Keywords: | Next_action: never set Verified: 0| Deployment_affected: Blockedby: | Blocking: -+-- Run the attached program from the Terminal activity on an XO which has 801 and has power saving activated and wait until first the screen dims and then until the animation stops. After you wake the machine the colors will be wrong. Repeat 3 times to get back the good colors. Now if it a DCON bug then you should probably fix it before gen 1.5 comes out. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Notes on service discovery XS/XO
benjamin m. schwartz wrote: Martin Langhoff wrote: The short of it is that mdns/dns-sd make sense for a small, underutilised network of peers. They assume that the network is a cheap resource, that broadcast messages are cheap, and that there is no coordinating server. mDNS assumes all of the above things. DNS-SD does not. DNS-SD is perfectly happy to work on a standard DNS server. From the spec This document proposes no change to the structure of DNS messages, and no new operation codes, response codes, resource record types, or any other new DNS protocol values. This document simply specifies a convention for how existing resource record types can be named and structured to facilitate service discovery. (http://files.dns-sd.org/draft-cheshire-dnsext-dns-sd.txt) the last i looked at (and actually used) dns-sd to solve the discovery problem, it seemed that dns-sd development had stalled. (and i haven't had a reason to look since.) i believe we used code from Sun, which was all i could find at the time, and it wasn't what you'd call production ready. on the other hand, we were using it in a somewhat non-standard way -- in fact, we switched to mdns soon after because it fit our deployment model better, since we didn't really have a central server. the XS model may be a better fit. (this was all 3 or 4 years ago, btw.) paul =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Notes on service discovery XS/XO
martin wrote: On Mon, Apr 20, 2009 at 3:53 PM, Jonas Smedegaard d...@jones.dk wrote: DNS-SD using unicast DNS seems reasonable to me too. If we can do without the avahi gunk, and use it in a way that is not optimised for user driven browsing but for automated selection of services, then it might work. Looking closer at the RFC, the initial service queries do have an added overhead in that a layer of indirection is used (not SRV - A, but instead PTR - SRV + TXT - A). But standard DNS optimizations apply, so SOA record should allow clients to preserve bandwidth through caching. Can we teach dnsmasq to push all the relevant records with the SOA record? In other words: Install dnsmasq on the XOs, use plain standard DNS internally and on the wire, setup DNS-SD entries in a standard nameserver on the XS, and extend Sugar to support DNS-SD. I'd be happy to help compose standard BIND9 files, if that is what will be used on the XS. If we have a dnsmasq resident expert, I rather use your help transitioning to dnsmasq (note - with several bits of weird dhcp rules). There is no upside to BIND and plenty of downsides, starting with the 25MB memory footprint. i'm a big fan of dnsmasq, but be sure it will fulfill all your needs before doing too much work on it -- it's not quite a full-fledged DNS server -- as an example, dnsmasq doesn't support CNAME: http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2006q1/000583.html - ask interesting questions simon kelley (dnsmasq author) is extremely helpful on the dnsmasq list, btw, so it shouldn't be too hard to get interesting answers, as well. :-) paul =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Notes on service discovery XS/XO
jonas wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, Apr 20, 2009 at 09:45:28AM -0400, p...@laptop.org wrote: benjamin m. schwartz wrote: Martin Langhoff wrote: The short of it is that mdns/dns-sd make sense for a small, underutilised network of peers. They assume that the network is a cheap resource, that broadcast messages are cheap, and that there is no coordinating server. mDNS assumes all of the above things. DNS-SD does not. DNS-SD is perfectly happy to work on a standard DNS server. From the spec This document proposes no change to the structure of DNS messages, and no new operation codes, response codes, resource record types, or any other new DNS protocol values. This document simply specifies a convention for how existing resource record types can be named and structured to facilitate service discovery. (http://files.dns-sd.org/draft-cheshire-dnsext-dns-sd.txt) the last i looked at (and actually used) dns-sd to solve the discovery problem, it seemed that dns-sd development had stalled. (and i haven't had a reason to look since.) i believe we used code from Sun, which was all i could find at the time, and it wasn't what you'd call production ready. on the other hand, we were using it in a somewhat non-standard way -- in fact, we switched to mdns soon after because it fit our deployment model better, since we didn't really have a central server. the XS model may be a better fit. (this was all 3 or 4 years ago, btw.) Here's my understanding: * DNS-SD is a formalized use of DNS records to store services (rather than hosts, the most popular use of DNS records). * mDNS is DNS over multicast (using DNS-SD to resolve services). sigh. please disregard everything i wrote in the paragraph above. i was mistakenly referring to DNS-SD when i should have been referring to SLP (service location protocol). we migrated from SLP to mDNS. this has nothing to do with anything martin has proposed for the XS. sorry! :-) paul So it seems to me that if you've switched from DNS-SD to mDNS, then in fact you are still relying on DNS-SD, just using an additional layer on top of it. A good introduction (assumably more reliable than Wikipedia) is http://www.dns-sd.org/ - Jonas =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
powerd on XS?
martin and i just had a short exchange off-list that we realized should probably be moved on-list. here's an edited transcript: To: Martin Langhoff martin.langh...@gmail.com From:p...@laptop.org Subject: Re: Bxl testing report - April 16th hi martin -- i've been watching your XS development updates (and applauding, btw :-), and it occurred to me i should remind you about olpc-powerd XS-on-XO. it might not be the least bit necessary -- you might even get exactly the behavior you want without installing either it or ohmd -- but if you need any kind of power/suspend/screen-dimming/shutdown kinds of management, powerd is far more easily tweaked. as an example, the other day i realized that on a small server i was setting up on an XO (a home audio server), that it would be convenient to be able to run it on the shelf with lid closed. it was trivial to add a remain awake when shut config option. another example: the XS might want a limit how long it runs on batteries without external power -- again, trivial with powerd. (powerd already performs a critical battery level shutdown, which ohmd lacks.) paul To: Martin Langhoff martin.langh...@gmail.com From:p...@laptop.org Subject: Re: Bxl testing report - April 16th martin wrote: Great idea, thanks for the offer! Remain awake when shut is desirable (but was getting that... because I don't have ohmd :-) ) -- and shutdown when on low battery is something I really need (so I'll need power handling). Powerd is written in Python? Some of the questions I'll come asking is: actually, no -- it's in shell, with two helper daemons in C. (i pre-date python. ;-) the three pieces are: olpc-kbdshim: implements support for the grab keys on the XO keyboard, and rotates the action of the touchpad to match rotation of the screen. what's pertinent here is that because it's watching the entire user input stream, it also reports user idle and activity states to powred. there are two versions: the principle version is part of HAL, because that makes watching USB keyboards a lot easier. there's a previous, almost identical standalone version, however, if you're not using HAL. (i really didn't want to depend on hal, so i wrote that version first. but support for USB input devices forced my hand.) olpc-switchd: watches the lid, ebook, and power-button switches, and periodically polls (15 second interval) AC and battery status. powerd: it's a big shell loop that watches events that arrive via a fifo, and acts on them to manage the idle timeouts, watch battery level, etc. perhaps not useful for the XS is that it uses rtcwake to allow a sleeping laptop to wake up in order to either turn off its own display, or to shutdown completely. - what's the mem footprint? i don't think the VSZ/RSS numbers are very useful in this case, since the shell is probably always resident. if i stop powerd, free tells me i get 350K back. that seems to be reproducible. same metric with olpc-switchd says roughly 100K. it's harder to quickly get isolated numbers from olpc-kbdshim because it's started/stopped by hald, but i'd guess it's similar to olpc-switchd. so call it all 600K, certainly less than 1M, in total. - how can we minimise it? the olpc-switchd functionality could be pulled into olpc-kbdshim. powerd could be rewritten in C (which wouldn't be hard, now that its been prototyped -- just a bit time consuming). also, i was careful not to write bash-specific code -- i _believe_ powerd will run under dash, for instance. perhaps not advantageous if bash is already resident, but maybe. - how can we make sure it's safe to swap the process out if no relevant events are triggered? this sounds like you're doing the swapping manually somehow. otherwise, i'm not sure i understand why it wouldn't swap in when needed? - can we turn powerd into logic that gets triggered by kernel events (udev, etc) instead of a resident daemon? well, that's sort of what it is now, at some level. [ Those are the same nasty questions I ask about every bit of sw on the XS. It's a tricky space... ] . To: p...@laptop.org From:Martin Langhoff martin.langh...@gmail.com Subject: Re: Bxl testing report - April 16th On Fri, Apr 17, 2009 at 3:25 PM, p...@laptop.org wrote: martin wrote: Great idea, thanks for the offer! Remain awake when shut is desirable (but was getting that... because I don't have ohmd :-) ) -- and shutdown when on low battery is something I really need (so I'll need power handling). Powerd is written in Python? Some of the questions I'll come asking is: actually, no --
Re: new releases of powerd and olpc-kbdshim (alt. power mgmnt)
i wrote:
olpc-kbdshim should work on the
latest rawhide releases. (i hope -- feedback please, i haven't
had a chance to try rawhide myself.)
i've gotten my feedback: in a word, don't bother. :-) the grab
keys might work, but rotation is broken, not only because the
location of keyhandler.py has changed under rawhide, but dcon
support isn't complete.
paul
=-
paul fox, p...@laptop.org
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
new releases of powerd and olpc-kbdshim (alt. power mgmnt)
i've released a new version of both olpc-kbdshim and powerd. olpc-kbshim supports the XO grab keys, rotates the touchpad action when the screen rotates, and provides user (in)activity status for powerd. with this release olpc-kbdshim is now integrated with HAL in order to allow tracking USB mice and keyboards. powerd is a more flexible and configurable replacement for ohmd. it's not a drop-in replacement, but it's getting close -- there are a few things ohmd provides which are hard for powerd to do in exactly the same way. i'm about to start the review process for getting these both into fedora -- if you've been thinking of trying them, but haven't, i could use the feedback. remember that you'll need to install powerd on a laptop running an OLPC kernel, otherwise suspend and resume won't do anything anyway. olpc-kbdshim should work on the latest rawhide releases. (i hope -- feedback please, i haven't had a chance to try rawhide myself.) powerd disables ohmd when it installs, and reenables it if it's uninstalled. so there's no conflict unless you install ohmd after powerd, which is unlikely. both packages will apply small patches to sugars keyhandler.py, in order to take back control of the rotation and brightness keys. (i've suggested these patches become permanent, somehow, in SL #737.) if you later remove either of my packages, the keyhandler.py patches remain, but are benign. i could go on about features, etc, here, but since i'd be quoting or paraphrasing info that comes with the packages, i'll just refer directly there. olpc-kbdshim is described in its README: http://dev.laptop.org/git/users/pgf/olpc-kbdshim/tree/README powerd is described by commentary in the core script itself: http://dev.laptop.org/git/users/pgf/powerd/tree/powerd the git trees for the two packages are here: http://dev.laptop.org/git/users/pgf/olpc-kbdshim/ http://dev.laptop.org/git/users/pgf/powerd RPMs live here: http://dev.laptop.org/~pgf/rpms and the initial announcements of powerd is here: http://lists.laptop.org/pipermail/devel/2009-March/023798.html olpc-kbdshim wasn't as well announced, but was described here: http://lists.laptop.org/pipermail/devel/2009-March/023703.html paul =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: move to rawhide update
peter, and greg -- greg wrote: Whichever way you go, strong leadership, patience, and many hands are required to fight through the problems. If the community cares enough and develops the necessary leadership, the project moves forward. But it's never easy. It is my hope that people continue to use the tracking bug here, and align bugs to it, and use it to assess fitness of the current release: https://bugzilla.redhat.com/showdependencytree.cgi?id=461806hide_resolved=1 of course. but the whole thing feels a lot like telling someone that their local dealership has closed, and they should write to the car's manufacturer for information about oil changes. the scale of the solution doesn't match the needs of the problem. (the analogy is shaky, i agree.) but as an example -- if bugs filed against the XO will be summarily closed by the developers because it's not our problem, file it upstream, the larger OLPC community will be ill-served. users of the XO are not typical open-source enthusiasts, and they're not the audience that current linux distributions are used to targeting. the XO isn't a general purpose laptop, and was never intended to be. it's better considered a device, with special needs, and as such i think it will be under-served by the new generic release and support scheme. while i agree that the current plan is probably the best we can come up with, i remain frustrated. thanks. and sorry for the non-technical venting... believe me, the real target of my rant is not the folks like you two who are continuing the mission. paul =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: move to rawhide update
john wrote: It looks like perhaps the kernel changes have slipped right through the F11 schedule. Is it seriously likely that the F11 kernel for the record, this was a conscious decision. everyone knew there wouldn't be time to get XO-specific changes upstream, and back to fedora, before F11. as you say, it was the cost of going broke. the challenge is now to get those changes upstream in time for F12. maintainers would adopt a pile of OLPC patches that aren't in the upstream kernel, between the Beta and the Final F11 releases? Had these changes been adopted (by Fedora or by the Linux kernel) early in the release cycle, they could've been well tested to make sure they don't introduce any problems into non-OLPC hardware. But now, it appears that F11 won't be able to suspend on OLPC, which makes it almost useless for laptop use (as opposed to developer use when the laptop is sitting on a desk with permanent AC power). Such is the i think the plan is to make an OLPC-patched kernel available for the distribution creators. paul price of firing all of your kernel developers. Even the bug report that tracks the kernel power management changes has fallen into disarray (the Fedora Bug Zapper zapped it in November and nobody has bothered to fix it since): https://bugzilla.redhat.com/show_bug.cgi?id=465284 John ___ Fedora-olpc-list mailing list fedora-olpc-l...@redhat.com https://www.redhat.com/mailman/listinfo/fedora-olpc-list =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: GPS on XO
hal wrote: in particular, the part about getting maps should be more specific: maps are big, so you'll want to put them on SD or USB. roadmap will look for maps in a top-level directory called RoadMap.maps, plus in any subdirectories of RoadMap.maps. as long as the full path is /media/something-or-other/RoadMap.maps/, it should find them. Close, but it doesn't work with /media/USB Drive/ which is where my USB flash drive shows up. Note the space in there. :) hrmph. Don't do that. :-) This seems worthy of a bug report. (Not RoadMap, whatever code mounted it with a filename containing a space.) Which chunk of code is that? Does RoadMap wamt a bug report too? i confess i'm not sure who mounts the drive. i suspect most people will say Not a bug. i should be able to make that work in the RoadMap activity. i'll take a look. I've got the California maps working now. Thanks again. The maps have interesting wiggles in streets that should be straight lines. My guess would be the bottom bits of the locations are getting compressed out. The streets I'm looking at are straight, but off north-south or east-west. can you send me a screen shot, and/or the lon/lat of where you're seeing the problem? roadmap stores and uses microdegrees, so i don't think it's a truncation problem. Sometimes roads and creeks overlap a bit. the Tiger data (from the US Census bureau) has notoriously bad water feature data, so this doesn't surprise or concern me. it's called RoadMap, not MarineChart for a reason. ;-) I've also seen it miss chunks of road around the edges. Moving slightly picks them up. at very high zoom levels? yes, i haven't worked on that one for a while. someone broke the screen-edge clipping at some point. I haven't figured out how to display or collect a track yet. hmm. i thought the breadcrumb trail (where the breadcrumbs are shown as small purple dots) was be enabled by default, but maybe i'm wrong. it's either not being displayed, or it's not being generated. to fix: File-Preferences then scroll through _far_ too many configuration tabs to get to Track, and be sure you have: Initial Display: on Policy: anything but Off you can read about the different track policies under CURRENT TRACK at http://roadmap.sourceforge.net/usermanual.html paul =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [BULK] Re: GPS on XO
hal wrote:
i confess i'm not sure who mounts the drive. i suspect most people
will say Not a bug. i should be able to make that work in the
RoadMap activity. i'll take a look.
It really is a bug. All sorts of command line code gets in trouble if there
are spaces in filenames. I've seen it mentioned so many times on the FPGA
newsgroup that it finally sunk in. Spaces in file/directory names are just
asking for troubles.
i suppose. but if the user named their device that way, i'm not sure they'd
expect it to be mounted in some other way. and like it or not, unix needs
to (and does) provide tools for navigating pathnames with spaces.
i guess i'd be a lot more worried if the volume name (or whatever
it is that's being used as the device name) could contain a slash
('/') character. because that would no doubt render the device
unmountable. someone should try that...
paul
Yes, you can probably fix this case. That leaves 99 other systems that
will still need fixing.
Even if they didn't cause this sort of problem, they require extra effort
(quotes or a backslash) when typing things in. Why set a bad example? (Tab
expansion did the right thing and put in a backslash when it completed the
name for me.)
--
These are my opinions, not necessarily my employer's. I hate spam.
=-
paul fox, p...@laptop.org
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: GPS on XO
hal wrote: From the Testing summary Roadmap-3 Map of California came up, could move around easily. Interesting timing. Thanks. I'm about to go on a long drive and it would be fun to be able to watch where I'm going on my XO. I've got a USB GPS device that shows up on lsusb as a Prolific serial port. i'm the current maintainer of roadmap (not just the Activity), so in theory i should be able to answer all your questions. roadmap works very well for what you want to do, and can even help directly guide you somewhere if you've preloaded it with a route to where you want to go. what it can't do (that any modern GPS navigation device will do these days) is figure out the route to your destination itself. Are there any other activities or whatever on an XO that use input from a GPS device? I can't get much useful out of Roadmap-3. On startup, I get a street map of the San Francisco area, but scrolling doesn't update the map beyond the edge of the initial map and the help stuff doesn't do anything. even though the maps that roadmap uses are pre-processed into a format suitable for small devices, they're way too big to provide more than a demo sampler with the Activity itself. so what you have is state outlines for the whole country, and full details for just the city of san francisco. just enough to whet a user's appetite, and i'm pleased to see it worked. :-) Does anybody know how I can download/preload maps for a region? Or the help stuff? the help screens in roadmap are available in HTML format. because sugar still hasn't figured out how to make it easy for an activity to present the user with information in a browser, the help isn't packaged with the activity. probably short-sighted of me. in any case, it's all available here: http://roadmap.sourceforge.net/usermanual.html you should also take a look at: http://roadmap.sourceforge.net/platforms.html#toc3 for some XO-specific information, though looking at it just now i see it could use some fleshing out. in particular, the part about getting maps should be more specific: maps are big, so you'll want to put them on SD or USB. roadmap will look for maps in a top-level directory called RoadMap.maps, plus in any subdirectories of RoadMap.maps. as long as the full path is /media/something-or-other/RoadMap.maps/, it should find them. fetch maps of the states you want to visit from here: http://roadmap.sourceforge.net/maps.html create a RoadMap.maps directory on your storage device, and unpack the tarballs you find at that page into that directory, and (re)start RoadMap. you should then have a much fuller view of the world. (for non-USA folk -- roadmap also has limited maps for canada (roads, but no water features), as well as support for OpenStreetMap maps which are quite good for many parts of the world.) Poking around on the menus... It finds my GPS device and displays a reasonable location. It says 0 satellites, so I assume it wants more info. I've got a typical GPS toy speaking NMEA. What $GPxxx sentences does Roadmap want? It's currently setup to send only $GPRMC sentences. roadmap will use GPRMC, GPGGA, GPGSA, GPGSV, and GPGLL. i believe if you add at least some of those, you'll get the satellite count correctly. i encourage you to join the roadmap mailing list -- there's only one list for users and developers because the community is small and the traffic level low. paul =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Announcing Fedora 11 Beta for XO
peter wrote: It is as far as I'm aware plain rawhide which means it will be sugar 0.84 with default Fedora power stuff using the new devicekit [1]. All the hardware should work as expected and if it doesn't please report it, either here or in the Fedora Bugzilla. i don't understand. wasn't there just a thread yesterday or the day before about how there are major XO-specific pieces (e.g. suspend/resume, the dcon driver) missing from the fedora kernel? what do you mean by hardware should work as expected? paul Cheers, Peter [1] https://fedoraproject.org/wiki/Features/DeviceKit On Fri, Apr 3, 2009 at 9:15 PM, Carol Farlow Lerche c...@msbit.com wrote: That is somewhat helpful, but I suppose I was hoping for the XO-specific parts. E.g. power management? Does all the hardware work (leaving aside the stylus area, of course)? Is sugar installed and if so what version? Does wifi definition work in the sugar gui? That stuff. On Fri, Apr 3, 2009 at 1:04 PM, Peter Robinson pbrobin...@gmail.com wrote: The Fedora F11 beta announcement is here http://www.redhat.com/archives/fedora-devel-list/2009-March/msg02103.html Peter On Fri, Apr 3, 2009 at 9:01 PM, Carol Farlow Lerche c...@msbit.com wrote: Chris, are there release notes somewhere? On Fri, Apr 3, 2009 at 12:51 PM, Chris Ball c...@laptop.org wrote: Hi, Here's a build of the F11 beta release for XO: http://dev.laptop.org/~cjb/rawhide-xo/f11-beta/ Instructions on flashing are at http://dev.laptop.org/~cjb/rawhide-xo/. Enjoy, - Chris, with thanks to the SoaS and Fedora teams. -- Chris Ball c...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel -- It is difficult to get a man to understand something, when his salary depends upon his not understanding it. -- Upton Sinclair ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel -- It is difficult to get a man to understand something, when his salary depends upon his not understanding it. -- Upton Sinclair ___ Fedora-olpc-list mailing list fedora-olpc-l...@redhat.com https://www.redhat.com/mailman/listinfo/fedora-olpc-list =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Announcing Fedora 11 Beta for XO
peter wrote: It is as far as I'm aware plain rawhide which means it will be sugar 0.84 with default Fedora power stuff using the new devicekit [1]. All the hardware should work as expected and if it doesn't please report it, either here or in the Fedora Bugzilla. i don't understand. wasn't there just a thread yesterday or the day before about how there are major XO-specific pieces (e.g. suspend/resume, the dcon driver) missing from the fedora kernel? what do you mean by hardware should work as expected? Yes. This isn't a joyride style build though. Its a Fedora build with sugar for the OLPC. See chris's follow up post. right. joyride or not, it's simply not the case that hardware should work as expected. :-) paul =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: announce: alternate power management
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 =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] instructions for flashing SoaS on a XO
mitch wrote: My XO Boots but gets stuck loading the initrd. OFW Q2E34 Here is what I see on the screen Boot device: /nandflash:\boot\olpc.fth Arguments: Boot device: /nandflash:\boot\vmlinuz0 Arguments: root=mtd0 rootfstype=jffs2 liveimg console=tty0 console=ttyS0,115200 boot_delay=3 fbcon=font:SUN12x22 Loading ramdisk image from nand:\boot\initrd0.img It stays there its been about 20 minutes now. Try booting with the check button (game key above the power button) held down. If that fixes the problem, the issues is that the OS is not switching from pretty boot mode to active screen mode. i only realized recently that the final unfreeze of the screen is not done in bootanim, as i expected, but by way of sugar installing a g_idle callback that sends a message to ohmd to do the unfreeze. so if either sugar or ohmd don't start correctly, the screen will stay frozen. this doesn't seem optimal to me. (and it may be that i have it wrong, and there's another unfreeze mechanism as well.) (when powerd replaces ohmd, it simply does the unfreeze after 10 seconds have passed. also sub-optimal.) paul You can disable pretty-boot by adding these lines to /boot/olpc.fth : unfreeze visible The second line, just after the comment line, is a good place for them. ___ Sugar-devel mailing list sugar-de...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: announce: alternate power management
albert wrote: pgf writes: so: i've packaged a new version of powerd. the big change is that it now allows for the two modes of operation i mentioned last week on the list: dim sleep, screen on sleep, screen off shutdown or: dim screen off sleep, screen off shutdown screen on and screen off aren't very well defined. What exactly do you mean? sorry -- i was describing it from a naive user's perspective. here: dim(reduced backlight) sleep, screen on (cpu sleep, dcon on, backlight still on and dim) sleep, screen off (cpu sleep, dcon off, backlight off) shutdown or: dim(reduced backlight) screen off (cpu running, dcon off, backlight off) sleep, screen off (cpu sleep, dcon off, backlight off) shutdown the two cases are diffentiated by powerd simply by looking at the middle two timers -- if the timer for sleeping is smaller than the timer for turning hte screen off, you get the first set of steps, otherwise the second. (btw, probably obvious, but any trailing subset of these steps can be supressed simply by setting the appropriate timeout arbitrarily high.) a. the Geode chipset: producing video or not? i don't believe anything explicit for this is done (except shutdown and cpu sleep, of course). i'm not sure how to accomplish this. b. the DCON: pass-through, freeze-frame, or off? the dcon is frozen while the shutdown splash screen(s) are painting, so that you can't see the shades coming down. other than that, it remains unfrozen, but is turned on and off as noted above. c. the backlight: on or off? turned on and off as above. when dimming, the level being ramped to is configurable, so if you set it to 15, no dimming will occur. d. the LCD panel: on or off? i confess i don't know how to do that. if it's feasible, and not happening already, it should be added. paul =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: announce: alternate power management
okay, if i don't quit playing with this thing and get the taxes
done, my wife will kill me.
so: i've packaged a new version of powerd. the big change
is that it now allows for the two modes of operation i mentioned
last week on the list:
dim
sleep, screen on
sleep, screen off
shutdown
or:
dim
screen off
sleep, screen off
shutdown
(in contrast, the current releases only really support
dim
sleep, screen on
after that you have to do things manually.)
in addition, powerd can use a completely different configuration
profile when running in ebook mode -- in fact, you can have multiple
profiles (you know you've always wanted a different power behavior
when taking your laptop to the beach, right?) and switch between
them pretty easily.
there's also a (very) primitive configuration utility that lets
you select the major configuration parameters. (it's dialog-based,
so it's curses-based graphics. you've been warned.)
by default, power management is only active when you're running
on battery. that's selectable.
the big items listed under unimplemented down below are still
unimplemented. don't know when i'll get to them.
enjoy. please try it, please let me know what you find. i've
seen a few anomolies while playing with it -- most of which i
think i've fixed. but there may well be more, since i think i've
seen at least one i still can't really explain. (but it was
after a couple of glasses of wine, so who knows.)
code:
http://dev.laptop.org/git/users/pgf/powerd/
rpms:
http://dev.laptop.org/~pgf/rpms/
paul
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
Re: improving XO connectivity rates
martin wrote: On Tue, Mar 17, 2009 at 2:36 AM, Daniel Drake d...@laptop.org wrote: Actually, the connection succeeds, the problem is that the Good debugging! you can find the .c source on the ticket and compile it yourself the thread on the dbus list is quite scary. OTOH, your patch made my morning. The right fix will take a lot of hair pulling. Nothing that a spartan sleep(3); can't fix. i cringe every time i see a sleep in code like this -- network setup takes long enough as it is. any chance one could get a similar workaround by instead asking for or sending some more data? e.g., if one sent the same message twice (knowing that the recipient would ignore dups), then it wouldn't matter if the second one sometimes didn't make it. paul =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: improving XO connectivity rates
daniel wrote: 2009/3/16 p...@laptop.org: i cringe every time i see a sleep in code like this -- network setup takes long enough as it is. The sleep is not in the network setup path. It happens after the DHCP client has established connectivity and notified networkmanager of that fact. It doesn't add any delay. ah. okay. so NM won't wait for the close before telling the user their network is ready? paul =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: announce: alternate power management
mikus wrote: configurable timeouts for screen dim and sleep. the dim level is configurable. My XO systems are plugged in to the AC, so I normally leave them running 24/7. But in the middle of the night if I happen to walk by, I notice if they are acting as light sources. Two concerns (for which I don't know whether doing anything is feasible): - Rawhide. AFAIK there currently is no dimming support at all. I either have to power off such an XO overnight, or have to close the lid while the backlight is still lit. It would be useful if rawhide supported dimming/shutting_off the screen when no one is looking at it (irrespective of whether the CPU is doing work or not). i'm sure rawhide will gain a power management solution of some sort. probably ohmd will be added. i wouldn't be surprised if olpc-kbdshim and olpc-powerd would work fine as well, but if you'd like to test that to confirm it, i wouldn't object. ;-) - Suspend. It was functioning well only with Joyride - but I hope it gets implemented other places as well. The problem is - the CPU may suspend because it is idle (and partly dim the screen), but the user may still continue looking at that screen (in color mode) while the XO is suspended. After a decent interval at half-bright, it is reasonable to assume the user has seen enough, and the screen could now be dimmed all the way off. BUT since the system is sleeping, the current implementation has no way to wake up the system just so it can execute 'screen dim' instructions. The result is that if I don't intervene at the keyboard, my suspended (Joyride) XO's screen remains half-bright throughout the night. I think it yes, clearly it would be good to have two (or maybe three) more stages available for idleness. we should be able to extend current behavior like this: dim (exists) sleep, screen on (exists) sleep, screen off (can't be done currently) shutdown (can't be done currently) or, alternatively, this sequence, which is more like a normal laptop behaves: dim screen off sleep, screen off shutdown (can't be done currently) i think all but the last step could be done currently. what's missing is a) a wakeup when closing the lid, and/or b) the ability for the system to set an alarm clock with which to wake up at some time in the future, in order to let it go back to (a deeper) sleep. i spoke with richard about the wakeup alarm recently -- implementing this requires changes to both the EC (embedded controller) and to the kernel. but maybe we can push something along. it's a feature which has been long-planned, but never finished. counter-productive to suspend the rest of the system (to save power!) when no one is using it, but to leave the screen lit (still drawing power!) once it can be presumed no one is using it any more. different power behavior when in ebook mode (though detection may be unreliable -- i think the ebook switch suffers from some issues we previously noticed with the lid switch). What issues ? I thought the lid switch could be fooled by people with magnets - but that an actual shut would always be recognized as being a shut (and a failure to recognize an open could be overcome by momentarily pressing the power button). the lid issues i was referring to are covered in #5703 and #7536. a) we get no wakeup when closing the lid, only opening. i believe this is a regression from some time ago, possibly a result of the fixes described in #5703, but also possibly a side-effect of #7536. (i haven't yet examined the actual code for either one to see what's going on.) this keeps us from noticing that the lid is being closed with the screen still on, and it stays like that. (#7536 was a change to keep us from waking on lid close when the screen was off -- in that case the wakeup was needless.) b) i've seen out-of-sync ebook switch behavior -- i.e., the event being reported (ebook open/close) exactly mismatches the physical condition of ebook mode. since this behavior was described for the lid switch in #5703 (and fixed), i'm guessing the ebook switch needs similar love. again, i haven't looked at the code yet. c) we still sometimes get empty sci as the wakeup source after a lid open. i (in powerd) currently treat empty sci the same as lid, but that might not fly if we were to fix a). paul =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: announce: alternate power management
i wrote: b) i've seen out-of-sync ebook switch behavior -- i.e., the event being reported (ebook open/close) exactly mismatches the physical condition of ebook mode. since this behavior was described for the lid switch in #5703 (and fixed), i'm guessing the ebook switch needs similar love. again, i haven't looked at the code yet. i've now looked at the code -- ebook mode tracking is completely separate from and different than lid state tracking. (sigh :-) it seems the condition i saw could be caused by an early failed read of the ebook state by the kernel, or a subsequent loss of one of the SCI events which indicates that the state changed. (this is a really good example of why just reporting something has changed, without reporting what it has changed _to_, is a bad idea from a robustness point of view.) paul =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: announce: alternate power management
scott wrote: On Sat, 2009-03-14 at 09:37 -0400, p...@laptop.org wrote: i'm sure rawhide will gain a power management solution of some sort. probably ohmd will be added. i wouldn't be surprised if olpc-kbdshim and olpc-powerd would work fine as well, but if you'd like to test that to confirm it, i wouldn't object. ;-) Rawhide status: thanks for testing! 1. Only by using an OLPC kernel (such as the one from staging release 801) is the kernel is capable of power management on the XO 2. with an OLPC kernel, ohmd does not work. Closing the lid, hitting the power button, these are not detected. I don't know why at the moment... odd. ohmd uses dbus for various things, but i would have assumed that would work. 3. with the OLPC kernel and this olpc-kbdshim and olpc-powerd (which by the way are really realy nice, thanks a million pgf!) the XO suspends when via lid switch and the power button. great! did you try the grab keys and rotation? (those are just olpc-kbdshim.) olpc-rotate should spin the display, even if the buttons don't work. 4. In a GNOME session, this behaves oddly, as gnome-power-manager also intercepts the power button press and pops up a hibernate/suspend/yadayada/ dialog, and then your XO suspends anyway :-) yeah, i kind of expected that. similar issues happen if you run ohmd alongside powerd as well. is g-p-m (easily) uninstallable? paul =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: announce: alternate power management
scott wrote: 3. with the OLPC kernel and this olpc-kbdshim and olpc-powerd (which by the way are really realy nice, thanks a million pgf!) the XO suspends when via lid switch and the power button. great! did you try the grab keys and rotation? (those are just olpc-kbdshim.) olpc-rotate should spin the display, even if the buttons don't work. Pressing the rotation button does nothing in GNOME or Sugar. Should this be a general X rotation that should work in any X session? hmm. i wouldn't expect the button to work in gnome, but i'd expect the sugar bindings to continue working. the first check, though, it to see if the olpc-rotate command works from terminal. when olpc-kbdshim installs, it patches sugar to run that command rather than do its normal internal calls to xrandr. so if the command works, but the key doesn't, the debug path is pretty short, at least, i think. (is is possible that sugar installed after olpc-kbdshim? that would explain it.) What are grab keys? I am not seeing any functionality for the gamepad keys. In the OLPC Fedora/Sugar these enable me to get around the scroll bar is not draw even though content is larger than frame fun. the grab keys are the two with the little hands, at either side of the space bar. on an industry standard keyboard, they would be the bear the industry monopolist logo. :-) when you hold either down, a using the touchpad should cause whatever you're looking at to scroll. (if it's capable, of course -- i.e., wide or tall web pages, or terminal sessions with any amount of scrollback.) 4. In a GNOME session, this behaves oddly, as gnome-power-manager also intercepts the power button press and pops up a hibernate/suspend/yadayada/ dialog, and then your XO suspends anyway :-) yeah, i kind of expected that. similar issues happen if you run ohmd alongside powerd as well. is g-p-m (easily) uninstallable? Yes. Very easy to remove. One additional point related to power management, the control panel in the current Sugar RPMs (for rawhide/F11) doesn't have the power settings (extreme power management etc.) icon. Perhaps there is a gconf key to enable that? I asked in #sugar but got no reply. Or, is this functionality removed on purpose? don't know. i have several questions about how XO-specific hardware will be supported going forward. i assume the sugar folks would rather not continue carrying hardware specific key-bindings for rotation and brightness for instance, but i don't know what their current thoughts are. paul =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
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
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: extend the memory flash space with an SD card to build open80211s
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. paul =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
fixing broken wiki-to-git links
with the recent switchover from, uh, whatever we were using before, to cgit on dev.laptop.org, there are now many stale links on wiki.laptop.org (and possibly some at sugarlabs as well, i suppose). if you do a google search on wiki.laptop.org for url:dev.laptop.org/git you'll get almost 200 hits for such links. many of these are in the Activity summary section of pages like this: http://wiki.laptop.org/go/Log_Viewer#Feature_requests i assume a mechanical translation is possible, but i don't know. any volunteers to take this on, and make all those links work again? paul =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
[no subject]
[resend from subscribed address] last week i announced a daemon that would activate the grab keys on the XO keyboard. a day or two later there was a thread about how it would be nice if the action of the touchpad rotated with the screen (in much the same way that the dpad keys do). since my daemon was already looking at every input event, it seemed a natural place to implement the rotation feature. and after doing that, the name seemed like it should change. so, announcing olpc-kbdshim. source: http://dev.laptop.org/git?p=users/pgf/olpc-kbdshim rpm: http://dev.laptop.org/~pgf/rpms/olpc-kbdshim-1-1.i386.rpm after installing the rpm you need to fully reboot your laptop to get the plumbing set up properly. the rpm includes a new command olpc-rotate which takes care of all the mechanics of screen and touchpad rotation. since sugar (currently) handles this key binding, the rpm postinstall script patches /usr/share/sugar/shell/view/keyhandler.py so that it invokes os.system(olpc-rotate) _instead_ of its current builtin behavior. separating it out like this makes olpc-kbdshim and olpc-rotate more useful for non-sugar UIs. i wrote the sugar patch so that it won't break if you uninstall the olpc-kbdshim rpm -- sugar will take over the rotate function again. also, though i haven't tried it on today's brand-new sugar 0.84 (good work everyone!), a look at the current keyhandler.py says the patch should still apply correctly. the topic of ebook-mode touchpad usage came up the other day too. while i didn't create any visible UI support for it, the daemon will put the touchpad in and out of ebook-mode (which means, reflecting it on both x and y axes) using olpc-rotate -e/-n please let me know what you think... paul p.s. btw, the daemon isn't really very olpc-specific. i've been running it on my thinkpad all week, in order to get the use of the grab key scrolling. the thinkpad doesn't have Windows keys (which is what the XO grab keys are), but it turns out the blue Fn key in the corner can be used as a modifier, so that plus my trackstick gives 2D scrolling -- it came in very handy for looking at the bootchart images this morning. =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: testers needed: grab keys and touchpad rotation
sorry about that. replying to add a subject... i wrote: last week i announced a daemon that would activate the grab keys on the XO keyboard. a day or two later there was a thread about how it would be nice if the action of the touchpad rotated with the screen (in much the same way that the dpad keys do). since my daemon was already looking at every input event, it seemed a natural place to implement the rotation feature. and after doing that, the name seemed like it should change. so, announcing olpc-kbdshim. source: http://dev.laptop.org/git?p=users/pgf/olpc-kbdshim rpm: http://dev.laptop.org/~pgf/rpms/olpc-kbdshim-1-1.i386.rpm after installing the rpm you need to fully reboot your laptop to get the plumbing set up properly. the rpm includes a new command olpc-rotate which takes care of all the mechanics of screen and touchpad rotation. since sugar (currently) handles this key binding, the rpm postinstall script patches /usr/share/sugar/shell/view/keyhandler.py so that it invokes os.system(olpc-rotate) _instead_ of its current builtin behavior. separating it out like this makes olpc-kbdshim and olpc-rotate more useful for non-sugar UIs. i wrote the sugar patch so that it won't break if you uninstall the olpc-kbdshim rpm -- sugar will take over the rotate function again. also, though i haven't tried it on today's brand-new sugar 0.84 (good work everyone!), a look at the current keyhandler.py says the patch should still apply correctly. the topic of ebook-mode touchpad usage came up the other day too. while i didn't create any visible UI support for it, the daemon will put the touchpad in and out of ebook-mode (which means, reflecting it on both x and y axes) using olpc-rotate -e/-n please let me know what you think... paul p.s. btw, the daemon isn't really very olpc-specific. i've been running it on my thinkpad all week, in order to get the use of the grab key scrolling. the thinkpad doesn't have Windows keys (which is what the XO grab keys are), but it turns out the blue Fn key in the corner can be used as a modifier, so that plus my trackstick gives 2D scrolling -- it came in very handy for looking at the bootchart images this morning. =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] testers wanted: grab keys, and touchpad rotation
bert wrote: Just tried it on my XO at build 800 - works like a charm, both the scrolling and rotation. Yay! great! The only nit I have to pick is the inverted direction of scrolling. With both a scroll-wheel and my MacBook's two-finger scroll, moving down does scroll down. I understand about the grab metaphor implied by the key caps, but since we're not actually grabbing but scrolling, IMHO it should scroll the other way. if you edit /etc/events.d/olpc-kbdshim and add a -r to the olpc-kbdshim invocation line, you can try that behavior to see how you like it. edit, then: initctl stop olpc-kbdshim initctl start olpc-kbdshim others should weigh in on this. you'll remember that it was the big question i raised last week. i think i agree with you, but i also think it's hard to put oneself in the shoes of a user who has never used a scrollbar before. paul who is hoping he can send at least one message today without botching the From line, the Subject line, or the To line. =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] testers needed: grab keys and touchpad rotation
wade wrote: Cool! I'm looking forward to trying this when I get back to my XO I wonder though, is there a reason this has to be a separate daemon, and can't just being part of the HPGK driver with a /sys/... interface for control? it's a daemon very largely because much of the code already existed in daemon form, from another project of mine. it also makes it much more flexible -- adding the rotation support was trivial, for instance. and i was able to include primitive (don't disconnect it!) support for USB keyboards (since my XO has a hardwired mini-usb keyboard in place of the standard one). but your point is a good one. i just don't know how easy it would be to to combine state from two drivers -- the mouse and keyboard data travel pretty different paths, AFAICT. paul =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: What to expect from developers, are there any left?
noiseehc wrote: Sorry, I wanted to post it toplevel. p...@laptop.org wrote: but like david, i think that currently neither olpc nor sugarlabs is going to foster or champion their use: olpc has no resources for s/w development, and as far as i can tell, sugarlabs is targeting other h/w platforms just as strongly as the XO -- and other platforms don't have these screen issues. Witch the recent disbanding of the development team I simply cannot see what will happen to the XO development. I mean that 8.2.1 will be released and 9.1.0 is dropped but what I do not understand is what will happen with all the development for 9.1.0? What I heard is that those will be pushed upstream (whatever that means) but it is not clear if reporting bugs or talking about button layouts on the game pad will result in a new software release or is just a waste of time. What I mean is that should I also subscribe to some Fedora devel list (note that I do not know sh*t about linux development, packaging or anything like that) to keep informed or what? a brief conversation on #olpc-devel yesterday evening made it clear that there's a big gap in our understanding of the issues you're raising. it's entirely possible that some folks think the path forward is clear. i know that it's not to me. as i understand it, the goal is to push everything that's XO-specific into packages that are acceptable to fedora, at least in terms of not interfering with the rest of a stock fedora release. assuming we can do that (and i'm confident we can), the next step is to take a set of fedora rpms, mostly generic, some XO-specific, and create a distribution. what's opaque to me, currently, is: - who will do this - how often - what set of packages will be included - what the process will be for changing that set of packages OLPC has spoken pretty clearly (with deeds, if not words -- words have never been OLPC's strong point ;-) that it won't be doing s/w releases or distributions. so who will? Currently I am writing a nice activity which teaches kids what to do when alien spaceships attacks Earth and it will take some time to finish. What should I do next? this is a much simpler question: there's a lot of work going on in sugarland to help activity writers. since activities are released independently, the distribution aspects that affect XO base s/w aren't really an issue. http://sugarlabs.org/go/ActivityTeam Can some insider comment on these issues please? you may be overestimating a) the number of insiders, and b) their stash of undisclosed information. paul =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: rotate button sucks on the XO
noiseehc wrote: The question remains whether we make it rotate to match the closed ebook mode or match the rotated opened-like-a-book mode. there's no good answer to this, because there's no way to make it do the right thing automatically. the lid switch can't be used, because by definition the laptop isn't really in ebook mode when you're trying to use the touchpad. there's no way for the laptop to tell that the screen is flipped around, which is what's needed. user configuration might be possible, but frankly, i'd just default it to match the opened mode. i've gotten used to (in almost-ebook mode) moving my finger opposite to the direction i want the pointer to move, and i never rotate the screen in that mode precisely because of the rotation issue. so it would be a win just to have the finger-to-pointer relationship be predictable, even if it's not right. paul =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Screen rotation -- My two cents
james wrote: I have experienced the frustration of trying to use the mouse pad when in ebook mode (actually not quite ebook mode, since you have to open the XO a bit to get your finger on the mousepad). The reason I need to do it is that when I'm using View Slides the enormous mouse arrow blocks part of the picture on the screen, so I want to move it out of the way. What would be far better would be to have the mouse pointer simply hide itself when the mouse pad or mouse hasn't been used in awhile. It would $ yum install unclutter $ unclutter (and add it to .xsession) =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: rotate button sucks on the XO
while i can understand the frustration when something that seems simple and obvious doesn't work, starting wout with sucks probably isn't the best way to get people to listen to your issues. how do other people feel about this problem? are there any good reasons to _not_ make the touchpad rotate with the screen? (i actually think this might be an almost, but not quite, trivial addition to the grab key daemon i mentioned to the list last week. matching the touchpad orientation to the orientation of the screen initially would be the tricky part -- if they were out of sync, it'd be a real drag.) noiseehc wrote: Hello! Just today I have noticed some things about the rotate button (which is below the directional buttons on the display part): 1. When the screen is rotated the mouse does not so if I turn the XO to be able to read letters, I cannot navigate with the mouse. 2. An Xvideo RGB overlay displays the big nothing (black) while the screen is rotated. If somebody will fix it to be usable then it would be a good idea to program the rotate button so that holding pressed for 2 seconds would turn on-off the backlight (color to mono and back). is this simply to make the backlight controllable from ebook mode? because shift-increase and shift-decrease (or is it ctrl?) accomplish this pretty simply now. paul =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: rotate button sucks on the XO
eben wrote: Start with the most basic, and build up. There's a limited set of buttons there; that's something to be dealt with. Video game consoles have done a pretty good job with similar limitations. At least in the 90s they did. These days they've caved in to many more buttons. game consoles also had/have reliable buttons. i find that fine-grained control of direction, or even of number of actual presses, is nearly impossible with the d-pad -- that's why i came up with the toothpick mod. that helps a lot, but it's still not perfect. (in contrast, the individual check/circle/etc buttons work fine.) i have no problem with the idea of creating good APIs for doing navigation with the bezel controls. but like david, i think that currently neither olpc nor sugarlabs is going to foster or champion their use: olpc has no resources for s/w development, and as far as i can tell, sugarlabs is targeting other h/w platforms just as strongly as the XO -- and other platforms don't have these screen issues. in any case, so far i've heard no good argument against rotating the touchscreen to match the screen. it may not be the most convenient way to use or hold the laptop, but it would be better than the current situation where screen rotation makes the touchpad almost completely useless. (btw, i would _love_ it if Browse sprouted a prev-link/next-link/ follow-link/back-to-previous interface, for arrow key control, just like lynx or elinks has. it would be faster to use than the touchpad in most cases even in regular laptop orientation.) paul =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] OS/X11 support for XO-1 hardware?
benjamin m. schwartz wrote: There are lots of good reasons to play with screen resolution. My favorite reason is that reducing the resolution to 800x600 would make all graphical operations runs twice as fast, and use half as much memory, while introducing a negligible drop in display quality (the display, remember, is not _really_ 1200x900 in color mode; the total number of color elements is equivalent to 800x450). not to mention the compatibility improvements with previously tuned desktop environments: in a conversation with erig garrison late last year, he pointed out that the absolutely best way to make XFCE look good on the XO display was to simply scale the display so that its dimensions were closer to what the designers used. no more unclickable icons, no more unreadable text. paul =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
bert wrote: On 24.02.2009, at 19:09, Carol Farlow Lerche wrote: ... Asking for better documentation doesn't imply that the facility is new. It recognizes that development has reached a local minimum in an important component that is not well understood by many. My post was a request to the most knowledgeable person, Michael to do the service of taking the time to write a document that clearly lays out . the purpose (not in security speak but in terms of the benefits it brings to end users), for my part, i've always felt that it's this first point of carol's that's been missing from the docs. the functional overview is very important: as a developer, you're asking me to implement a bunch of new API functionality simply to make a simple program (which may already be working well in most other unix environments) functional. i'd like to be sold on the concept first, before having to do a bunch of work for no (apparent) benefit to me or my program. paul =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Opportunity for speedup
mitch wrote: Bobby Powers wrote: - its designed to be as light as possible, using syscalls instead of libc functions as much as possible (the only thing we use libc for is string comparison, which could be replaced with a local function). while its written like this, I haven't worked on cutting down the linking (I need some guidance for that) great stuff bobby -- i'm happy to help with any remaining details if you like. To reduce the execution footprint, you could try linking it against dietlibc, http://www.fefe.de/dietlibc/ I'm not sure just how much time that would save; maybe it wouldn't be significant. But it's worth a try. my gut says that using already present glibc shared lib will be cheaper than introducing a new library, even if it's small and static. but you're right it's worth a try. and source is avail at http://dev.laptop.org/git?p=users/bobbyp/bootanim i took a very brief look. as a favor to future maintainers, i think you could either a) merge boot-anim-start/client/stop and ul-warning into a single executable (much of the code is the same) or b) extract the common parts (e.g. initial_setup(), and the code that mmaps the framebuffer) into a boot-anim-utils.c or something like that. (and while i'm all for reducing dependencies, the XO has so much else going on that i don't think using against string libraries or even stdio will affect things much in the greater scheme of things. so i'd have used fputs rather than write(2,...) for errors. but i understand the intent.) paul =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: new mailing list for other distros?
da...@lang.hm wrote: On Wed, 18 Feb 2009, qu...@laptop.org wrote: On Wed, Feb 18, 2009 at 04:14:05PM +0800, Carlos Nazareno wrote: I will have my two XO's there, I will try to have them running different flavors of DebXO (from USB sticks if nothing else, but quite possibly from the NAND), since the future direction is to have them run relativly standard distros, having examples of the different distros would be nice. Would it be good to create a new separate mailman developer list for non XO OS (Fedora + Sugar) other linux distro ports? (debxo, ubuntu xo, fedora xo etc) And then keep devel for main XO OS to avoid clutter? I disagree. There is no clutter now, and concentrating all the XO hardware related discussions here is very valuable. Splitting by distribution would halt collaboration. I'd go further and say that things are already too fragmented. the fact that the DebXO maintainer didn't know that much of the discussion that he needed to know about had migrated to a fedora mailing list is not a good sign. i'm unaware of that particular case, but i agree completely on this point. it would be far far better to eliminate lists than create new ones at this point. paul =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: price point + sales to individuals
bert wrote: On 18.02.2009, at 18:01, John Watlington wrote: We already have a developer program where we give away laptops to interested people. This is for people already committed, already part of the community. It's a great program, I got my XOs from it. it's also only great when it's operational. i have no knowledge of its current status, but there have been many complaints in the last year or so that the program had stagnated. paul =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: power consumption after shutdown
frederick wrote: In a discussion thread like this, it would good to have a source code link for all to reference, now and in the future. Thanks for all the contributions! unfortunately, the code in question (i.e., the EC firmware) is one of the few small bodies of code on the XO which isn't open. paul On Mon, Feb 16, 2009 at 3:36 AM, James Cameron qu...@laptop.org wrote: On Mon, Feb 16, 2009 at 12:19:41AM -0500, Richard A. Smith wrote: qu...@laptop.org wrote: (If one discharges an XO battery outside the XO using a home lighting circuit, the displayed state of charge will be inconsistent. Persisting in this practice results in increasing inconsistency. Ceasing the practice results in decreasing inconsistency over several XO moderated charge and discharge cycles. The inconsistency results in forced power-down before the state of charge would suggest, manifesting as my XO stops too soon.) How far off is it? The EC actually tries to detect this. The ACR register will decrease when you use the battery outside the laptop. Last I checked, some months ago, it was no more than about 30% error. I didn't proceed with the test beyond about that point. Good to know it tries to do something about it. -- James Cameronmailto:qu...@us.netrek.org http://quozl.netrek.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel part 2 text/plain 129 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Treatise on Formatting FLASH Storage Devices
da...@lang.hm wrote: On Wed, 4 Feb 2009, Mitch Bradley wrote: http://wiki.laptop.org/go/How_to_Damage_a_FLASH_Storage_Device Read it and weep. this completely ignores wear leveling, which is very nessasary for just about any filesystem, but especially for FAT (which appear to be the only filesystems this author is familiar with) all in all this doesn't seem like a very useful page. since i'm 99% sure that mitch wrote that page, let me be the first to disagree. :-) i believe that everything he's said is completely spot on. i confess i wasn't conscious of the partition vs. erase block alignment issue until a couple of months ago when i first heard mitch mention it, but i'm absolutely sure the effect is real. paul =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: keyboard handling (was Re: OLPC where to go development advice.)
s wrote: Summary: I updated http://wiki.laptop.org/go/Enabling_XO_features_on_other_distributions http://wiki.laptop.org/go/Keyboard_shortcuts and several other pages, but mysteries remain. p...@laptop.org usefully responded: I have zero clue where to find the keymapping file or configuration utility. i just booted ubuntu to see how they do it -- turns out it's easy. they use a program called xbindkeys to bind all of the special XO keys. the configuration for that is in /home/olpc/.xbindkeysrc -- you'll see an entry in there that invokes /usr/bin/rotate_screen.py. I added this to http://wiki.laptop.org/go/Enabling_XO_features_on_other_distributions Folks, this is the page where distros note their tweaks for the benefit of humanity. I think Sugar doesn't use that technique. ... but i've been wondering if perhaps it should. given that sugar is now multi-platform, does it make sense for sugar itself to be managing the special XO keyboard keys? seems like pulling that support out would let it be reused by non-sugar distros more readily. what happens when you press F9 through F12 when running SoaS? (i think those are the volume and brightness keys on the XO.) paul =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: OLPC where to go development advice.
paul wrote: Thanks for all the advice, I've gotten ubuntu installed. One OLPC question and one GTK question OLPC: where exactly is the keyboard mapping file that would let me change the behavior of the screen orientation button? this will be different under ubuntu-on-XO, i believe. are you trying to get it to rotate? or to do something else? there seem to be some tips, and a start on the how to get it to rotate topic here: http://www.olpcnews.com/forum/index.php?topic=2240.0 Its missing the gio headers. specifically #includegio/gio.h dpkg -S gio.h on my thinkpad install of ubuntu intrepid implies that gio.h should be /usr/include/glib-2.0/gio/gio.h, and comes from libglib2.0-dev. paul =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Touchpad problem
bernie wrote: Daniel Drake wrote: 2009/1/31 Tiago Marques tiago...@gmail.com: Almost already as I started using it, I noticed that sometimes the touchpad would be irresponsive. I may use it for hours without having a problem but, when it happens, it usually doesn't start working again soon. Which OS version are you using? I'm assuming 8.2.0. This is fixed for 8.2.1, perhaps you'd like to join the testing effort? What does the fix do? I thought it was not fixable in software. i asked dan the same thing. the only true fix i know of in 8.2.1 keeps the touchpad from locking up entirely on occasion. this happens only rarely in earlier releases (and can be corrected by suspending/resuming the laptop). the other fix in 8.2.1 for the touchpad is not really a fix -- it's really more of a bandage that the user can unwrap and apply themselves (and even then, it only hides the cut, and doesn't help it heal :-). the touchpad driver in 8.2.1 has more tuneables, which allow reducing some of the pre/during/post- recalibration delays. all this does is make the touchpad failures less annoying. here's an earlier email (oddly, google's not finding it for me at laptop.org) -- http://n2.nabble.com/touchpad-tunables-td2138474.html paul =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: OLPC where to go development advice.
paul wrote: this will be different under ubuntu-on-XO, I want to write some code that runs in Tablet mode and I need one more key. So I want to disable the screen rotation. Currently even under ubuntu it rotates the screen. I'm a linux newbee so I have zero clue where to find the keymapping file or configuration utility. you're doing pretty well for a newbie. i just booted ubuntu to see how they do it -- turns out it's easy. they use a program called xbindkeys to bind all of the special XO keys. the configuration for that is in /home/olpc/.xbindkeysrc -- you'll see an entry in there that invokes /usr/bin/rotate_screen.py. all you need to do is change that to point at your own script or program. dpkg -S gio.h on my thinkpad install of ubuntu intrepid implies If I include that path it is now looking for glibconfig.h and dpkg -S glibconfi.h responds with libglib2.0.dev: /usr/lib/glib-2.0/include/glibconfig.h A dierectory that does not exist. So this probably means I need to install the libglib2.0.dev package right?? yes. though you meant libglib2.0-dev. in general on debian and ubuntu, to development of a program that needs a library, you'll need to have the -dev package for that library installed. paul =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: OLPC where to go development advice.
i wrote: i just booted ubuntu to see how they do it -- turns out it's easy. they use a program called xbindkeys to bind all of the special XO to be clear, they isn't ubuntu. they is the person (who goes by the moniker teapot) who put together binary release you downloaded. a pure ubuntu would probably not be using xbindkeys. in that vein -- if you need much more help with your release, you're welcome to hang out here and ask for help, but you may get more help from the folks over on http://www.olpcnews.com/forum -- people over there probably have more experience with teapot's ubuntu than people here. paul =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Touchpad problem
daniel wrote: 2009/2/1 p...@laptop.org: i asked dan the same thing. the only true fix i know of in 8.2.1 keeps the touchpad from locking up entirely on occasion. this happens only rarely in earlier releases (and can be corrected by suspending/resuming the laptop). That's what I'm referring to. Details are a little unclear but I think that Tiago is describing the exact problem that you fixed where recalibration fails and the mouse stops. I think this is a fair assumption given how often this seems to happen... ah -- sorry. i misread his symptoms. paul =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: OLPC upgrades
samuel wrote: On Fri, Jan 30, 2009 at 9:18 AM, Frank Ch. Eigler f...@redhat.com wrote: Mitch Bradley w...@laptop.org writes: [...] It's also worth pointing out that the new low-power x86 processors, Atom being the poster child, are still stuck with power-hungry support chips - memory and display controllers. That might change soon, but for now it's still the case. [...] According to the ACPI battery gauges under Fedora 10, my Fujitsu U820 UMPC (Atom Z530, Poulsbo GMA500 MCH/graphics) takes around 6W *total* during light webby operations. What do those same gauges tell you about an XO under F10? unless things have changed, those same gauges won't exist on the XO -- we don't do acpi. paul =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Backlight control
marco pesenti gritti wrote: On Sat, Jan 24, 2009 at 5:23 AM, John Watlington w...@laptop.org wrote: What can I call from an activity (in python) to indicate that the backlight should be turned off ? I'm playing with a photoframe app, and want to have the ability to deliberately control the backlight level from the UI. See http://git.sugarlabs.org/projects/sugar/repos/mainline/blobs/master/src/jarabe/m odel/screen.py i've eventually come around to the notion that brightness requests all need to be brokered by ohmd (partly because the /sys nodes in question need root access, and partly because ohmd needs to track user requests so it can do intelligent dimming). but if ohmd is going to be in the middle, then the published api for requesting those changes should be more transparent than requiring every application be in python and have knowledge of dbus. that code in screen.py should a) be reimplemented in C (or shell? via dbus-send?) to remove the python dependency -- it should have no more system dependencies than ohm itself, and b) be installed in /usr/bin as a standalone executable. it should probably be packaged with ohmd itself. then the api for program's like wad's would be a simple program invocation. (i know running a program sounds expensive, but i can't at the moment think of another completely generic, language neutral mechanism -- dbus would still be available for apps that wanted to use it, of course.) the same could be argued for any of the system tuning knobs that ohmd provides -- imagine the problem faced by anyone trying to implement a non-sugar distribution on the XO: the mechanisms for turning those knobs should be as lightweight and generic as possible. paul =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Backlight control
tomeu wrote: On Sat, Jan 24, 2009 at 15:50, Marco Pesenti Gritti marc...@sugarlabs.org wrote: On Sat, Jan 24, 2009 at 3:43 PM, p...@laptop.org wrote: but if ohmd is going to be in the middle, then the published api for requesting those changes should be more transparent than requiring every application be in python and have knowledge of dbus. There is no python dependency and I personally have no problems with a right -- there's only a python dependency in that when someone asks how do i change the brightness, they're pointed to python code. :-) dep on dbus. Leaving aside technical considerations about dbus, pretty much everything in the desktop land requires it these days (and ohm is heavily based on it afaik). It's not worth to resist the flow ;) perhaps that's true for dbus. but it's too much of that thinking that makes the current XO distributions as slow as they are. :-/ btw, in the code marco pointed to: http://git.sugarlabs.org/projects/sugar/repos/mainline/blobs/master/src/jarabe/model/screen.py it looks like there's a missing assignment to _ohm_service (i.e., to save the connection so it doesn't need to be recreated each time). am i mis-reading? paul =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Backlight control
marco pesenti gritti wrote: On Sat, Jan 24, 2009 at 4:07 PM, p...@laptop.org wrote: http://git.sugarlabs.org/projects/sugar/repos/mainline/blobs/master/src/jarabe/m odel/screen.py it looks like there's a missing assignment to _ohm_service (i.e., to save the connection so it doesn't need to be recreated each time). am i mis-reading? Ouch, please ticket it, thanks. (dev.sugarlabs.org). done =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Backlight control
michael wrote: David -- why quibble over ohm when you've got NM and HAL to worry about? Paul -- why are the /sys nodes only writable by root? discounting, possible denial-of-brightness attacks by malicious screen hackers, no particularly good reason that i know of. well, other than ensuring that ohmd is, indeed, used to broker changes to those values. on the other hand, i'm not sure whether there's a precedent for opening up permissions under /sys -- i find no non-root-writeable nodes on any of 4 machines i just tried. paul Michael On 1/24/09, da...@lang.hm da...@lang.hm wrote: On Sat, 24 Jan 2009, Marco Pesenti Gritti wrote: On Sat, Jan 24, 2009 at 3:43 PM, p...@laptop.org wrote: but if ohmd is going to be in the middle, then the published api for requesting those changes should be more transparent than requiring every application be in python and have knowledge of dbus. There is no python dependency and I personally have no problems with a dep on dbus. Leaving aside technical considerations about dbus, pretty much everything in the desktop land requires it these days (and ohm is heavily based on it afaik). It's not worth to resist the flow ;) so is there a standard that says that every desktop must use dbus now? If so I missed the memo. I don't have much of a problem with any individual desktop deciding they want to use dbus (gnome, kde, etc) as I still have the choice to use other systems (lxde, windowmaker, etc) but to make fundamantal control of the hardware require dbus seems like a signficant step. David Lang ___ 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 =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Backlight control
marco pesenti gritti wrote: On Sat, Jan 24, 2009 at 4:07 PM, p...@laptop.org wrote: right -- there's only a python dependency in that when someone asks how do i change the brightness, they're pointed to python code. :-) Well... Wad needed it for a python activity. And even if you need to write it in another language, the example is useful for illustrative reasons. It would have been the same if I pointed someone to a C implementation, when he needed it in python or javascript. i missed that wad needed the code for python in the first place. paul =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Lighttpd problem
rodrigo padula de oliveira wrote: Hello Guys, I've installed lighttpd in my XO, but when i restarted them, i cant start the lighttpd service again. The problem is with the log files on /var/log/lighttod. The system clean this folder when restarting ? yes. /var/log is in a ramdisk. i think you can force your directory to be created at boot by adding it to /etc/rwtab (but i've never tried this myself). paul =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Lighttpd problem
rodrigo padula de oliveira wrote: p...@laptop.org escreveu: rodrigo padula de oliveira wrote: Hello Guys, I've installed lighttpd in my XO, but when i restarted them, i cant start the lighttpd service again. The problem is with the log files on /var/log/lighttod. The system clean this folder when restarting ? yes. /var/log is in a ramdisk. i think you can force your directory to be created at boot by adding it to /etc/rwtab (but i've never tried this myself). Hi Paul. I added the files and directory to be created at boot in the file /etc/rwtab, but it isn't working, files and directory not created! sorry rodrigo -- i guess i may have misled you. i see that there are other directories mentioned in that file which aren't created at boot either. perhaps i misunderstood what that file is for, though reading rc.sysinit i would have thought i was right. in any case, perhaps you can simply add a mkdir -p /var/log/lighttpd to the lighttpd startup script. seems like the easiest solution. paul =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: OLPC trac not allowing login?
gary c martin wrote: Any one else getting Invalid username or password errors trying to log in to trac? https://dev.laptop.org/login yes. me too. =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Nand blaster with 30 XOs
ricardo wrote: Mitch, Nandblaster is a blast! We updated 29 XOs in less than 30 minutes (most in less than 20 minutes). neat. Just one XO froze (two times), but this unit seems problematic anyway. I am attaching the stats for the other 28. There is a minor caveat (that is not actually related to the nandblaster): Once you finish updating the XO that will be replicated it woud be useful to put it in a state such that the XO-name and color will be asked again after boot (otherwise you finsh with a lot of xos with the same name and color). It is probably a matter of removing a file. if you've booted the XO, there's more than that that's been cloned which might be a problem. (ssh host key, for example.) you should really nandblast images that haven't been booted. (erikg: did you finish your audit of what exactly gets changed?) paul =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
touchpad tunables
current staging releases (9 and higher, i believe) contain some new parameters which were added to the mouse driver. these settings allow tweaking various timeouts related to touchpad recalibration. (i'd appreciate it someone running an 8.2.1 staging candidate could verify these parameters really are present -- i'm running a development kernel.) by default the timeouts related to various recalibration delays are quite conservative, leading to a total delay of 3 or 4 seconds while the touchpad autodetects jumpiness, waits before commencing recalibrating, recalibrates, and waits to be sure no motion was detected during the recal. i've been using the following script on my own XO for several weeks -- it doesn't keep the touchpad from going bonkers, but when it does, it recovers quite a bit more quickly. after choosing these initial values, i didn't do any more tuning. if someone would like to further investigate/improve, i'd welcome the changes. extra brownie points if you can get the touchpad to quit needing recalibration at all! :-) i'm not quite sure where/whether/when this should go into a release, but figured i should at the very least publish it here. paul #!/bin/sh # the available touchpad parameters are as follows. many do not # make sense and/or do nothing on the XO: #tpdebug:(int) #recalib_delta:packets containing a delta this large will # cause a recalibration. (int) #jumpy_delay:delay (ms) before recal after jumpiness detected (int) #spew_delay:delay (ms) before recal after packet spew detected (int) #recal_guard_time:interval (ms) during which recal will be # restarted if packet received (int) #post_interrupt_delay:delay (ms) before recal after recal # interrupt detected (int) #autorecal:enable recalibration in the driver? (int) #proto:Highest protocol extension to probe (bare, imps, exps, any). # Useful for KVM switches. (proto_abbrev) #resolution:Resolution, in dpi. (uint) #rate:Report rate, in reports per second. (uint) #smartscroll:Logitech Smartscroll autorepeat, 1 = enabled (default), # 0 = disabled. (bool) #resetafter:Reset device after so many bad packets (0 = never). (uint) #resync_time:How long can mouse stay idle before forcing resync # (in seconds, 0 = never). (uint) p=/sys/module/psmouse/parameters if [ $(whoami) = root ] then echo must be root 2 exit 1 fi ( echo Before: ; grep ^ $p/* ) /tmp/cur_psmouse_params if [ $1 = show ] then cat /tmp/cur_psmouse_params exit fi echo Setting mouse parameters: # all values in milliseconds echo 200 $p/jumpy_delay echo 200 $p/spew_delay echo 400 $p/recal_guard_time echo 100 $p/post_interrupt_delay ( echo After: ; grep ^ $p/* ) | diff /tmp/cur_psmouse_params - exit =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: touchpad tunables
sigh. when am i going to learn not to tweak shell scripts in my mailer buffer i wrote: if [ $(whoami) = root ] please change that to if [ $(whoami) != root ] paul =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: touchpad tunables
gary c martin wrote: Hi Paul On 10 Jan 2009, at 17:29, p...@laptop.org wrote: (i'd appreciate it someone running an 8.2.1 staging candidate could verify these parameters really are present -- i'm running a development kernel.) Not sure if this helps, but just looked in /sys/module/psmouse/ parameters/* on an XO here running Sugar 0.82.1, Build 7, Firmware Q2E24 (not quite the v.latest so something new could have crept in). I see: thanks gary. i believe the new vars made it into staging 9. paul autorecal rate resetafter resync_time tpdebug proto recalib_delta resolution smartscroll Was assuming to see the new parameters your echoing to listed, so I'm assuming they are not in yet, will check again when I re-flash with the v.latest staging build. --Gary =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Leaving
tomeu wrote: On Fri, Jan 9, 2009 at 09:07, Edward Cherlin echer...@gmail.com wrote: On Thu, Jan 8, 2009 at 10:50 PM, C. Scott Ananian csc...@cscott.net wrote: Like many others, Friday will be my last day employed by OLPC. I've enjoyed working on the project a lot, and hope to find some way to continue the work that has been begun. I'm very sorry to hear that. Will you be able to attend XOCamp2? The next release of Sugar appears to be left hanging, with no comment from management. I find this appalling. Did you really meant Sugar? Or OLPC? the official announcement did a disservice by repeating the conflation of the terms sugar and XO release. they're obviously quite related, but it's really the latter that i suspect edward was referring to. paul =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
see ya'
like many others, today is my last day at OLPC. my short tenure here has been loads of fun, and it's been an honor to be close to the center of such a great project. i'll be around -- please stay in touch. to the extent i can, i'll be following the lists, and dropping in on irc once in a while. richard and i have agreed that since i've already tainted myself by working with the sooper seekrit EC firmware, and i'm still effectively under NDA, that there's no reason i shouldn't continue to be a resource for questions and help in that area, if anything should come up where richard's not around, or whatever. hope i can help out somehow. my home address is p...@laptop.org, but pgf (or paul) @laptop will continue to work for some time, i believe. paul =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: see ya'
oops jameson wrote: my home address is p...@laptop.org, but pgf (or paul) @laptop will continue to work for some time, i believe. I believe your fingers didn't type what your brain was thinking. yes, i meant to type p...@foxharp.boston.ma.us paul =- paul fox, p...@foxharp.boston.ma.us (arlington, ma, where it's 26.8 degrees) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Fwd: Flash plugin not recognised by Firefox on the OLPC
shivaprasad wrote: Ok. I tried installing from the link given in the Firefox page of the OLPC wiki ( http://wiki.laptop.org/go/Firefox ) . It works fine if I install it from a .tar.gz file but doesn't if it is installed from a .rpm file? Any ideas? i think i already said something about this in private mail to you, but again, so no one else needs to reply: the RPM version installs the flash extension to a different place than the install-flash script provided with the firefox activity. it does this because the firefox activity doesn't look for extensions in the usual place. (i can't speak to whether or not it would be possible to trick the activity into using the standard locations -- but it doesn't currently.) paul -- Forwarded message -- From: shivaprasad javali jbs...@gmail.com Date: Tue, Jan 6, 2009 at 9:20 PM Subject: Fwd: Flash plugin not recognised by Firefox on the OLPC To: OLPC Devel Devel@lists.laptop.org The Flash rpm given at that link will install flash plugin's for all browser's including Firefox right? or do I need to install it seperately as given in this link http://wiki.laptop.org/go/Firefox . -- Forwarded message -- From: shivaprasad javali jbs...@gmail.com Date: Tue, Jan 6, 2009 at 8:35 PM Subject: Flash plugin not recognised by Firefox on the OLPC To: OLPC Devel Devel@lists.laptop.org Hi, I installed Firefox on my OLPC from the All activities page. And then installed flash from the following link http://wiki.laptop.org/go/Adobe_Flash#Installation . I don't have a Wi-Fi router so I downloaded the .xo and rpm on my windows machine and then transferred them over to the OLPC and installed them. I wanted to view some flash content that I had so when I opened them in Firefox I got a message saying Flash Player is not installed. To double check I typed rpm -qa at the terminal and it showed that Flash has been installed. The flash content works fine on the Browse activity but not in flash. I tried uninstalling GNASH with the same result. I know that the flash content works fine with firefox because it works fine with firefox on my linux machine. So can any body tell me what else the problem might be? Thanks jbsp72 part 2 text/plain 129 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel =- paul fox, p...@laptop.org give one laptop, get one laptop --- http://www.laptop.com/xo ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Fedora Desktop on XO
chris wrote: Hi Peter, How did you go with this? Did you have any luck? I also realised that if you drop gnome-user-share you'll drop all the httpd requirements. Yep, it worked! I had RPM conflicts in GConf2 (against GConf2-dbus, both ship the same .mo files) and evince (against sugar-evince, both ship the same evince backend shared libraries). Also, it turns out that evince-dvi is responsible for bringing in texlive, via kpathsea. Here's the command I'm using now: -bash-3.2# yum -y install NetworkManager-gnome alacarte at-spi bug-buddy control-center eog file-roller gcalctool gdm gdm-user-switch-applet gedit gnome-applets gnome-audio gnome-backgrounds gnome-media gnome-panel gnome-power-manager gnome-screensaver gnome-session what happens when you push the power button? i assume the laptop will suspend due to ohmd, but i think g-p-m is doing the same dbus listen, no? paul =- paul fox, p...@laptop.org give one laptop, get one laptop --- http://www.laptop.com/xo ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Devel Digest, Vol 34, Issue 86
mitch wrote: d...@laptop.org wrote: On Tue, Dec 23, 2008 at 8:08 PM, p...@laptop.org wrote: ssh host keys are probably generated on first boot as well. with partitioning support, it should be possible to have a r.o. root overlaid by a unionfs writeable mount, so machine-specific changes don't modify the released partition. this would make cloning quite a bit easier, i'd think. i have no idea what the performance hit of a unionfs setup would be, nor how such a partitioning would fit into the rest of the update strategy (e.g. olpc-update). unionfs isn't upstream and was quite unreliable last time I use it. Puppy Linux has used unionfs for some time, apparently with good results. And it adds the challenge of differentiating state that must be discarded for the cloned image, and state that must not be. Uh, is it really unionfs that adds that challenge? I would think that the need to differentiate between wanted and unwanted state is a fundamental requirement of the cloning approach, regardless of whether or not unionfs is part of the implementation strategy. right. the process of preparing an image which is suitable for distribution will always be more complex than simply booting, configuring, and shutting down. it might involve mounting an external copy of the image and modifying it without running it, for instance. but once the image has initially been made suitable for cloning, using something like unionfs would allow that image to _remain_ suitable for cloning -- clonable from any laptop on which it's installed. paul =- paul fox, p...@laptop.org give one laptop, get one laptop --- http://www.laptop.com/xo ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Deployment image customization
morgan wrote: On Tue, Dec 23, 2008 at 18:29, Daniel Drake d...@laptop.org wrote: On Tue, Dec 23, 2008 at 2:19 PM, Greg Smith gregsmitho...@gmail.com wrote: ... The biggest challenge I see is to find those things which you do not want to clone from the source XO. The only things that come to mind are Name and Color. We could even pre-fill them as long as those dialog boxes come up at start up. There is a lot more than that - it's things that are invisible to the user, technical details of the system, which are the bits we don't have a good answer for. For example (an easy one), keys are generated on first boot, but it is potentially bad news down the line if multiple XOs have the same keys. The hard part is tracking these things, which are not specified anywhere and there's no one place you ... I believe the mail from Michael that you were looking for is http://lists.laptop.org/pipermail/devel/2008-March/012200.html - and http://lists.laptop.org/pipermail/devel/2008-April/012957.html is probably also relevant. The keys generated in ~/.sugar/default/ are AFAIK not used for crypto, but are used to generate the unique Jabber ID (JID). If two XOs (or Sugar clients) have the same keys, Strange Bad Things happen to presence and collaboration. ssh host keys are probably generated on first boot as well. with partitioning support, it should be possible to have a r.o. root overlaid by a unionfs writeable mount, so machine-specific changes don't modify the released partition. this would make cloning quite a bit easier, i'd think. i have no idea what the performance hit of a unionfs setup would be, nor how such a partitioning would fit into the rest of the update strategy (e.g. olpc-update). paul =- paul fox, p...@laptop.org give one laptop, get one laptop --- http://www.laptop.com/xo ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Deployment image customization
daniel wrote: On Tue, Dec 23, 2008 at 8:08 PM, p...@laptop.org wrote: ssh host keys are probably generated on first boot as well. with partitioning support, it should be possible to have a r.o. root overlaid by a unionfs writeable mount, so machine-specific changes don't modify the released partition. this would make cloning quite a bit easier, i'd think. i have no idea what the performance hit of a unionfs setup would be, nor how such a partitioning would fit into the rest of the update strategy (e.g. olpc-update). unionfs isn't upstream and was quite unreliable last time I use it. And it adds the challenge of differentiating state that must be discarded for the cloned image, and state that must not be. For example, we would want to ssh keys generated during first boot to *not* be included in the clonable image, that's obvious. But if the user boots the OLPC image, goes into the control panel and sets a language, then we *do* want that language change to be included in the clonable image that is the output of the process. How would the system differentiate between those two? i dunno. i guess the lead engineer on the project would have to decide. :-) paul =- paul fox, p...@laptop.org give one laptop, get one laptop --- http://www.laptop.com/xo ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Activities] Colors!-v13 released
hi wade -- how does colors deal with the lack of wacom support in the kernel? do you bundle a driver module? paul wade wrote: Hey all, I have released Colors! version 13 with improved Wacom tablet support. Painting has been optimized, refresh bugs have been fixed, a color pickup feature has been added, and numerous polishing tweaks have been made to the UI. http://dev.laptop.org/~wadeb/Colors!-13.xo Testing and feedback are welcome, as always. The wiki page will be updated once the server comes back up! Best, Wade Note: There are still some minor known bugs in collaboration. I'm having a hard time getting my XO VM and my real XO to see each other. But I hope to make another release which resolves these issues before long. =- paul fox, p...@laptop.org give one laptop, get one laptop --- http://www.laptop.com/xo ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Downloading Scratch project to XO
philipp wrote: Hi Bert, John There is a bug in copy-from-journal, it is adding an additional dot before the file extension. Otherwise it is working. [o...@localhost ~]$ copy-from-journal -o 07474cf4-4883-4ded-a994-ab5511cfc29c /tmp/test.sb /home/olpc/.sugar/default/data/07474cf4-4883-4ded-a994-ab5511cfc29c - /tmp/test..sb My workaround in scratch-activity looks like this: if [ -n $object_id ] ; then filename=$SUGAR_ACTIVITY_ROOT/instance/temp.sb copy-from-journal -o $object_id $filename filename=$SUGAR_ACTIVITY_ROOT/instance/temp..sb else filename= fi will you file a ticket on this? (or perhaps at least update #5571.) paul =- paul fox, p...@laptop.org give one laptop, get one laptop --- http://www.laptop.com/xo ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Slimmed Down Fedora 10 on XO (was Fedora 10 on XO)
greg wrote: Hi All, Thanks for all the feedback on my questions about what it would take to run a slimmed down Fedora 10 on the XO NAND. https://www.redhat.com/archives/fedora-olpc-list/2008-December/msg00022.html To reiterate, the goal is one distribution with two Desktop Environments (Sugar and one standard one). I think the main work now is to pick the minimal package list that we need and will fit on the XO NAND. Can anyone get a slimmed down Fedora 10 with window manager running on an XO? yes. install any joyride. i'm being flip, of course, but please be precise. our installs _are_ slimmed down fedora releases. and sugar _is_ a window manager. (but seriously: we only need to add to what we have -- we don't need to start from scratch, rebuilding and/or subtracting from fedora.) paul =- paul fox, p...@laptop.org give one laptop, get one laptop --- http://www.laptop.com/xo ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 8.2.1 Bug review meeting - 1 PM EST Friday 12/12/08
ed wrote: Folks - We¹re trying to get a very focused 8.2.1 release wrapped up to address a small number of problems affecting or blocking key country deployments of 8.2. A few bugs have been tagged for an 8.2.1 milestone (fifteen of them), i went looking for a canned report to find those 15 tickets for me. i found two: http://dev.laptop.org/report/34 and 35. clearly i don't understand how reports work, because they each return 323 tickets, in different orderings, 8 of which are marked as blockers. how do i get that list of 15? paul =- paul fox, p...@laptop.org give one laptop, get one laptop --- http://www.laptop.com/xo ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
