re: [support-gang] spectacular new XO-1.5 disassembly guides

2010-10-09 Thread pgf
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

2010-07-28 Thread pgf
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

2010-05-20 Thread pgf
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

2010-03-04 Thread pgf
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?

2009-05-29 Thread pgf
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: overhead in a G1G1 environment

2009-05-29 Thread pgf
martin wrote:
  On Thu, May 28, 2009 at 9:03 PM,  p...@laptop.org wrote:
   so the answer is no, it's not necessary.
  
  I'm hacking on olpc-update-query this week. I thought of offering a
  hook to disable it, but it's growing some useful features (even for
  unlocked machines).

can you expand on that?

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?

2009-05-28 Thread pgf
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

2009-05-28 Thread pgf
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

2009-05-18 Thread pgf
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)

2009-05-07 Thread pgf
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)

2009-05-07 Thread pgf
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

2009-05-02 Thread pgf
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?

2009-04-28 Thread pgf
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?

2009-04-28 Thread pgf
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?

2009-04-28 Thread pgf
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?

2009-04-28 Thread pgf
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?

2009-04-28 Thread pgf
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?

2009-04-28 Thread pgf
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

2009-04-27 Thread pgf
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?

2009-04-27 Thread pgf
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?

2009-04-27 Thread pgf
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

2009-04-26 Thread pgf
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

2009-04-25 Thread pgf
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

2009-04-25 Thread pgf
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

2009-04-21 Thread pgf
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

2009-04-21 Thread pgf
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

2009-04-20 Thread pgf
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

2009-04-20 Thread pgf
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

2009-04-20 Thread pgf
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

2009-04-20 Thread pgf
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


Re: [Server-devel] [Sugar-devel] Notes on service discovery XS/XO

2009-04-20 Thread pgf
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
___
Server-devel mailing list
Server-devel@lists.laptop.org
http://lists.laptop.org/listinfo/server-devel


powerd on XS?

2009-04-17 Thread pgf
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)

2009-04-13 Thread pgf
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)

2009-04-12 Thread pgf
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

2009-04-07 Thread pgf
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

2009-04-07 Thread pgf
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

2009-04-06 Thread pgf
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

2009-04-06 Thread pgf
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

2009-04-04 Thread pgf
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

2009-04-03 Thread pgf
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

2009-04-03 Thread pgf
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

2009-04-01 Thread pgf
 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

2009-03-22 Thread pgf
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

2009-03-20 Thread pgf
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

2009-03-19 Thread pgf
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

2009-03-16 Thread pgf
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

2009-03-16 Thread pgf
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

2009-03-14 Thread pgf
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

2009-03-14 Thread pgf
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

2009-03-14 Thread pgf
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

2009-03-14 Thread pgf
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

2009-03-13 Thread pgf
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

2009-03-13 Thread pgf
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

2009-03-12 Thread pgf
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

2009-03-11 Thread pgf
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]

2009-03-04 Thread pgf
[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

2009-03-04 Thread pgf
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

2009-03-04 Thread pgf
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

2009-03-04 Thread pgf
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?

2009-03-02 Thread pgf
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

2009-03-02 Thread pgf
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

2009-03-02 Thread pgf
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

2009-03-01 Thread pgf
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

2009-03-01 Thread pgf
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?

2009-02-26 Thread pgf
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?

2009-02-24 Thread pgf
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

2009-02-19 Thread pgf
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?

2009-02-18 Thread pgf
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

2009-02-18 Thread pgf
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

2009-02-16 Thread pgf
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: power consumption after shutdown

2009-02-14 Thread pgf
edward wrote:
  On Fri, Feb 13, 2009 at 8:38 PM, Chris Ball c...@laptop.org wrote:
   Hi,
  
  by default the wireless card remains alive to participate in a
  potential mesh network, disabling wireless should give you a lot
  more time.
  
   You're thinking of sleep mode, not the full shutdown that Mikus is doing.
  
  That's not how I learned it. The wireless was designed to remain
  active when everything else was off, in order to support mesh
  networking throughout a community. However, I don't see any

no.  not when the laptop is off.  as chris said -- only when
it's sleeping.

paul
=-
 paul fox, p...@laptop.org
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: power consumption after shutdown

2009-02-13 Thread pgf
benjamin m. schwartz wrote:
  -BEGIN PGP SIGNED MESSAGE-
  Hash: SHA1
  
  Mikus Grinbergs wrote:
   I take this to mean that *something* was draining some 
   power for the two days the XO was sitting in its shut down state.
  
  All rechargeable batteries lose stored energy over time.  The phenomenon
  is called self-discharge.  It is sometimes modeled as a large (but not
  infinite) resistance in parallel with the battery.

but self-discharge takes place whether a battery is installed in
the laptop or not.  i suspect what mikus is seeing is the effect
of the embedded controller (the EC) needing a small amount of
current in order to be able to observe the power button press,
which tells it to turn the rest of the system on.

mikus -- when you power up the system after two days, what does
sugar, or olpc-pwr-log, tell you about the state of the battery? 
i suspect it's pretty close to full, but that it needs a small
top up.  (which is why the light turns yellow.)

(i'm sure richard has numbers for the power-off drain from the
EC, and for the powered-off shelf life of a fully charged
laptop.)

paul
=-
 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

2009-02-04 Thread pgf
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.)

2009-02-02 Thread pgf
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.

2009-02-01 Thread pgf
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

2009-02-01 Thread pgf
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.

2009-02-01 Thread pgf
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.

2009-02-01 Thread pgf
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

2009-02-01 Thread pgf
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

2009-01-30 Thread pgf
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

2009-01-24 Thread pgf
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

2009-01-24 Thread pgf
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

2009-01-24 Thread pgf
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

2009-01-24 Thread pgf
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

2009-01-24 Thread pgf
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

2009-01-19 Thread pgf
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

2009-01-19 Thread pgf
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?

2009-01-18 Thread pgf
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

2009-01-12 Thread pgf
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

2009-01-10 Thread pgf

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

2009-01-10 Thread pgf
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

2009-01-10 Thread pgf
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

2009-01-09 Thread pgf
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'

2009-01-09 Thread pgf
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'

2009-01-09 Thread pgf
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

2009-01-06 Thread pgf
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

2009-01-06 Thread pgf
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

2008-12-24 Thread pgf
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

2008-12-23 Thread pgf
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

2008-12-23 Thread pgf
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


  1   2   3   >