Re: [PATCH 1/3] olpc-battery: add support for CHARGE_FULL_DESIGN

2010-12-10 Thread Richard A. Smith
On 12/10/2010 10:22 PM, Andres Salomon wrote:

 > Alright, thanks.  I guess a comment in the (kernel) source saying as
 > much would be useful.
 >
 > On Fri, 10 Dec 2010 21:41:00 -0500 Paul Fox  wrote:
 >
 >> i'm pretty sure those numbers (and the corresponding numbers from the
 >> 1.5 DSDT) came from the battery manufacturer.  obviously we could move
 >> the data to the EC, but i'm not sure what the advantage of that would
 >> be.  i know that the numbers don't come from the battery itself.

Some history for those who may not know:

The design of the battery system in the EC is sort of out in its own 
class. OLPC sort of forced that to happen.

1) We used battery chemistry's few laptop have used and used both of 
them at the same time. NiMH and LiFePO4. (In the LiFePO4 case, I think 
we are the only laptop that has used it.)

2) In XO-1 we had the "We hate the evil ACPI mantra".

To top it off we had this requirement of the battery lasting 2000 
cycles.  This requires some very funky stuff in the NiMH case. 
Basically for NiMH there is a really complex 12 page flowchart on 
charging.  We have now stopped caring about NiMH but the 1.0 and 1.5 
carry around a lot of legacy NiMH baggage.  In 1.75 we have purged all 
of that.

We had (good) reasons for doing all of the above but we basically forced 
quanta to come up with a battery subsystem on their own.  Not one that 
followed any of the accepted standards at the time.

The system that they came up with does not have any concept of battery 
capacity.  It uses markers inherent in the battery characteristics to 
determine when the battery is full and empty.  To track the state of 
charge (SOC) each chemistry has a setting for what the net difference 
for 1% SOC is in the accumulated current register (ACR).  If the ACR 
goes up or down that value then the SOC is ++ or -- 1%.  The ACR is used 
as a free running counter of charge.  When a full or empty marker is 
found the SOC is snapped to a full (97%) or empty (7%) [1].

So none of the max capacity values that you are asking about exist in 
the EC because they aren't necessary for things to work.  All the values 
about max capacity are values that I pulled from the manufactures 
datasheet and put up on the wiki.

http://wiki.laptop.org/go/Laptop_Batteries

Until now there hasn't been a reason to add this info into the EC code. 
  There is nothing hard about adding them except that its a few more 
commands for the EC, OFW, and kernel to add and then all be in sync.

There's also no concept of calibration in the EC code.  Last time Sascha 
brought all this up I began to think about how to do some sort of 
calibration.  It would be a nice feature to have.  We already have a 
some issues because the battery capacity varies +/- 5%.  If I had 
calibration then I could store the "real" capacity in the eeprom of the 
battery.  Hopefully I can get a chance to figure out a good way to do 
this for 1.75 and keep it so that batteries are backward compatible. in 
1.5 and 1.0

If you want the max capacity values added to the EC code with EC 
commands to fetch that extra the data then that's not a big problem just 
tell me.  But that won't help with running your new kernel on an old XO 
with older firmware so you will still have to hardcode it for them.

I think it makes sense to hardcode them until such time as I have 
calibration in the EC code and then the kernel can ask the EC (or OFW 
via DT for them)


[1]  I have no idea where those values came from. I'm changing them in 
1.75 to be more sane.

-- 
Richard A. Smith  
One Laptop per Child
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: [Sugar-devel] prevent screen rotation in a sugar activity?

2010-12-10 Thread Bakhtiar Mikhak

On Dec 10, 2010, at 5:14 PM, James Cameron wrote:

> On Fri, Dec 10, 2010 at 04:29:31PM -0500, Erik Blankinship wrote:
>> It is sometimes a designer's prerogative to present their work in one 
>> format.  
>> Numerous examples are available on the iPhone and android markets.
> 
> It is sometimes a platform designer's perogative to enforce human
> interface guidelines and require applications to support certain
> behaviours.
> 
>> Is it possible to override or be notified of a rotation signal?
> 
> No, not without taking control of components outside the scope of a
> Sugar activity.  You're welcome to try that, but the problems that occur
> are:
> 
> 0.  installation will require root access, which is not available to
> some users due to deployment team policy,
> 
> 1.  the API will keep changing, instead of remaining relatively static
> in the case of the Sugar Activity API,
> 
> 2.  there are multiple build versions to test against,
> 
> 3.  there is a higher risk of breaking something later.

If I am reading the current version of HIG correctly, it is not a requirement 
for developers to implement a portrait layout for their activity:
Screen Rotation
While in Hand-held mode, the laptops support screen rotation; by pressing a 
small button on the bezel of the display, the interface will rotate 90 degrees 
to provide a portrait layout of the currently active activity. Just as any 
activity can implement Hand-held mode, those which can benefit from a vertical 
aspect ratio may also implement this feature, and we encourage developers to 
take advantage of this functionality. The Read activity serves as a prime 
example of the usefulness of such a feature, since a vertical layout is well 
suited to displaying a single page from a book. This is just the type of 
activity one might want to do in Hand-held mode, and by providing two 
orientations a greater number of use cases can be covered.
In the current revisions of the laptops, its important to note that the buttons 
for interacting with Hand-held mode are slightly less accessible when the 
laptops are held vertically. For this reason, activities that require heavy or 
frequent use might not be best suited for this mode. However, OLPC is working 
hard on introducing touch-screen technology in the near future, which will 
nearly eliminate the dependency on the physical buttons, expanding the 
possibilities as every activity can take advantage of screen rotation. 
Therefore, even if screen rotation doesn't make sense for the first version of 
your activity, please construct your interface in such a way as to allow future 
adaptation to this new and potentially useful functionality.
I therefore think it is worth considering if the control over if/how one's 
activity takes advantage of screen rotation should be exposed through the Sugar 
API.___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: [Sugar-devel] prevent screen rotation in a sugar activity?

