Re: Wireless test results
On 16 Feb 2009, at 05:32, Chris Ball wrote: > Hi, > >> Last I checked, it was either the firmware or the kernel changes >> that did it. I posted my findings to the mailing list in the past >> two weeks. > > I think your findings actually say "it was either the firmware, > kernel, > or something else altogether". It'd be good to downgrade both at > once, > but still on candidate-800, so that we can check that at least *one* > of > the two is the problem. I should be asleep, but instead have been zigzagging through old http://xs-dev.laptop.org/~cscott/xo-1/streams/staging/ staging builds testing WPA and the dialogue cancel dance for the last 4hrs: 790 working 4 working 5 working 6 working <- 7 intermittent 11 intermittent 15 broken 800 broken Intermittent means it can occasionally associate with a WPA access point with no cancel dance, but usually I had to dance. Broken means I had to dance every time. One thing I noticed when testing the working 4, 5 and 6 that may help, is that if you do naughtily click an already connected WPA access point you'll get back to one round of the WPA cancel dance. If you make sure you first select 'disconnect' then click the AP again, you get correctly re-associated, no dance required. This suggests that clicking a connected AP should either do NOP, or should at least disconnect properly before trying to connect again. The sound you just heard was my head hitting the pillow :-) --Gary > Thanks, > > - Chris. > -- > Chris Ball ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Wireless test results
Hi, > Last I checked, it was either the firmware or the kernel changes > that did it. I posted my findings to the mailing list in the past > two weeks. I think your findings actually say "it was either the firmware, kernel, or something else altogether". It'd be good to downgrade both at once, but still on candidate-800, so that we can check that at least *one* of the two is the problem. Thanks, - Chris. -- Chris Ball ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: power consumption after shutdown
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. The EC periodically takes a snapshot of the SOC and the current ACR and saves it into the EEPROM. When you insert a battery the first thing it does is compare the current ACR vs the saved values and then roll the SOC up or down depending on the difference between the values. -- Richard Smith One Laptop Per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: power consumption after shutdown
qu...@laptop.org wrote: >> 3) If that battery had been sitting on the shelf (not in an XO) for >> a month -- what did I need to do to make it "topped off" ? > > Discharge it to 90% capacity, then charge it. q2e32 can help you out. In q2e32 I've pulled in some of my batman.fth stuff. As James mentions the EC won't try to charge if it thinks the battery is full because the battery full flag is set. I've added some commands that let you reset that flag. ok batman-start ok bg-clr-full-flag ok ec-reboot The EC should then charge your battery. -- Richard Smith One Laptop Per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Wireless test results (Was: Announcing the first 8.2.1 release candidate)
On Mon, Feb 16, 2009 at 03:48:17AM +, Gary C Martin wrote: > Any pointers? Last I checked, it was either the firmware or the kernel changes that did it. I posted my findings to the mailing list in the past two weeks. If you'd like to try some testing, try swapping the firmware file in /lib/firmware/usb8388.bin from the older build. After that, you could try swapping the old kernel in. I didn't get that far in my tests. -- James Cameronmailto:qu...@us.netrek.org http://quozl.netrek.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Wireless test results (Was: Announcing the first 8.2.1 release candidate)
On 16 Feb 2009, at 03:18, James Cameron wrote: > On Mon, Feb 16, 2009 at 03:05:59AM +, Gary C Martin wrote: >> Summary: 8.2.1 has regressed relative to 8.2 for WPA access points. >> You now have to enter the security string; it will fail to associate >> and prompt you for the security string again; you have to cancel this >> dialogue; it will start trawling for a mesh; you have to click the AP >> again; it will now connect. > > Good simplification of previous workaround, well done. Do we have an idea at which build this might have crept in? I'm just downloading 790 for a little regression testing (as it's easy for me to reproduce), I think after that it's out with the snake boots and butterfly net to start hunting through deepest, darkest, http://xs-dev.laptop.org/~cscott/xo-1/streams/staging/ Any pointers? --Gary > -- > James Cameronmailto:qu...@us.netrek.org http://quozl.netrek.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Wireless test results (Was: Announcing the first 8.2.1 release candidate)
On Mon, Feb 16, 2009 at 03:05:59AM +, Gary C Martin wrote: > Summary: 8.2.1 has regressed relative to 8.2 for WPA access points. > You now have to enter the security string; it will fail to associate > and prompt you for the security string again; you have to cancel this > dialogue; it will start trawling for a mesh; you have to click the AP > again; it will now connect. Good simplification of previous workaround, well done. -- James Cameronmailto:qu...@us.netrek.org http://quozl.netrek.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Wireless test results (Was: Announcing the first 8.2.1 release candidate)
On 10 Feb 2009, at 23:53, Chris Ball wrote: > Some particular areas we'd like to see testing of: > > * Connecting to encrypted wireless access points. We believe there > are > regressions here that we're trying to understand. The test procedure > is: > - connect to a WEP/WPA AP > - suspend/resume using the power button, see what happens > - reboot, see what happens > > Some hypotheses we're trying to investigate are: > - WEP always works > - WPA works with some percentage chance of success > > You can read more about the wireless testing that's been done > already: >http://lists.laptop.org/pipermail/devel/2009-February/023096.html >http://lists.laptop.org/pipermail/devel/2009-February/022993.html Here's my wireless results for 8.2.1 candidate-800. Tested 6 times in a row for open access, WEP, and WPA, and some misc. comparative runs with an XO running 8.2. Access point is a D-Link DSL-G604T (Wireless ADSL router). Summary: 8.2.1 has regressed relative to 8.2 for WPA access points. You now have to enter the security string; it will fail to associate and prompt you for the security string again; you have to cancel this dialogue; it will start trawling for a mesh; you have to click the AP again; it will now connect. Open access == First connection: 4 successful auto associations, 2 times a 2nd click on the AP was required before it would associate. After OS reboot: 5 successful auto associations, 1 failed to re- associate and required clicking the AP. After restart of Sugar UI: 6 successful auto associations. After sleep: 5 successful auto associations, 1 failed to re-associate and required clicking the AP. WEP security == First connection: 6 successful WEP dialogue followed by association. After OS reboot: 6 successful auto associations. After restart of Sugar UI: 6 successful auto associations. After sleep: 5 successful auto associations, 1 failed to re-associate and required entering WEP key again. WPA security == First connection: Prompts for the security string and then fails every time, until you subsequently click a dialogue cancel button, then clicking the AP again will associate (8.2 connects without a hitch). After OS reboot: A 6 attempts failed to re-associate and shows the security string dialogue, clicking cancel and then clicking the AP again will re-associate (8.2 connects without a hitch). After restart of Sugar UI: 6 successful auto associations. After sleep: All 6 times dropped back to mesh, 3 of those times manually clicking the AP auto re-associated, the other 3 times prompted for the security string which you had to cancel then click the AP again (8.2 did not automatically re-associate, but clicking the AP connected immediately with no dialogues). Hope this helps, --Gary P.S. Interestingly we had what seems to be the same behaviour, but with WEP, for a while early last year in the (long) run up to 8.2. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Unshare an Activity
Hi all, I am doing an activity for blind childrens and I need to know If some one knows if sugar has a way to programmaticaly unshare a shared activity?, and if it has, how can i do that?. If I join a shared activity I can use the leave method from activity object of presenceservice to leave the shared activity, but, if I share how can I stop sharing it? Thanks for the answers. Regards. -- Jorge Saldivar ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: power consumption after shutdown
On Sun, Feb 15, 2009 at 12:36:36AM -0500, Mikus Grinbergs wrote: > My apologies for not being clear. I'll try again: > > I want to feel that the battery that I just put into the XO I'm > walking out the door with is as "charged up" as it normally can be. > > 1) If that battery came from an XO that was plugged into the AC > 24/7 for the past week -- I *think* it is fully "charged up". Yes, 95% likely. > 2) If that battery came from an XO that had been "shut down" for 48 > hours; but then that XO had been plugged into the AC until the > 'power' light went green -- I *think* it is well "charged up". Yes, 95% likely. > 3) If that battery had been sitting on the shelf (not in an XO) for > a month -- what did I need to do to make it "topped off" ? Discharge it to 90% capacity, then charge it. (You can do this manually in OFW using the watch-battery command ... or you can periodically attach the AC adaptor until you get an orange LED instead of green.) > Sorry - I did not mean that I cared exactly how "charged up" it was > -- what I want to know is how to ensure to myself, without going to > extremes, that the battery was "well charged up". [Is 94% reported > by the pop-up for an on-the-shelf battery believable, or is the > 'true' value half that? And if do I see 94%, do I need to worry > that "this is a battery that requires some more charging"?] Given a battery with an unknown history, it is not practical to predict the state of charge. > I was under the impression that when the battery charge went > somewhere below about 97%, the XO would "charge it some more". > So I was surprised to have it stay at 94%. [If 94% being shown on > the pop-up is not low enough for "charging some more", then how can > I initiate charging being performed by the XO ?] Discharge it some more. (There is no facility for boost charging ... one reason is that this would shorten the life of the battery.) > >> But when the software pop-up is between 90-96% (for a previously > >> out-of-case battery), and despite the AC adapter being plugged in > >> that value does not increase in an hour -- what ought I to do to > >> find the "state of charge" ? > > > > No possible way except a full discharge while measuring the power > > provided. > > Apologies for being unclear. I'm not particularly interested in the > precision of the "state of charge". My explanation of this precision was so that you would understand why you cannot get what you want. I had tried explaining that you cannot get what you want but you persisted, so I thought you were interested. > What I am interested in is "is > the battery as 'well charged up' as I can make it be by using the > XO's 'built-in' charger - I will want to get the most minutes of use > of my XO when carried to a place that does not have electricity" ? Discharge to 90% and then charge to completion. Power off, then remove the battery. Travel as fast as possible to the place that does not have electricity, do not delay by a month. Insert the battery and power on. You will have the most minutes of use. > And if it is not 'well charged up', what do I need to do to make it > so? In particular -- if it *were* 90% "charged up" when I took > it off the shelf, would I have to fully discharge it in order to > then "charge it up" (using the XO as the 'charger') closer to 97-99% ? No. Assuming a battery that has only been used in the XO, you need only complete one charge cycle, from orange LED to green LED. Since you cannot cause this cycle unless the state of charge value was low enough, you need to manipulate the state of charge value down, and the only way to do this in the design is to discharge for a short time. Usually about five minutes, but it depends on how busy the XO is. -- James Cameronmailto:qu...@us.netrek.org http://quozl.netrek.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: power consumption after shutdown
On Sun, Feb 15, 2009 at 6:36 PM, Mikus Grinbergs wrote: > I was under the impression that when the battery charge went > somewhere below about 97%, the XO would "charge it some more". > So I was surprised to have it stay at 94%. [If 94% being shown on > the pop-up is not low enough for "charging some more", then how can > I initiate charging being performed by the XO ?] It probably is trying to charge it, but batteries are chemical mixes, so - there is no real 100% or 0% - the software is handwaving to some extent... - the charge and performance of the battery changes with many variables, and generally degrades with use so I have many batteries that after some use I only see reported as "95% charged". Even if they get more "charge", the battery doesn't hold it. Or perhaps the software estimated the capacity a bit too high. In short, the % you see is a fiction, a bad simplification. This is increasingly apparent as you use older batteries, and in general as you gain experience with different batteries... m ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: power consumption after shutdown
On 15 Feb 2009, at 05:36, Mikus Grinbergs wrote: > My apologies for not being clear. I'll try again: > > I want to feel that the battery that I just put into the XO I'm > walking out the door with is as "charged up" as it normally can be. > > 1) If that battery came from an XO that was plugged into the AC > 24/7 for the past week -- I *think* it is fully "charged up". > > 2) If that battery came from an XO that had been "shut down" for 48 > hours; but then that XO had been plugged into the AC until the > 'power' light went green -- I *think* it is well "charged up". > > 3) If that battery had been sitting on the shelf (not in an XO) for > a month -- what did I need to do to make it "topped off" ? > > > >>> What I am now interested in is understanding a "correct" state of >>> charge value after having my battery out of the XO for one month. >> >> Not possible without discharging the battery fully to determine the >> state of charge it had. The test is charge destructive; once it is >> completed there is no usable charge in the battery. > > Sorry - I did not mean that I cared exactly how "charged up" it was > -- what I want to know is how to ensure to myself, without going to > extremes, that the battery was "well charged up". [Is 94% reported > by the pop-up for an on-the-shelf battery believable, or is the > 'true' value half that? And if do I see 94%, do I need to worry > that "this is a battery that requires some more charging"?] > >>> the software pop-up says 94%. But I notice that >>> after an hour, the software pop-up *still* says 94%. >> >> I hope you aren't surprised. No reason it should change. Battery is >> not being used. > > I was under the impression that when the battery charge went > somewhere below about 97%, the XO would "charge it some more". > So I was surprised to have it stay at 94%. [If 94% being shown on > the pop-up is not low enough for "charging some more", then how can > I initiate charging being performed by the XO ?] > >>> But when the software pop-up is between 90-96% (for a previously >>> out-of-case battery), and despite the AC adapter being plugged in >>> that value does not increase in an hour -- what ought I to do to >>> find the "state of charge" ? >> >> No possible way except a full discharge while measuring the power >> provided. > > Apologies for being unclear. I'm not particularly interested in the > precision of the "state of charge". What I am interested in is "is > the battery as 'well charged up' as I can make it be by using the > XO's 'built-in' charger - I will want to get the most minutes of use > of my XO when carried to a place that does not have electricity" ? Have you tried either of the tools/procedures at: http://wiki.laptop.org/go/XO_LiFePO4_Recovery_Procedure Either olpc-pwr-log (download and run in terminal) or bat-recover (download a batman.fth file and use from Open Firmware), display actual charge going into (or out of) the battery, so you could use either of them to charge and see when your battery stops getting any more juice. Of course, without testing full discharge/charge cycles occasionally, you could never be quite sure where a batteries max is/ was (but that just takes us back to the email loop on precision). --Gary > And if it is not 'well charged up', what do I need to do to make it > so? In particular -- if it *were* 90% "charged up" when I took > it off the shelf, would I have to fully discharge it in order to > then "charge it up" (using the XO as the 'charger') closer to 97-99% ? > > mikus > > ___ > 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
[ANNOUNCE] Sucrose 0.84 Release Candidate 1 (0.83.5)
Dear Sugar Community,
This is Release Candidate 1 for the upcoming 0.84 Release - see [1] for
more details. Only two more weeks to go in this release cycle. Please
test this release and report all the bugs you find that we are able to
fix them in time. A friendly [2] will be available to triage those bugs
accordingly and the developers can never have enough bug food. If you
have non-bug feedback about features you can use the sugar-devel mailing
list to share it with us.
From a user point of view we want to highlight the following changes
that have been made in this release:
=== Journal ===
The translation of the dates in the Journal is working now again. Please
verify with your favorite language that this works for you. A 'Clear
search' button has been added to the 'No matching entries' message,
following Eben's specification. Also the space used and left is now
displayed in the volume palette in the Journal.
Journal entry palette
The journal entry palette has seen some great improvements. We have a
'View Details' option that brings you to the details of the entry
directly. Also the icon for the file transfer was designed and added by
Gary C. Martin. Furthermore you do not need to go to the detail view any
more to select the activity you want to start or resume the entry with -
this option is now available in the palette as well.
=== Naming Alert ===
When you stop an activity from the Frame the activity is resumed and one
can refine the activity metadata in the Naming Alert. As well a saving
error of the activity will not prevent one any more from closing the
activity due to the Naming Alert.
=== Palettes ===
There were some positioning issues of the palette that got fixed. Please
report back any issues you still find. Another palette related fix was
that on right click on an Access Point icon we do reveal the palette as
it is the behavior in all the other places in the UI and do not try to
connect to the Access Point.
=== Keep error when displaying a file in Browse, Read, ImageViewer ===
This is one of my favorite fixes as this has been broken for quite a
while. When trying to display for example an image in Browse or the
ImageViewer there was an keep error when closing the activity.
=== Resume activity ===
Last release we added the ability to resume an activity by default
instead of creating a new instance. The list of the available entries in
the palette when you hover of the activity in the home view is now
updated directly. As this is an interesting new feature, we would like
to hear about any issues you might have with it and positive feedback of
course as well.
=== Control Panel ===
We now hide any OLPC-specific fields on non-xo machines. For example in
the 'About my Computer' section we display the build dependent on the
distribution (i.e. Fedora). As the Power section was only relevant on
the XO, it is hidden in non OLPC distributions.
=== Frame Devices ===
Right-clicking on the speaker device icon does not mute the speakers
anymore.
=== Clipboard ===
Several fixes were made to the detection of images dragged and dropped
to the clipboard in the Frame.
Thanks everyone for your great contributions!
In behalf of the sugar community,
Your Release Team
[1] The Sucrose Release Schedule can be found here
http://sugarlabs.org/go/DevelopmentTeam/Release/Roadmap#Schedule
[2] More Info about the BugSquad at
http://sugarlabs.org/go/BugSquad
[3] You can find more details and screenshots at
http://sugarlabs.org/go/DevelopmentTeam/Release/Releases/Sucrose/0.83.5
__
Modules that changed:
== Glucose modules==
* sugar-toolkit 0.83.6:
http://download.sugarlabs.org/sources/sucrose/glucose/sugar-toolkit/sugar-toolkit-0.83.6.tar.bz2
* sugar 0.83.7:
http://download.sugarlabs.org/sources/sucrose/glucose/sugar/sugar-0.83.7.tar.bz2
* sugar-artwork 0.83.4:
http://download.sugarlabs.org/sources/sucrose/glucose/sugar-artwork/sugar-artwork-0.83.4.tar.bz2
* sugar-datastore 0.83.3:
http://download.sugarlabs.org/sources/sucrose/glucose/sugar-datastore/sugar-datastore-0.83.3.tar.bz2
== Glucose news ==
=== sugar-toolkit ===
* Dates in journal are not translated {{Bug|55}}
* Keep error when displaying a file in Browse, Read, ImageViewer, etc
{{Bug|258}}
* Palette positioning fixes {{Bug|298}}
* 'Resume' activity window when NamingAlert is displayed {{Bug|293}}
* Naming alert prevents activity close on keep error {{Bug|224}}
=== sugar ===
* Resume Activity list is not updated directly {{Bug|322}}
* Fix network panel on XO (Sascha Silbe) {{Bug|290}}
* Only show cp power section on xo {{Bug|320}}
* Add logout option to the buddy menu (Sayamindu) {{Bug|207}}
* Launch activity also when clicking on the palette icon {{Bug|335}}
* Use the activity icon for the 'Start new' palette item {{Bug|314}}
* Close the object chooser when the activity is closed {{Bug|329}}
* D
