Re: [PATCH 1/3] olpc-battery: add support for CHARGE_FULL_DESIGN
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?
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?
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
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
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
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
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
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
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
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
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
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
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
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
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
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
{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
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?
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
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
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
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
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