2010-12-10 Thread James Simmons
Erik,

Here is how you can be notified when the screen is rotated:

First, listen for the "expose" event in PyGTK:

self.connect("expose_event", self.area_expose_cb)

Here is the method that gets invoked:

def area_expose_cb(self, area, event):
screen_width = gtk.gdk.screen_width()
screen_height = gtk.gdk.screen_height()
if self.saved_screen_width != screen_width and
self.saved_screen_width != 0:
self.show_page(self.page)
self.saved_screen_width = screen_width
return False

Now if you write a PyGTK Activity the layouts usually make this
unnecessary.  In this case I was displaying an image which needed to
be resized to make the best use of the new screen dimensions, so I
invoke the method that shows the image when the dimensions change.

Every new Activity developer seems to want to do something that Sugar
won't allow.  In time you'll come to terms with what Sugar is and make
your Activities accordingly.

Your iPhone and Android examples are not good.  If I had paid money
for an app for either platform and it refused to rotate when I rotated
my phone I would not think highly of that app.  Supporting screen
rotation in a PyGTK Activity is trivial.  With PyGame it's more work,
but it's work you should be doing anyway.  With Sugar on a Stick your
Activity will need to support a variety of screen dimensions.  A good
example of the wrong thing to do is the commercial game "Super Vampire
Ninja Zero".  It ONLY works on the XO screen dimensions, without
rotation.  Don't be that guy!

James Simmons


On Fri, Dec 10, 2010 at 4:14 PM, James Cameron  wrote:
> On Fri, Dec 10, 2010 at 04:29:31PM -0500, Erik Blankinship wrote:
>> It is sometimes a designer's prerogative to present their work in one format.
>>  Numerous examples are available on the iPhone and android markets.
>
> It is sometimes a platform designer's perogative to enforce human
> interface guidelines and require applications to support certain
> behaviours.
>
>> Is it possible to override or be notified of a rotation signal?
>
> No, not without taking control of components outside the scope of a
> Sugar activity.  You're welcome to try that, but the problems that occur
> are:
>
> 0.  installation will require root access, which is not available to
> some users due to deployment team policy,
>
> 1.  the API will keep changing, instead of remaining relatively static
> in the case of the Sugar Activity API,
>
> 2.  there are multiple build versions to test against,
>
> 3.  there is a higher risk of breaking something later.
>
> --
> James Cameron
> http://quozl.linux.org.au/
> ___
> Sugar-devel mailing list
> sugar-de...@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Archlinux packages for Sugar

2010-12-10 Thread Christophe Guéret
Hi,

The sugar packages for Archlinux where orphans and outdated.
I just adopted and updated a bunch of them: 
http://aur.archlinux.org/packages.php?SeB=m&K=tolgam

If you are an Arch user, please have a look at them and let me know if 
they work for you.

Cheers,
Christophe

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: [PATCH 1/3] olpc-battery: add support for CHARGE_FULL_DESIGN

2010-12-10 Thread Andres Salomon
Alright, thanks.  I guess a comment in the (kernel) source saying as
much would be useful.


On Fri, 10 Dec 2010 21:41:00 -0500 Paul Fox  wrote:

> i'm pretty sure those numbers (and the corresponding numbers from the
> 1.5 DSDT) came from the battery manufacturer.  obviously we could move
> the data to the EC, but i'm not sure what the advantage of that would
> be.  i know that the numbers don't come from the battery itself.
> 
> paul
> 
> mitch wrote:
>  > By not providing more information, I was sending a subtle signal
>  > that I am busy with something else right now and do not want to go
>  > into "digging up everything I know or can find out about
>  > batteries" mode at the moment.
>  > 
>  > 
>  > On 12/10/2010 3:09 PM, Andres Salomon wrote:
>  > > On Fri, 10 Dec 2010 14:56:15 -1000
>  > > Mitch Bradley  wrote:
>  > >
>  > >> There is some battery info in the _BIF (battery info) method in
>  > >> the BATT node of the ACPI DSDT.  I don't remember if it is
>  > >> correct or not.  The numbers below match the DSDT numbers.
>  > >
>  > > Wait, so where did *those* numbers come from?  A spec somewhere,
>  > > the EC, or did you actually reverse engineer them?
>  > >
>  > > (Note that ACPI is only available on XO-1.5, so pulling them
>  > > from ACPI on XO-1 isn't an option.)
>  > >
>  > >
>  > >
>  > >>
>  > >> On 12/10/2010 2:38 PM, Andres Salomon wrote:
>  > >>> On Fri, 10 Dec 2010 22:15:10 +
>  > >>> David Woodhouse   wrote:
>  > >>>
>  >  On Fri, 2010-12-10 at 23:05 +0100, Sascha Silbe wrote:
>  > >
>  > > +
>  > > +   switch (tech.intval) {
>  > > +   case POWER_SUPPLY_TECHNOLOGY_NiMH:
>  > > +   switch (mfr) {
>  > > +   case 1: /* Gold Peak */
>  > > +   val->intval = 300*.8;
>  > > +   break;
>  > > +   default:
>  > > +   return -EIO;
>  > > +   }
>  > > +   break;
>  > > +
>  > > +   case POWER_SUPPLY_TECHNOLOGY_LiFe:
>  > > +   switch (mfr) {
>  > > +   case 1: /* Gold Peak */
>  > > +   val->intval = 280;
>  > > +   break;
>  > > +   case 2: /* BYD */
>  > > +   val->intval = 310;
>  > > +   break;
>  > > +   default:
>  > > +   return -EIO;
>  > > +   }
>  > > +   break;
>  > > +
>  > > +   default:
>  > > +   return -EIO;
>  > > +   }
>  > > +
>  > > +   return ret;
>  > > +}
>  > 
>  > ___
>  > 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: [PATCH 1/3] olpc-battery: add support for CHARGE_FULL_DESIGN

