Re: power consumption after shutdown
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" ? 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
Re: power consumption after shutdown
On Sat, Feb 14, 2009 at 08:26:13PM -0500, Mikus Grinbergs wrote: > This gets more and more bizarre !! No, it's just physics and chemistry, constrained by engineering. Please, if you think it is bizarre, explain why you think so, and I'll happily explain the physics that I know. > 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. > [When I insert that battery and plug in the AC adapter, the 'power' > light is green, and 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 presume that when I merely "shut down" the XO, and leave it > sitting for two days with the battery still in the case: Then when > I again connect the XO to the AC adapter (and let it charge until > the 'power' light goes from yellow to green), I should be able to > trust that what the software pop-up says is accurate. No. It will be close to the true value most of the time, unless there is damage. By close I mean within 20% or so, 90% of the time, assuming no external use of the battery. I'm just giving you personal estimates there, I don't have all the data. > 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. The state of charge value that you refer to is calculated. It is an estimate. It often represents reality. The calculation is done by the EC based on a measurement of current flowing into or out of the battery, since the battery was manufactured. The measurement is over time, so it is called accumulation. Measurement is done by the EC using the battery support chip in the battery pack. The results are stored in the chip. Measurement does not occur of either chemical self-discharge, or external discharge by some other means. -- James Cameronmailto:qu...@us.netrek.org http://quozl.netrek.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] 'Resume activity' is confusing for user
Mikus, On 15 Feb 2009, at 00:24, Mikus Grinbergs wrote: > My observation from running Joyride 2650 on an XO-1: > > With 'Resume by default' checked in the "Favorite view" dropdown in > Home View, those activity_icons for which a Journal entry now exists > are colored. I __naively__ thought that if I clicked on a "colored" > icon, the *existing* session for that activity would be resumed. You're 3 weeks late ;-) It was a bug, I'm 99% sure Tomeu has this is fixed, if you're using a current build of sugar here's the ticket: http://dev.sugarlabs.org/ticket/238 Here's the rub... Joyride is dead (though for an XO user it's still about the easiest/smoothest way to play with the new sugar toys). It got a Sugar code update back in 2631, making it to sugar 0.83.3 from what I can tell (~19 Jan 2009); but there're just not enough hands on deck to keep that plate spinning. FWIW I've been able to copy-nand and use the image called soas3.img that Marco was kind enough to get an image built and working: http://download.sugarlabs.org/soas/xoimages/ ... but again I fear this is now an end of line unless another engineer can continue the work. I'm not convinced the world of XO users will see much, if any more, output from SugarLabs for a long time, the only hope I see is to run 'Sugar on a Stick' USB spins (Fedora being currently the most tested/working) – but only for testing purposes – the normal Fedora is still far off the level of XO hardware support that the 8.2.x OLPC Fedora fork currently provides. Actually, the latest Fedora SoaS USB image I've tried to boot on an XO just kernel panics, so Marco's above effort is, perhaps the last, most recent XO booting Sugar. With all that doom and gloom, I must say that OLPC 8.2.1 (candidate-800) is looking rather nice in comparison, get some testing in if you can, we may be using it for some time... Regards, --Gary > But when in Home View I moved the cursor to the (colored) icon for > Terminal and left-clicked, a *second* Terminal session was launched. > > > Apparently, to be sure of what one is doing with a colored icon in > Home View, one needs to right-click on that icon, and wait for its > palette to be displayed. Then, to 'Resume' a session, right-click > on an entry in the palette for which an object name is listed. Or, > to 'start' a new session, click on the palette entry that lists the > plain activity name (or click on the 'Start' entry near the bottom > of the palette). > > > I ought to be able to explain all this to a "Sugar" user (including > when there are "special cases" and when there are not). But much > simpler to just tell him to forget about 'Resume by default'. > > > mikus > > > p.s. Suggestion: when clicking on an icon in Home View favorites > will not result in 'returning control' to an already-launched > Activity, *don't* color that icon. > > ___ > 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: power consumption after shutdown
This gets more and more bizarre !! James wrote: > The displayed state of charge is stored in the chip in the battery, and > is maintained by the EC. The battery does not change it's own state of > charge value. and > (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".) 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. [When I insert that battery and plug in the AC adapter, the 'power' light is green, and the software pop-up says 94%. But I notice that after an hour, the software pop-up *still* says 94%.] I presume that when I merely "shut down" the XO, and leave it sitting for two days with the battery still in the case: Then when I again connect the XO to the AC adapter (and let it charge until the 'power' light goes from yellow to green), I should be able to trust that what the software pop-up says is accurate. 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" ? mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: power consumption after shutdown
On Sat, Feb 14, 2009 at 01:56:22PM -0500, Mikus Grinbergs wrote: > I have found the XO-1 batteries (mfg by BYD Company Ltd) to be very > stingy with energy loss. When I put one back in after a month out > of the case, the XO software told me it was still 94% charged. The displayed state of charge is stored in the chip in the battery, and is maintained by the EC. The battery does not change it's own state of charge value. I don't think that batteries outside the XO will have their state of charge value changed by the chemical self-discharge process. But once the terminal voltage becomes significantly inconsistent with the state of charge value, I imagine that the terminal voltage is trusted more. (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".) > James Cameron mentioned measuring a current draw of 24mA. I suspect > this was *not* on a thoroughly "shut-down" G1G1. Wrong. It was on a thoroughly shutdown mass production unit. The unit was shutdown using the Sugar shutdown option, then the DC cable and the battery were removed, 30 seconds were allowed to elapse, and then the DC cable was reinserted. The measurement was after this reinsertion. > In my experience, > after two days in a "shut-down" state the XO software shows the > battery charge % to be somewhere in the mid-90's. You observe a difference between my measurements and yours. I knew the technique was inadequate, but I was providing it as a maximum. I had already said that I thought the external DC supply path to contain additional losses. Richard has explained that the difference was due to the EC not stopped, because it knows it is on external DC supply. -- James Cameronmailto:qu...@us.netrek.org http://quozl.netrek.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO BW mode (was Re: Guidance sought on collaboration techniques)
2009/2/14 Wade Brainerd : >> The below will switch to BW, but still leave the backlight on: I recall that there are several people requesting a hot-key for this mode since the B4 era. However, it's not adopted since then. It's not really a BW mode; it just makes DCON think it's in BW as the color filter can't be "turned off". So the result is similar to "sub-pixel rendering" or "clear type"... whatever you call it. (DCON does use each "pixel" to render contents in this mode) I do think this is very useful when color is not needed and the displayed font will be crisp. Surely this may introduce confusion and probably the reason it's not adopted? http://picasaweb.google.com/lh/photo/sAslAOFF3Iz5xHNlc39Qvg?feat=directlink http://picasaweb.google.com/lh/photo/4nJ-POA6g7u_d4-YuVQGNA?feat=directlink Some people don't like this mode as some slight color "leak" around the strokes. (same for white on black) But this doesn't affect much for ebook reading. (at least for me it's most useful for reading) -- Best regards, Yuan Chao ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: power consumption after shutdown
Richard A. Smith wrote: > into STOP mode but its power draw suggests otherwise. I'll have to > study it deeper. After deeper study I have verified that the EC is going into stop mode. I have also found the (biggest) source of the additional power draw I measured. The tinder box XO has the EC serial port connector loaded and has a TTL->USB adapter connected. The 3.3V EC rail is ORed in with the 3.3V regulator from the 5V USB since the device can be powered by either side. Disconnecting the EC serial port drops the power draw to 1.6mA. This also tells me that the reading listed as EC is not just the EC but all the devices connected to that rail. The instrumented setup only has a current measurement resolution down to about 1mA. So there's room for a lot of error in that measurement. Looking at the schematics I see that there are quite a few other parts that share the 3.3V rail with the EC so 1mA or so seems reasonable. I've started a long term measurement test using the ACR guage inside the battery. I'll check it on Monday. -- Richard Smith One Laptop Per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
New joyride build 2654
http://xs-dev.laptop.org/~cscott/olpc/streams/joyride/build2654 Changes in build 2654 from build: 2652 Size delta: 0.00M -pkgconfig 1:0.23-3.fc10 +pkgconfig 1:0.23-6.fc10 -- This mail was automatically generated See http://dev.laptop.org/~rwh/announcer/joyride-pkgs.html for aggregate logs See http://dev.laptop.org/~rwh/announcer/joyride_vs_update1.html for a comparison ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO BW mode (was Re: Guidance sought on collaboration techniques)
On Sat, 14 Feb 2009, Gary C Martin wrote: > On 14 Feb 2009, at 10:16, Bert Freudenberg wrote: > >> >> The blur you see in color mode is the DCON performing anti-aliasing >> by adding color components from the four neighboring pixels into >> each pixel (e.g., for a red pixel it takes the red components of the >> surrounding pixels into account, etc). >> >> In early DCON drivers it was possible to toggle the anti-aliasing >> independently of the backlight intensity, so you could clearly see >> its effect. IIUC this capability has now been coupled to the >> backlight intensity, which is fine in regular use, but takes away >> the possibility to easily demonstrate what's happening. > > You do appear to be wrong here. Have access to three XOs here (two MP > and one B4) that all happily respond to the below command: > > su > echo 1 > /sys/devices/platform/dcon/output > > Disables colour while leaving the backlight setting alone, allowing a > slightly crisper BW display with backlight on if you want it (close > look at text edges reminds me of the little colour pixels you get with > sub-pixel resolution tricks on conventional screens), and: > > su > echo 0 > /sys/devices/platform/dcon/output > > Enables colour while leaving the backlight setting alone, allowing a > 'colour display' mode when the backlight is potentially off (not a > very useful combination as it's the backlight that goes through the > colour layer so you're left looking at a slightly soft BW image from > just reflected light). the acceptability of the result is going to depend greatly on what you are displaying. if you have black text on a white background disabling the color bluring mode (anti-aliasing, whatever you want to call it) works pretty well. however, if you have white text on a black background you end up with a rainbow instead of a readable display. the worst case I saw of this was a graph display (I think it was an audio program, but I don't remember which one). it drew a thin white line on a black background, when disabling the color mode and leaving the backlight on each pixel of the graph was a different color and it really showed up that way. however, when you do the black lines on a white background there appears to be enough other colors around that your eyes still see the lighted pixels as white and the black lines look pretty good. David Lang ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: power consumption after shutdown
On 14 Feb 2009, at 19:24, Richard A. Smith wrote: > > While running on eternal power the EC does not attempt to enter a low > power mode. s/eternal/external/ ? Although, to be honest, I'd love to believe you were right... ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: power consumption after shutdown
Richard A. Smith wrote: > going into STOP mode the EC is only going into IDEL mode. In IDEL the > instruction fetch is turned off but the clocks and timers still run. 4mA > is listed as the nominal draw in that mode. /s/IDEL/IDLE -- Richard Smith One Laptop Per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: power consumption after shutdown
da...@lang.hm wrote: >> The embedded controller was. Something needs to be watching for a >> power button press in order to know when to turn on. > > by default the wireless card remains alive to participate in a > potential mesh network, disabling wireless should give you a lot more > time. In power off the the WLAN is not powered up. Only the EC remains powered. > from the XO. Self-discharge rate has a dependency on storage > temperature as well. The self discharge of LiFePO4 is quite low. The numbers thrown about in the marketing docs are between 3-5%/month. Based on the values in the datasheet I calculate ours to be 3.8%/month at 25 degC. However, its highly temperature dependent. The datasheet suggests that at temps >= 45 degC its 33%/month and at 60 degC 100%/month. This has be somewhat experimentally verified. There were a few boxes of laptops stored in a temp controlled environment for at least a year and when I examined those batteries they still had plenty of life but, batteries sent to Jordan that were stored in a hot warehouse arrived completely discharged. > I did this just now, on a unit running Q2E27, and another running > Q2E30, the current is 24mA at 12.9V powered from a large sealed lead > acid battery with nothing else attached. Two days of this would be > 1.15 amp hours (Ah). Three days would be 1.73 Ah. While running on eternal power the EC does not attempt to enter a low power mode. This is because its monitoring the battery. This is sub-optimal while on things like solar power so at some point this may roll up on the "Fixme:" list but theres a lot of conditions that have to be dealt with. For now Ext power == EC on full. When powered off and on battery power only the EC attempts to to go into the STOP state where power consumption is much less. Not as low as it should be (see below) but much less. > days later I insert the AC adapter into the (still closed) XO, after > the 'power' light comes on, it goes yellow. [I've seen this both > when I was running 'joyride' on the XO, and when I was running > 'staging'.] I take this to mean that *something* was draining some > power for the two days the XO was sitting in its "shut down" state. As mentioned above the EC attempts to go into STOP mode when the power is off and not plugged up to external power. The data sheet indicates that STOP mode is supposed to be in the 10s of uA range. Measurements taken (this morning against my EC dev tree) via instrumented XO indicate that its 4mA. Studying the datasheet that suggests that rather then going into STOP mode the EC is only going into IDEL mode. In IDEL the instruction fetch is turned off but the clocks and timers still run. 4mA is listed as the nominal draw in that mode. Looking at the EC code the go-into-STOP-mode rather than the go-into-IDEL-mode bit is getting set. So the code is _trying_ to go into STOP mode but its power draw suggests otherwise. I'll have to study it deeper. In anycase @ a 4mA draw the EC will see the net ACR diff at about 3.1%/24hours so across 2 days you would have probably discharged enough for the EC to enable the charger to top up the battery. -- Richard Smith One Laptop Per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: power consumption after shutdown
Hi, >> You're thinking of sleep mode, not the full shutdown that Mikus is >> doing. > That's not how I learned it. The wireless was designed to remain > active when everything else was off, in order to support mesh > networking throughout a community. Regardless of how you learned it, the wireless chip is shut down completely in shutdown mode. It functions as you describe when in sleep mode, which is (still) not what Mikus was talking about. - Chris. -- Chris Ball ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: power consumption after shutdown
edward wrote: > On Fri, Feb 13, 2009 at 8:38 PM, Chris Ball wrote: > > Hi, > > > > > by default the wireless card remains alive to participate in a > > > potential mesh network, disabling wireless should give you a lot > > > more time. > > > > You're thinking of sleep mode, not the full shutdown that Mikus is doing. > > That's not how I learned it. The wireless was designed to remain > active when everything else was off, in order to support mesh > networking throughout a community. However, I don't see any no. not when the laptop is "off". as chris said -- only when it's sleeping. paul =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: power consumption after shutdown
On Fri, Feb 13, 2009 at 8:38 PM, Chris Ball wrote: > Hi, > > > by default the wireless card remains alive to participate in a > > potential mesh network, disabling wireless should give you a lot > > more time. > > You're thinking of sleep mode, not the full shutdown that Mikus is doing. That's not how I learned it. The wireless was designed to remain active when everything else was off, in order to support mesh networking throughout a community. However, I don't see any measurements for that, although the wireless chip draws less than a watt. Perhaps someone would be willing to add it to http://wiki.laptop.org/go/XO_power_draw > - Chris. > -- > Chris Ball > ___ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel > -- Silent Thunder (默雷/धर्ममेघशब्दगर्ज/دھرممیگھشبدگر ج) is my name And Children are my nation. The Cosmos is my dwelling place, The Truth my destination. http://wiki.sugarlabs.org/go/User:Mokurai (Ed Cherlin) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: power consumption after shutdown
Chris Ball and Paul Fox responded: > > I take this to mean that *something* was draining some power for > > the two days the XO was sitting in its "shut down" state. > > The embedded controller was. Something needs to be watching for a power > button press in order to know when to turn on. Thank you. I guess it's simpler to do it that way, than to add two extra "latches" to the package. [2 latches might work as follows: One latch would be turned on when sent electricity through the power button. This first latch would turn on the second latch if that second latch was off. The software could test the first latch state, and could turn that state off when it wanted to be watching for a power button press. The second latch would connect the battery to the motherboard proper. It would be turned off by the software for "zero power drain" mode.] Benjamin Schwartz wrote: > All rechargeable batteries lose stored energy over time. > This phenomenon is called "self-discharge". True. I have found the XO-1 batteries (mfg by BYD Company Ltd) to be very stingy with energy loss. When I put one back in after a month out of the case, the XO software told me it was still 94% charged. James Cameron mentioned measuring a current draw of 24mA. I suspect this was *not* on a thoroughly "shut-down" G1G1. In my experience, after two days in a "shut-down" state the XO software shows the battery charge % to be somewhere in the mid-90's. James wrote: > If you wish to avoid this draining by the EC, and instead rely only on > draining by self-discharge of the battery pack, then remove the pack > from the XO. Self-discharge rate has a dependency on storage > temperature as well. Thanks, mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: DebXO 0.5 release
On Fri, 13 Feb 2009 18:06:03 -0500 Andres Salomon wrote: > Hi, > > I've just built and tagged DebXO 0.5. I had to put this out sooner > than I'd anticipated due to an OFW upgrade that broke things. It > doesn't have some of the features I'd wanted to have in 0.5, so > they'll have to come later. > [...] > > - There's a new XFCE desktop, courtesy of Erik Garrison. > One thing we overlooked; the XFCE desktop doesn't have a browser installed by default. Oops! 'sudo apt-get install epiphany-browser' or 'sudo apt-get install iceweasel' will fix that for you. I've fixed this in the git repository, so the next debxo version will include epiphany-browser in the XFCE desktop. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO BW mode (was Re: Guidance sought on collaboration techniques)
On 14.02.2009, at 17:24, Gary C Martin wrote: > On 14 Feb 2009, at 10:16, Bert Freudenberg wrote: > >> >> On 13.02.2009, at 19:27, Gary C Martin wrote: >>> >>> Note the backlight goes through the colour refractive screen magic, >>> even in BW mode, so it's not as sharp as with the backlight 100% off >> >> That explanation is horrendously wrong. Please do not perpetuate >> the rumor of "modes" in the display hardware. There are none. > > Horrendously wrong? Wow... well Bert you've been with the project > for way longer than me so I do trust you to be right, I must have > hit a nerve, sorry. > >> And, there is no "refractive screen magic", that idea did not make >> it into production. The backlight uses regular r/g/b color filters. > > Was my 'refractive' faux pas your only reason for using > 'horrendously wrong'? I guess the term I should have given there was > 'transflective', apologies to optical geeks everywhere. I couldn't > see any obvious errors else where. You attributed the decrease in sharpness to some "colour refractive screen magic". There is no magic and it got nothing to do with the screen at all. >> The blur you see in color mode is the DCON performing anti-aliasing >> by adding color components from the four neighboring pixels into >> each pixel (e.g., for a red pixel it takes the red components of >> the surrounding pixels into account, etc). >> >> In early DCON drivers it was possible to toggle the anti-aliasing >> independently of the backlight intensity, so you could clearly see >> its effect. IIUC this capability has now been coupled to the >> backlight intensity, which is fine in regular use, but takes away >> the possibility to easily demonstrate what's happening. > > You do appear to be wrong here. I'd be glad to be wrong, but that's not the flag I meant. That one did not disable color, but only the anti-aliasing. That is, you could see colors, but it was crisp (leading to colored fringes so that's why the setting is not available independently anymore). The fact that you can't change the AA independently of the color-to-grayscale conversion makes it appear as if the two were intrinsically coupled. > Have access to three XOs here (two MP and one B4) that all happily > respond to the below command: > > su > echo 1 > /sys/devices/platform/dcon/output > > Disables colour while leaving the backlight setting alone, allowing > a slightly crisper BW display with backlight on if you want it > (close look at text edges reminds me of the little colour pixels you > get with sub-pixel resolution tricks on conventional screens), and: > > su > echo 0 > /sys/devices/platform/dcon/output > > Enables colour while leaving the backlight setting alone, allowing a > 'colour display' mode when the backlight is potentially off (not a > very useful combination as it's the backlight that goes through the > colour layer so you're left looking at a slightly soft BW image from > just reflected light). If the backlight is on and there is not much ambient light in the room you see *no* reflected light, simply because there is no light to be reflected. If you are in the sun there is so much reflected light you see no colored background light anymore. > I can try and take some pixel macro photos of the effect if it makes > you feel better? :-) > > http://wiki.laptop.org/go/Display#DCON_screen_driver_chip Thanks, I do feel fine ;) I am however slightly frustrated (and I'm not even one of the OLPC engineers) about all the misinformation spread about the XO. Didn't mean to be offensive though, please chalk this up to English being not my mother tongue. - Bert - ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO BW mode (was Re: Guidance sought on collaboration techniques)
On 14 Feb 2009, at 10:16, Bert Freudenberg wrote: > > On 13.02.2009, at 19:27, Gary C Martin wrote: >> >> Note the backlight goes through the colour refractive screen magic, >> even in BW mode, so it's not as sharp as with the backlight 100% off > > That explanation is horrendously wrong. Please do not perpetuate the > rumor of "modes" in the display hardware. There are none. Horrendously wrong? Wow... well Bert you've been with the project for way longer than me so I do trust you to be right, I must have hit a nerve, sorry. > And, there is no "refractive screen magic", that idea did not make > it into production. The backlight uses regular r/g/b color filters. Was my 'refractive' faux pas your only reason for using 'horrendously wrong'? I guess the term I should have given there was 'transflective', apologies to optical geeks everywhere. I couldn't see any obvious errors else where. > The blur you see in color mode is the DCON performing anti-aliasing > by adding color components from the four neighboring pixels into > each pixel (e.g., for a red pixel it takes the red components of the > surrounding pixels into account, etc). > > In early DCON drivers it was possible to toggle the anti-aliasing > independently of the backlight intensity, so you could clearly see > its effect. IIUC this capability has now been coupled to the > backlight intensity, which is fine in regular use, but takes away > the possibility to easily demonstrate what's happening. You do appear to be wrong here. Have access to three XOs here (two MP and one B4) that all happily respond to the below command: su echo 1 > /sys/devices/platform/dcon/output Disables colour while leaving the backlight setting alone, allowing a slightly crisper BW display with backlight on if you want it (close look at text edges reminds me of the little colour pixels you get with sub-pixel resolution tricks on conventional screens), and: su echo 0 > /sys/devices/platform/dcon/output Enables colour while leaving the backlight setting alone, allowing a 'colour display' mode when the backlight is potentially off (not a very useful combination as it's the backlight that goes through the colour layer so you're left looking at a slightly soft BW image from just reflected light). I can try and take some pixel macro photos of the effect if it makes you feel better? :-) http://wiki.laptop.org/go/Display#DCON_screen_driver_chip --Gary > - Bert - ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO BW mode (was Re: Guidance sought on collaboration techniques)
On 13.02.2009, at 19:27, Gary C Martin wrote: > > Note the backlight goes through the colour refractive screen magic, > even in BW mode, so it's not as sharp as with the backlight 100% off That explanation is horrendously wrong. Please do not perpetuate the rumor of "modes" in the display hardware. There are none. And, there is no "refractive screen magic", that idea did not make it into production. The backlight uses regular r/g/b color filters. The blur you see in color mode is the DCON performing anti-aliasing by adding color components from the four neighboring pixels into each pixel (e.g., for a red pixel it takes the red components of the surrounding pixels into account, etc). In early DCON drivers it was possible to toggle the anti-aliasing independently of the backlight intensity, so you could clearly see its effect. IIUC this capability has now been coupled to the backlight intensity, which is fine in regular use, but takes away the possibility to easily demonstrate what's happening. - Bert - ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