2010-12-10 Thread Paul Fox
i'm pretty sure those numbers (and the corresponding numbers from the
1.5 DSDT) came from the battery manufacturer.  obviously we could move
the data to the EC, but i'm not sure what the advantage of that would
be.  i know that the numbers don't come from the battery itself.

paul

mitch wrote:
 > By not providing more information, I was sending a subtle signal that I 
 > am busy with something else right now and do not want to go into 
 > "digging up everything I know or can find out about batteries" mode at 
 > the moment.
 > 
 > 
 > On 12/10/2010 3:09 PM, Andres Salomon wrote:
 > > On Fri, 10 Dec 2010 14:56:15 -1000
 > > Mitch Bradley  wrote:
 > >
 > >> There is some battery info in the _BIF (battery info) method in the
 > >> BATT node of the ACPI DSDT.  I don't remember if it is correct or
 > >> not.  The numbers below match the DSDT numbers.
 > >
 > > Wait, so where did *those* numbers come from?  A spec somewhere, the
 > > EC, or did you actually reverse engineer them?
 > >
 > > (Note that ACPI is only available on XO-1.5, so pulling them from ACPI
 > > on XO-1 isn't an option.)
 > >
 > >
 > >
 > >>
 > >> On 12/10/2010 2:38 PM, Andres Salomon wrote:
 > >>> On Fri, 10 Dec 2010 22:15:10 +
 > >>> David Woodhouse   wrote:
 > >>>
 >  On Fri, 2010-12-10 at 23:05 +0100, Sascha Silbe wrote:
 > >
 > > +
 > > +   switch (tech.intval) {
 > > +   case POWER_SUPPLY_TECHNOLOGY_NiMH:
 > > +   switch (mfr) {
 > > +   case 1: /* Gold Peak */
 > > +   val->intval = 300*.8;
 > > +   break;
 > > +   default:
 > > +   return -EIO;
 > > +   }
 > > +   break;
 > > +
 > > +   case POWER_SUPPLY_TECHNOLOGY_LiFe:
 > > +   switch (mfr) {
 > > +   case 1: /* Gold Peak */
 > > +   val->intval = 280;
 > > +   break;
 > > +   case 2: /* BYD */
 > > +   val->intval = 310;
 > > +   break;
 > > +   default:
 > > +   return -EIO;
 > > +   }
 > > +   break;
 > > +
 > > +   default:
 > > +   return -EIO;
 > > +   }
 > > +
 > > +   return ret;
 > > +}
 > 
 > ___
 > 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: [PATCH 1/3] olpc-battery: add support for CHARGE_FULL_DESIGN

2010-12-10 Thread Mitch Bradley
By not providing more information, I was sending a subtle signal that I 
am busy with something else right now and do not want to go into 
"digging up everything I know or can find out about batteries" mode at 
the moment.


On 12/10/2010 3:09 PM, Andres Salomon wrote:
> On Fri, 10 Dec 2010 14:56:15 -1000
> Mitch Bradley  wrote:
>
>> There is some battery info in the _BIF (battery info) method in the
>> BATT node of the ACPI DSDT.  I don't remember if it is correct or
>> not.  The numbers below match the DSDT numbers.
>
> Wait, so where did *those* numbers come from?  A spec somewhere, the
> EC, or did you actually reverse engineer them?
>
> (Note that ACPI is only available on XO-1.5, so pulling them from ACPI
> on XO-1 isn't an option.)
>
>
>
>>
>> On 12/10/2010 2:38 PM, Andres Salomon wrote:
>>> On Fri, 10 Dec 2010 22:15:10 +
>>> David Woodhouse   wrote:
>>>
 On Fri, 2010-12-10 at 23:05 +0100, Sascha Silbe wrote:
>
> +
> +   switch (tech.intval) {
> +   case POWER_SUPPLY_TECHNOLOGY_NiMH:
> +   switch (mfr) {
> +   case 1: /* Gold Peak */
> +   val->intval = 300*.8;
> +   break;
> +   default:
> +   return -EIO;
> +   }
> +   break;
> +
> +   case POWER_SUPPLY_TECHNOLOGY_LiFe:
> +   switch (mfr) {
> +   case 1: /* Gold Peak */
> +   val->intval = 280;
> +   break;
> +   case 2: /* BYD */
> +   val->intval = 310;
> +   break;
> +   default:
> +   return -EIO;
> +   }
> +   break;
> +
> +   default:
> +   return -EIO;
> +   }
> +
> +   return ret;
> +}

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: [PATCH 1/3] olpc-battery: add support for CHARGE_FULL_DESIGN

2010-12-10 Thread Andres Salomon
On Fri, 10 Dec 2010 14:56:15 -1000
Mitch Bradley  wrote:

> There is some battery info in the _BIF (battery info) method in the
> BATT node of the ACPI DSDT.  I don't remember if it is correct or
> not.  The numbers below match the DSDT numbers.

Wait, so where did *those* numbers come from?  A spec somewhere, the
EC, or did you actually reverse engineer them?

(Note that ACPI is only available on XO-1.5, so pulling them from ACPI
on XO-1 isn't an option.)



> 
> On 12/10/2010 2:38 PM, Andres Salomon wrote:
> > On Fri, 10 Dec 2010 22:15:10 +
> > David Woodhouse  wrote:
> >
> >> On Fri, 2010-12-10 at 23:05 +0100, Sascha Silbe wrote:
> >>>
> >>> +
> >>> +   switch (tech.intval) {
> >>> +   case POWER_SUPPLY_TECHNOLOGY_NiMH:
> >>> +   switch (mfr) {
> >>> +   case 1: /* Gold Peak */
> >>> +   val->intval = 300*.8;
> >>> +   break;
> >>> +   default:
> >>> +   return -EIO;
> >>> +   }
> >>> +   break;
> >>> +
> >>> +   case POWER_SUPPLY_TECHNOLOGY_LiFe:
> >>> +   switch (mfr) {
> >>> +   case 1: /* Gold Peak */
> >>> +   val->intval = 280;
> >>> +   break;
> >>> +   case 2: /* BYD */
> >>> +   val->intval = 310;
> >>> +   break;
> >>> +   default:
> >>> +   return -EIO;
> >>> +   }
> >>> +   break;
> >>> +
> >>> +   default:
> >>> +   return -EIO;
> >>> +   }
> >>> +
> >>> +   return ret;
> >>> +}
> >>
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: [PATCH 1/3] olpc-battery: add support for CHARGE_FULL_DESIGN

2010-12-10 Thread Andres Salomon
On Sat, 11 Dec 2010 00:41:20 +
David Woodhouse  wrote:

> On Fri, 2010-12-10 at 16:38 -0800, Andres Salomon wrote:
> > It there is, it's not at all clear.  The values are fetched from the
> > EC, which get them from the EEPROM. 
> 
> If the EC knows them, can't we ask the EC rather than pulling numbers
> our of our arse in the kernel?

Sorry, i meant the battery manufacturer/type info is fetched from the
EC (and the DT doesn't appear to have *that* information, much less
the magic values that this patch uses).

Pgf or Richard can probably tell us if the magic numbers can be derived
from the EC.


___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: [PATCH 1/3] olpc-battery: add support for CHARGE_FULL_DESIGN

2010-12-10 Thread Mitch Bradley
There is some battery info in the _BIF (battery info) method in the BATT 
node of the ACPI DSDT.  I don't remember if it is correct or not.  The 
numbers below match the DSDT numbers.

On 12/10/2010 2:38 PM, Andres Salomon wrote:
> On Fri, 10 Dec 2010 22:15:10 +
> David Woodhouse  wrote:
>
>> On Fri, 2010-12-10 at 23:05 +0100, Sascha Silbe wrote:
>>>
>>> +
>>> +   switch (tech.intval) {
>>> +   case POWER_SUPPLY_TECHNOLOGY_NiMH:
>>> +   switch (mfr) {
>>> +   case 1: /* Gold Peak */
>>> +   val->intval = 300*.8;
>>> +   break;
>>> +   default:
>>> +   return -EIO;
>>> +   }
>>> +   break;
>>> +
>>> +   case POWER_SUPPLY_TECHNOLOGY_LiFe:
>>> +   switch (mfr) {
>>> +   case 1: /* Gold Peak */
>>> +   val->intval = 280;
>>> +   break;
>>> +   case 2: /* BYD */
>>> +   val->intval = 310;
>>> +   break;
>>> +   default:
>>> +   return -EIO;
>>> +   }
>>> +   break;
>>> +
>>> +   default:
>>> +   return -EIO;
>>> +   }
>>> +
>>> +   return ret;
>>> +}
>>
>> I don't much like hard-coding it in the kernel. Can the firmware
>> expose these values in the device-tree?
>>
>
>
> It there is, it's not at all clear.  The values are fetched from the
> EC, which get them from the EEPROM.  The DT has a battery entry, but it
> contains nothing useful:
>
> /proc/device-tree/batt...@0/name
> /proc/device-tree/batt...@0/reg
> /proc/device-tree/batt...@0/.node
>
> Nor is there anything in the DT related to the battery EEPROM.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: [PATCH 1/3] olpc-battery: add support for CHARGE_FULL_DESIGN

2010-12-10 Thread David Woodhouse
On Fri, 2010-12-10 at 16:38 -0800, Andres Salomon wrote:
> It there is, it's not at all clear.  The values are fetched from the
> EC, which get them from the EEPROM. 

If the EC knows them, can't we ask the EC rather than pulling numbers
our of our arse in the kernel?

>  The DT has a battery entry, but it contains nothing useful:
> 
> /proc/device-tree/batt...@0/name
> /proc/device-tree/batt...@0/reg
> /proc/device-tree/batt...@0/.node

The driver ought to be matching on that rather than registering its own
platform device.

-- 
dwmw2

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: [PATCH 1/3] olpc-battery: add support for CHARGE_FULL_DESIGN

2010-12-10 Thread Andres Salomon
On Fri, 10 Dec 2010 22:15:10 +
David Woodhouse  wrote:

> On Fri, 2010-12-10 at 23:05 +0100, Sascha Silbe wrote:
> > 
> > +
> > +   switch (tech.intval) {
> > +   case POWER_SUPPLY_TECHNOLOGY_NiMH:
> > +   switch (mfr) {
> > +   case 1: /* Gold Peak */
> > +   val->intval = 300*.8;
> > +   break;
> > +   default:
> > +   return -EIO;
> > +   }
> > +   break;
> > +
> > +   case POWER_SUPPLY_TECHNOLOGY_LiFe:
> > +   switch (mfr) {
> > +   case 1: /* Gold Peak */
> > +   val->intval = 280;
> > +   break;
> > +   case 2: /* BYD */
> > +   val->intval = 310;
> > +   break;
> > +   default:
> > +   return -EIO;
> > +   }
> > +   break;
> > +
> > +   default:
> > +   return -EIO;
> > +   }
> > +
> > +   return ret;
> > +} 
> 
> I don't much like hard-coding it in the kernel. Can the firmware
> expose these values in the device-tree?
> 


It there is, it's not at all clear.  The values are fetched from the
EC, which get them from the EEPROM.  The DT has a battery entry, but it
contains nothing useful:

/proc/device-tree/batt...@0/name
/proc/device-tree/batt...@0/reg
/proc/device-tree/batt...@0/.node

Nor is there anything in the DT related to the battery EEPROM.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


DebXO 0.6 release

2010-12-10 Thread Andres Salomon
Hi,

After waay to long of a delay, I just tagged and built
DebXO 0.6.  In some ways, it's very polished (I've actually tested all
of the desktops myself), in other ways it has a number of regressions
(due to Debian updates breaking things, switching to an
almost-stock Linus kernel, etc).  Either way, I wanted to get it out
because people keep asking about it, and dropping jffs2 leads to such a
massive improvement.


DebXO is a version of Debian (testing) that is customized for the XO-1
hardware.  The 0.6 release adds initial support for the XO-1.5
hardware; however, XO-1.5 is not officially supported.  I'll update the
wiki with instructions for XO-1.5, for the early adopters.

The release can be found here:

http://lunge.mit.edu/~dilinger/debxo-0.6/images/

The official wiki is:

http://wiki.laptop.org/go/DebXO


CHANGES:

 - Update distribution to Debian Squeeze.  All packages and
   desktops have been upgraded.  This is pretty major; for example,
   Sugar is now at 0.88, and Gnome at 2.30(ish).

 - Kernel update.  Switch from the olpc-2.6 tree to Linus's linux-2.6
   tree (based upon 2.6.37-rc4+).  A few pending patches from -next and
   -mm have been included, but other than that... it's stock.  The
   config closely matches the Debian stock kernel config; at a future
   date, we'll just switch to a standard Debian 686 kernel.

 - Switch the nand images from using JFFS2 to UBIFS.  This makes an
   amazing difference in terms of usability.  Over time, JFFS2
   filesystems get slower as they fragment, while UBIFS doesn't appear
   to.

 - Initial XO-1.5 support. It's still rough around the edges, but it's
   functional (currently xorg.conf and /boot/olpc.fth must be edited).

 - Switch from autox to nodm for LXDE and XFCE desktops. LXDE
   usability has been vastly improved (for example, wicd is installed
   and configured automatically; LXDE can now get online). Webkit-based
   browsers are used - less ram thrashing throughout.

 - KDE image has been dropped (at least for now). KDE4 took at least 10
   minutes to start up and then crashed, so.. I'll deal with it another
   time. Patches to make it work accepted!

 - Awesome image has been dropped. I'd intended to replace this with
   XMonad (as that's what I actually use), but currently that requires
   some tweaking and needs to drop about 300MB of devel libs. So for
   now, it's just dropped.

 - Base images have been dropped.  The 0.5 base image was broken, and,
   well... I don't see much demand for it.

 - Hal is no longer used (except for some legacy stuff in the XFCE
   images). Key bindings are pulled from DMI and loaded by udev (note:
   upgrade your version of OFW if hitting the 'fn' key results in lots
   of '='s. Alternatively, add "/lib/udev/keymap /dev/input/event0
   olpc-xo" to your /etc/rc.local to auto-load the proper keymap).

Lots of misc other changes can be seen at:
http://lunge.mit.edu/cgi-bin/gitweb.cgi?p=xodist;a=summary


KNOWN BUGS:

 - Power management is currently not enabled. It's on the roadmap.

 - KDE and Awesome images are disabled (for DebXO 0.6).

 - The camera driver is disabled due to a crash in the kernel.

 - Upon first bootup, the LXDE and XFCE desktops display a wicd error.
   It only happens on the first boot, so I think it's related to
   copying files around. Just restart and it'll go away. 

 - Also upon first bootup, if you reboot XFCE via the menu
   (logout->reboot), it appears to kill the panel prior to saving the
   startup applications. This means that when XFCE boots up the second
   time, there's no panel or desktop. I believe that this is an XFCE
   bug; after the first boot, using the menu to reboot doesn't break
   anything. So, just open up a terminal and "sudo reboot" the first
   time, if using XFCE.

 - Nodm doesn't currently set ~/.Xauthority; see
   http://bugs.debian.org/605633 . This means gksu (and gksudo) are
   broken. For now, just open up a terminal and call (for example)
   "sudo synaptic".

 - The volume/brightness keys are mapped to function keys. It's unclear
   how best to handle this, as it is useful to have f11, for example.
   Will figure something out later.

 - Due to a switch from Hal to udev and upower, battery status
   reporting is broken. This is fixed with a pending kernel update, but
   it's in the process of being pushed upstream (and therefore will be
   fixed in 0.7).


INSTALLATION ONTO NAND FLASH:

To install onto the XO's NAND flash, download the jffs2/$DESKTOP.dat
and jffs2/$DESKTOP.img to a USB or SD stick (where $DESKTOP is
one of the various desktops - gnome, lxde, xfce, or sugar). Boot into
OFW (make sure your XO is unlocked!), and run

update-nand disk:\$DESKTOP.img

or

update-nand sd:\$DESKTOP.img

(depending upon whether you downloaded to an SD or USB disk).

If update-nand spits out any errors, make sure you're running an
appropriately up-to-date version of OFW.  The q2d* series do not
support update-nand, and versions q2e18 and q2e19 are k

Re: [PATCH 1/3] olpc-battery: add support for CHARGE_FULL_DESIGN

2010-12-10 Thread David Woodhouse
On Fri, 2010-12-10 at 23:05 +0100, Sascha Silbe wrote:
> 
> +
> +   switch (tech.intval) {
> +   case POWER_SUPPLY_TECHNOLOGY_NiMH:
> +   switch (mfr) {
> +   case 1: /* Gold Peak */
> +   val->intval = 300*.8;
> +   break;
> +   default:
> +   return -EIO;
> +   }
> +   break;
> +
> +   case POWER_SUPPLY_TECHNOLOGY_LiFe:
> +   switch (mfr) {
> +   case 1: /* Gold Peak */
> +   val->intval = 280;
> +   break;
> +   case 2: /* BYD */
> +   val->intval = 310;
> +   break;
> +   default:
> +   return -EIO;
> +   }
> +   break;
> +
> +   default:
> +   return -EIO;
> +   }
> +
> +   return ret;
> +} 

I don't much like hard-coding it in the kernel. Can the firmware expose
these values in the device-tree?

-- 
dwmw2

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


[PATCH 2/3] olpc-battery: add support for CHARGE_NOW

2010-12-10 Thread Sascha Silbe
CHARGE_NOW is needed by some user space software (read: UPower) for internal
calculations.

This patch violates the power supply class definition (as we already
do for CAPACITY though it isn't as obvious there), but this is the best
we can do without adding rather sophisticated algorithms to either the EC
or UPower.

Signed-off-by: Sascha Silbe 
Signed-off-by: Paul Fox 

diff --git a/drivers/power/olpc_battery.c b/drivers/power/olpc_battery.c
index 1f01d4c..3993883 100644
--- a/drivers/power/olpc_battery.c
+++ b/drivers/power/olpc_battery.c
@@ -249,6 +249,24 @@ static int olpc_bat_get_charge_full_design(union 
power_supply_propval *val)
return ret;
 }
 
+static int olpc_bat_get_charge_now(union power_supply_propval *val)
+{
+   uint8_t soc;
+   union power_supply_propval full;
+   int ret;
+
+   ret = olpc_ec_cmd(EC_BAT_SOC, NULL, 0, &soc, 1);
+   if (ret)
+   return ret;
+
+   ret = olpc_bat_get_charge_full_design(&full);
+   if (ret)
+   return ret;
+
+   val->intval = soc * (full.intval / 100);
+   return 0;
+}
+
 /*
  * Battery properties
  */
@@ -347,6 +365,11 @@ static int olpc_bat_get_property(struct power_supply *psy,
if (ret)
return ret;
break;
+   case POWER_SUPPLY_PROP_CHARGE_NOW:
+   ret = olpc_bat_get_charge_now(val);
+   if (ret)
+   return ret;
+   break;
case POWER_SUPPLY_PROP_TEMP:
ret = olpc_ec_cmd(EC_BAT_TEMP, NULL, 0, (void *)&ec_word, 2);
if (ret)
@@ -395,6 +418,7 @@ static enum power_supply_property olpc_bat_props[] = {
POWER_SUPPLY_PROP_CAPACITY,
POWER_SUPPLY_PROP_CAPACITY_LEVEL,
POWER_SUPPLY_PROP_CHARGE_FULL_DESIGN,
+   POWER_SUPPLY_PROP_CHARGE_NOW,
POWER_SUPPLY_PROP_TEMP,
POWER_SUPPLY_PROP_TEMP_AMBIENT,
POWER_SUPPLY_PROP_MANUFACTURER,
-- 
1.7.2.3

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


[PATCH 1/3] olpc-battery: add support for CHARGE_FULL_DESIGN

2010-12-10 Thread Sascha Silbe
Some user space software (read: UPower) uses CHARGE_FULL_DESIGN for internal
calculations. The design capacity of the OLPC batteries is effectively fixed
and only needs to be exported.

Signed-off-by: Sascha Silbe 
Signed-off-by: Paul Fox 

diff --git a/drivers/power/olpc_battery.c b/drivers/power/olpc_battery.c
index 5bc1dcf..1f01d4c 100644
--- a/drivers/power/olpc_battery.c
+++ b/drivers/power/olpc_battery.c
@@ -201,6 +201,54 @@ static int olpc_bat_get_tech(union power_supply_propval 
*val)
return ret;
 }
 
+static int olpc_bat_get_charge_full_design(union power_supply_propval *val)
+{
+   uint8_t ec_byte;
+   union power_supply_propval tech;
+   int ret, mfr;
+
+   ret = olpc_bat_get_tech(&tech);
+   if (ret)
+   return ret;
+
+   ec_byte = BAT_ADDR_MFR_TYPE;
+   ret = olpc_ec_cmd(EC_BAT_EEPROM, &ec_byte, 1, &ec_byte, 1);
+   if (ret)
+   return ret;
+
+   mfr = ec_byte >> 4;
+
+   switch (tech.intval) {
+   case POWER_SUPPLY_TECHNOLOGY_NiMH:
+   switch (mfr) {
+   case 1: /* Gold Peak */
+   val->intval = 300*.8;
+   break;
+   default:
+   return -EIO;
+   }
+   break;
+
+   case POWER_SUPPLY_TECHNOLOGY_LiFe:
+   switch (mfr) {
+   case 1: /* Gold Peak */
+   val->intval = 280;
+   break;
+   case 2: /* BYD */
+   val->intval = 310;
+   break;
+   default:
+   return -EIO;
+   }
+   break;
+
+   default:
+   return -EIO;
+   }
+
+   return ret;
+}
+
 /*
  * Battery properties
  */
@@ -294,6 +342,11 @@ static int olpc_bat_get_property(struct power_supply *psy,
else
val->intval = POWER_SUPPLY_CAPACITY_LEVEL_NORMAL;
break;
+   case POWER_SUPPLY_PROP_CHARGE_FULL_DESIGN:
+   ret = olpc_bat_get_charge_full_design(val);
+   if (ret)
+   return ret;
+   break;
case POWER_SUPPLY_PROP_TEMP:
ret = olpc_ec_cmd(EC_BAT_TEMP, NULL, 0, (void *)&ec_word, 2);
if (ret)
@@ -341,6 +394,7 @@ static enum power_supply_property olpc_bat_props[] = {
POWER_SUPPLY_PROP_CURRENT_AVG,
POWER_SUPPLY_PROP_CAPACITY,
POWER_SUPPLY_PROP_CAPACITY_LEVEL,
+   POWER_SUPPLY_PROP_CHARGE_FULL_DESIGN,
POWER_SUPPLY_PROP_TEMP,
POWER_SUPPLY_PROP_TEMP_AMBIENT,
POWER_SUPPLY_PROP_MANUFACTURER,
-- 
1.7.2.3

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


[PATCH 3/3] olpc-battery: add support for CURRENT_NOW and VOLTAGE_NOW

2010-12-10 Thread Sascha Silbe
{CURRENT,VOLTAGE}_AVG are actually {CURRENT,VOLTAGE}_NOW (the EC code directly
passes through the value from the gas gauge instead of the internally used
average). We retain {CURRENT,VOLTAGE}_AVG as an alias for compatibility
reasons, it will be removed later.

Signed-off-by: Sascha Silbe 
[ p...@laptop.org: added VOLTAGE_NOW, aliased to VOLTAGE_AVG ]
Signed-off-by: Paul Fox 

diff --git a/drivers/power/olpc_battery.c b/drivers/power/olpc_battery.c
index 3993883..c087699 100644
--- a/drivers/power/olpc_battery.c
+++ b/drivers/power/olpc_battery.c
@@ -333,6 +333,7 @@ static int olpc_bat_get_property(struct power_supply *psy,
return ret;
break;
case POWER_SUPPLY_PROP_VOLTAGE_AVG:
+   case POWER_SUPPLY_PROP_VOLTAGE_NOW:
ret = olpc_ec_cmd(EC_BAT_VOLTAGE, NULL, 0, (void *)&ec_word, 2);
if (ret)
return ret;
@@ -340,6 +341,7 @@ static int olpc_bat_get_property(struct power_supply *psy,
val->intval = (s16)be16_to_cpu(ec_word) * 9760L / 32;
break;
case POWER_SUPPLY_PROP_CURRENT_AVG:
+   case POWER_SUPPLY_PROP_CURRENT_NOW:
ret = olpc_ec_cmd(EC_BAT_CURRENT, NULL, 0, (void *)&ec_word, 2);
if (ret)
return ret;
@@ -414,7 +416,9 @@ static enum power_supply_property olpc_bat_props[] = {
POWER_SUPPLY_PROP_HEALTH,
POWER_SUPPLY_PROP_TECHNOLOGY,
POWER_SUPPLY_PROP_VOLTAGE_AVG,
+   POWER_SUPPLY_PROP_VOLTAGE_NOW,
POWER_SUPPLY_PROP_CURRENT_AVG,
+   POWER_SUPPLY_PROP_CURRENT_NOW,
POWER_SUPPLY_PROP_CAPACITY,
POWER_SUPPLY_PROP_CAPACITY_LEVEL,
POWER_SUPPLY_PROP_CHARGE_FULL_DESIGN,
-- 
1.7.2.3

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


[PATCH 0/3] olpc-battery: add properties needed by UPower

2010-12-10 Thread Sascha Silbe
With these patches applied, UPower correctly calculates Percentage,
TimeToEmpty and TimeToFull for OLPC batteries.

Sascha Silbe (3):
  olpc-battery: add support for CHARGE_FULL_DESIGN
  olpc-battery: add support for CHARGE_NOW
  olpc-battery: add support for CURRENT_NOW and VOLTAGE_NOW

 drivers/power/olpc_battery.c |   82 ++
 1 files changed, 82 insertions(+), 0 deletions(-)

-- 
1.7.2.3

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: [Sugar-devel] prevent screen rotation in a sugar activity?

2010-12-10 Thread Erik Blankinship
Thank you for these suggestions.

It is sometimes a designer's prerogative to present their work in one
format.  Numerous examples are available on the iPhone and android markets.

Is it possible to override or be notified of a rotation signal?  Or is the
answer to really remap the display and input into my software, which seems
unfortunately complex.

"*The following software has been modified from its original version. It has
been formatted to fit this screen."*

On Thu, Dec 9, 2010 at 7:45 PM, James Simmons  wrote:

> Erik,
>
> If you use PyGTK to develop your Activity there are Layouts which will
> arrange your controls on the screen to make the best use of the
> available space.  In this way the app is still usable with the screen
> rotated.  In View Slides I detect when the screen dimensions change
> and resize the image I'm displaying.  You might look at the code for
> View Slides to see how I do that (or look at Read SD Comics which does
> the same thing but is simpler).
>
> Screen rotation is a useful feature of the XO.  Your Activity should
> be able to deal with it gracefully.
>
> James Simmons
>
>
> On Thu, Dec 9, 2010 at 8:51 AM, Erik Blankinship 
> wrote:
> > Is there a way to prevent a sugar activity from being rotated when there
> is
> > a screen rotation event on an olpc-xo or other hardware which support
> screen
> > rotation?
> > ___
> > Sugar-devel mailing list
> > sugar-de...@lists.sugarlabs.org
> > http://lists.sugarlabs.org/listinfo/sugar-devel
> >
> >
>
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: ArchLinux packages for Sugar

2010-12-10 Thread Bert Freudenberg

On 10.12.2010, at 09:18, Christophe Guéret wrote:

> Hi,
> 
> The sugar packages for Archlinux were orphans and outdated.
> I just adopted and updated a bunch of them: 
> http://aur.archlinux.org/packages.php?SeB=m&K=tolgam
> 
> If you are an Arch user, please have a look at them and let me know if 
> they work for you.
> 
> Cheers,
> Christophe

Not an Arch user here, but yay! :)

Since I guess this is not exclusively aimed at OLPC hardware I'd suggest 
announcing this on the Sugar mailing list, too:

http://lists.sugarlabs.org/listinfo/sugar-devel

- Bert -


___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


ArchLinux packages for Sugar

2010-12-10 Thread Christophe Guéret
Hi,

The sugar packages for Archlinux were orphans and outdated.
I just adopted and updated a bunch of them: 
http://aur.archlinux.org/packages.php?SeB=m&K=tolgam

If you are an Arch user, please have a look at them and let me know if 
they work for you.

Cheers,
Christophe
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


10.1.3 Testing page available

2010-12-10 Thread Simon Schampijer
Hi,

we have a page [1] available where you are invited to gather your
10.1.3 testing results. We hope to find out more quickly possibly
introduced regressions and get a sense of what works well. There are
some tests where details about the hardware you used are of interest to
us (e.g. Internet connection, USB2VGA). And of course, we hope it is fun 
for you to see a page like this grow!

Each 10.1.3 Feature has a section where you can comment. There are as
well some more generic tests like connecting to the Internet and
backwards compatibility tests. The last section has a list of bugs that
we think are important to test.

The current build available as of today is os358. All of the tests in
the page works as well with os357 if you have already downloaded that
one. The difference between os357 and os358 is *only* a new WikipediaEN, 
WikipediaES and a new Write and Paint activity.

Looking forward to the results,
 Simon

[1] http://wiki.laptop.org/go/10.1.3/Testing
[2] http://build.laptop.org/10.1.3/
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: USB to VGA

2010-12-10 Thread Simon Schampijer
On 12/09/2010 02:28 PM, Martin Langhoff wrote:
> On Tue, Dec 7, 2010 at 1:24 PM, Kevin Gordon  wrote:
>> Both 1.5's with both Startechs, with both monitors:  If the monitor is
>> already turned on, and already plugged into the USB port on the XO 1.5
>> before cold boot, the external monitor becomes active and looks fantastice,
>> every time.  This works on both the Sugar and Gnome boots.  System doesnt
>> seem to care if anyting else has been plugged into the USB port between
>> boots, still comes up first time every time.
>
> Great. Besides looking fantastic, does it work well? ;-)
>
>> Both 1.0's with both Startechs with both monitors:  If the monitor is
>> already turned on, and already plugged into the USB port on the XO 1.0
>> before cold boot, the external monitor becomes active and looks fantastic,
>> most the time.  This is the case on both the Sugar and Gnome boots.  The
>> most the time comes from :  If I have plugged a different USB device into
>> the port between boots, the XO 1.0 stalls at the 'third dot around the
>> circle' during boot and flashes the external monitor.
>
> That is very strange. Can you elaborate on the "a different usb
> device"? Can you give us exact steps to repro?
>
>> I have had absolutely no success in plugging any adapter with any monitor
>> into any of the XO's after XO is up.  LSUSB recognizes the adapter, but
>> doesn't activate the external monitor.
>
> Correct. We cannot reconfigure while running. You can in some cases
> where the 2 video ports are on the same card and you have recent
> drivers. But not inserting a new video device as we do in this case.
>
>> I have had no success in unplugging the adapter while the external monitor
>> is active.  The internal XO display does not come back active, and
>> replugging the external adapter does not bring the external monitor back
>> active.  Oops, now need to Power off again.
>
> Please try this again -- the external monitor will take a few seconds
> but in my testing it does come back.
>
>> Another little note, when the external becomes active when booting the Sugar
>> desktop, the internal display goes blank, once the External goes active.
>> When booting on the Gnome side, the internal display continues to display a
>> sort of console output, but it remains static.
>
> Minor oddity I guess.
>
> thanks for the testing!
>
>
>
> m

Hi Kevin,

thanks for testing. You might as well like to log your findings here: 
http://wiki.laptop.org/go/10.1.3/Testing#USB2VGA_Adapter_usage

Thanks,
Simon
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel