automatic backlight control
this note is kind of long for what seems like a simple feature, but there are some complications i'd like feedback on. i've implemented one of the more amusing features of the 1.75 laptop, which is using its ability to monitor ambient light levels in order to turn off the backlight automatically when you're in bright enough light where you really don't need it -- i.e., mostly when outside in full sun. support for this feature is in the os11, but it's buggy -- os12 will be quite a bit better. this isn't an auto-dim feature -- in bright sunlight, the backlight is turned off, and when the environment isn't bright enough, the backlight is returned to its previous level. it's on or off -- nothing in between. (the _very_ inexpensive light sensor isn't really sensitive enough to allow for finer-grained control than this.) in working on this, i was reminded that currently, when we manually dim the backlight level to 0 (i.e., turn it off) with the keyboard keys, we also change the display's mode from color to monochrome. switching to mono mode effectively raises the screen resolution, giving crisper characters and lines. [1] to my knowledge, this is the only way in which monochrome mode can be invoked. my auto-backlight code did this too, at first, but once backlight control starts happening without user input, this auto-monochrome feature is a bit annoying. it looks much better if turning off the backlight (which happens in full sunlight) doesn't remove the residual color which was there moments before, when, say, a cloud was in front of the sun. (you can see this effect on your XO: take it into full sunlight, and reduce the brightness all the way. then alternately bump it to '1', then back to 0, and you'll see the bit of color that gets gained and lost.) so -- when automatically turning off the backlight, i don't switch the display to monochrome. it quickly became clear (to me, at least) that it would be confusing if user-dimming behaved differently than auto-backlight-control, with respect to monochrome mode. whether or not it's confusing to the user, it's definitely confusing to the code, since it's difficult to always do the right thing if the user and the sensor are both changing the brightness at the same time. so i disabled the switch to monochrome entirely -- using the brightness keys doesn't change the color/mono setting. but monochrome mode has it's advantages, and in the past i've had requests that it should be more available, rather than less. to that end, i've added the ability to force the screen into monochrome hi-res mode manually -- when enabled, it remains monochrome no matter what the brightness is set to. this essentially makes the higher display crispness available indoors as well. this toggle is available with Ctrl-Brightness-Down (for mono) and Ctrl-Brightness-Up (for color). it's also available on the commandline, by usingolpc-brightness [mono|color]. finally: because i think the user experience needs to be uniform across the laptops, these changes will affect XO-1 and XO-1.5 too, even though they have no auto-backlight control. i've already had some guarded negative feedback on both of these new behaviors, so i'm looking for more of that, as well as positive feedback to balance it out. :-) the criticisms were that roughly that: 1) getting rid of monochrome when dimmed to 0 is a major UI change. for my part, i'm not sure i agree that it's so major a change. plus, i'm not sure the feature was well implemented in the first place. (i.e., why no mono mode with the backlight on?) 2) the replacement color/mono control is completely undiscoverable. i guess i'd have to agree with this. there should probably be a UI control for the toggle as well, but i'm not sure it's an important enough feature to warrant frame real estate, for example. please discuss. i realize it's hard to talk about this in the abstract, since most of you don't have 1.75 machines to play with. if you do have one, please try it when os12 comes out. paul [1] http://wiki.laptop.org/go/Display#The_theory =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] automatic backlight control
On Mon, Nov 21, 2011 at 9:22 AM, Paul Fox p...@laptop.org wrote: this note is kind of long for what seems like a simple feature, but there are some complications i'd like feedback on. i've implemented one of the more amusing features of the 1.75 laptop, which is using its ability to monitor ambient light levels in order to turn off the backlight automatically when you're in bright enough light where you really don't need it -- i.e., mostly when outside in full sun. support for this feature is in the os11, but it's buggy -- os12 will be quite a bit better. this isn't an auto-dim feature -- in bright sunlight, the backlight is turned off, and when the environment isn't bright enough, the backlight is returned to its previous level. it's on or off -- nothing in between. (the _very_ inexpensive light sensor isn't really sensitive enough to allow for finer-grained control than this.) in working on this, i was reminded that currently, when we manually dim the backlight level to 0 (i.e., turn it off) with the keyboard keys, we also change the display's mode from color to monochrome. switching to mono mode effectively raises the screen resolution, giving crisper characters and lines. [1] to my knowledge, this is the only way in which monochrome mode can be invoked. my auto-backlight code did this too, at first, but once backlight control starts happening without user input, this auto-monochrome feature is a bit annoying. it looks much better if turning off the backlight (which happens in full sunlight) doesn't remove the residual color which was there moments before, when, say, a cloud was in front of the sun. (you can see this effect on your XO: take it into full sunlight, and reduce the brightness all the way. then alternately bump it to '1', then back to 0, and you'll see the bit of color that gets gained and lost.) so -- when automatically turning off the backlight, i don't switch the display to monochrome. it quickly became clear (to me, at least) that it would be confusing if user-dimming behaved differently than auto-backlight-control, with respect to monochrome mode. whether or not it's confusing to the user, it's definitely confusing to the code, since it's difficult to always do the right thing if the user and the sensor are both changing the brightness at the same time. so i disabled the switch to monochrome entirely -- using the brightness keys doesn't change the color/mono setting. but monochrome mode has it's advantages, and in the past i've had requests that it should be more available, rather than less. to that end, i've added the ability to force the screen into monochrome hi-res mode manually -- when enabled, it remains monochrome no matter what the brightness is set to. this essentially makes the higher display crispness available indoors as well. this toggle is available with Ctrl-Brightness-Down (for mono) and Ctrl-Brightness-Up (for color). it's also available on the commandline, by usingolpc-brightness [mono|color]. finally: because i think the user experience needs to be uniform across the laptops, these changes will affect XO-1 and XO-1.5 too, even though they have no auto-backlight control. i've already had some guarded negative feedback on both of these new behaviors, so i'm looking for more of that, as well as positive feedback to balance it out. :-) the criticisms were that roughly that: 1) getting rid of monochrome when dimmed to 0 is a major UI change. for my part, i'm not sure i agree that it's so major a change. plus, i'm not sure the feature was well implemented in the first place. (i.e., why no mono mode with the backlight on?) 2) the replacement color/mono control is completely undiscoverable. i guess i'd have to agree with this. there should probably be a UI control for the toggle as well, but i'm not sure it's an important enough feature to warrant frame real estate, for example. please discuss. i realize it's hard to talk about this in the abstract, since most of you don't have 1.75 machines to play with. if you do have one, please try it when os12 comes out. paul [1] http://wiki.laptop.org/go/Display#The_theory =- paul fox, p...@laptop.org ___ Sugar-devel mailing list sugar-de...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel Paul, Unless the display design is different than it was in 2007, then there is no way to decouple turning off the backlight and going into monochrome. Also, turning on the backlight adds color back (although the amount of color vs monochrome in the mix is a function of the backlight vs ambient-light levels. So I am not sure we could implement your proposal with the current hardware. -walter -- Walter Bender Sugar Labs http://www.sugarlabs.org ___
Re: [Sugar-devel] automatic backlight control
On 21.11.2011, at 15:29, Walter Bender wrote: Paul, Unless the display design is different than it was in 2007, then there is no way to decouple turning off the backlight and going into monochrome. Also, turning on the backlight adds color back (although the amount of color vs monochrome in the mix is a function of the backlight vs ambient-light levels. So I am not sure we could implement your proposal with the current hardware. -walter This is about switching the DCON's hardware anti-aliasing. OLPC has started to refer to that as color vs monochrome mode (presumably because it's hard to explain to others why you would or would not want AA). Here's how it works: http://www.squeakland.org/showcase/project.jsp?id=7050 - Bert - ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] automatic backlight control
On 21.11.2011, at 15:48, Bert Freudenberg wrote: On 21.11.2011, at 15:29, Walter Bender wrote: Paul, Unless the display design is different than it was in 2007, then there is no way to decouple turning off the backlight and going into monochrome. Also, turning on the backlight adds color back (although the amount of color vs monochrome in the mix is a function of the backlight vs ambient-light levels. So I am not sure we could implement your proposal with the current hardware. -walter This is about switching the DCON's hardware anti-aliasing. OLPC has started to refer to that as color vs monochrome mode (presumably because it's hard to explain to others why you would or would not want AA). Here's how it works: http://www.squeakland.org/showcase/project.jsp?id=7050 - Bert - Err, and the color-averaging I always tend to forget about. The DCON selects either just a single color component for a pixel (color mode) or combines red, green, and blue into a per-pixel value (monochrome mode). In early hw versions this could be toggled separately from the anti-aliasing, while in MP hardware those two were combined IIUC. - Bert - ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] automatic backlight control
On Mon, Nov 21, 2011 at 9:22 AM, Paul Fox p...@laptop.org wrote: this note is kind of long for what seems like a simple feature, but there are some complications i'd like feedback on. i've implemented one of the more amusing features of the 1.75 laptop, which is using its ability to monitor ambient light levels in order to turn off the backlight automatically when you're in bright enough light where you really don't need it -- i.e., mostly when outside in full sun. support for this feature is in the os11, but it's buggy -- os12 will be quite a bit better. this isn't an auto-dim feature -- in bright sunlight, the backlight is turned off, and when the environment isn't bright enough, the backlight is returned to its previous level. it's on or off -- nothing in between. (the _very_ inexpensive light sensor isn't really sensitive enough to allow for finer-grained control than this.) in working on this, i was reminded that currently, when we manually dim the backlight level to 0 (i.e., turn it off) with the keyboard keys, we also change the display's mode from color to monochrome. switching to mono mode effectively raises the screen resolution, giving crisper characters and lines. [1] to my knowledge, this is the only way in which monochrome mode can be invoked. my auto-backlight code did this too, at first, but once backlight control starts happening without user input, this auto-monochrome feature is a bit annoying. it looks much better if turning off the backlight (which happens in full sunlight) doesn't remove the residual color which was there moments before, when, say, a cloud was in front of the sun. (you can see this effect on your XO: take it into full sunlight, and reduce the brightness all the way. then alternately bump it to '1', then back to 0, and you'll see the bit of color that gets gained and lost.) so -- when automatically turning off the backlight, i don't switch the display to monochrome. it quickly became clear (to me, at least) that it would be confusing if user-dimming behaved differently than auto-backlight-control, with respect to monochrome mode. whether or not it's confusing to the user, it's definitely confusing to the code, since it's difficult to always do the right thing if the user and the sensor are both changing the brightness at the same time. so i disabled the switch to monochrome entirely -- using the brightness keys doesn't change the color/mono setting. but monochrome mode has it's advantages, and in the past i've had requests that it should be more available, rather than less. to that end, i've added the ability to force the screen into monochrome hi-res mode manually -- when enabled, it remains monochrome no matter what the brightness is set to. this essentially makes the higher display crispness available indoors as well. this toggle is available with Ctrl-Brightness-Down (for mono) and Ctrl-Brightness-Up (for color). it's also available on the commandline, by usingolpc-brightness [mono|color]. finally: because i think the user experience needs to be uniform across the laptops, these changes will affect XO-1 and XO-1.5 too, even though they have no auto-backlight control. i've already had some guarded negative feedback on both of these new behaviors, so i'm looking for more of that, as well as positive feedback to balance it out. :-) the criticisms were that roughly that: 1) getting rid of monochrome when dimmed to 0 is a major UI change. for my part, i'm not sure i agree that it's so major a change. plus, i'm not sure the feature was well implemented in the first place. (i.e., why no mono mode with the backlight on?) 2) the replacement color/mono control is completely undiscoverable. i guess i'd have to agree with this. there should probably be a UI control for the toggle as well, but i'm not sure it's an important enough feature to warrant frame real estate, for example. please discuss. i realize it's hard to talk about this in the abstract, since most of you don't have 1.75 machines to play with. if you do have one, please try it when os12 comes out. Not sure if I have gleaned all of what is desired here, but I will share my experience. I have a Samsung N130, a Lenovo S10-2, and an Adam Notion Ink all with Pixel Qi screens. Turning the backlight off and automatically being in monochrome is a desired feature and matches the usage pattern. Initiating the change to brightness by keystroke, instead of via ambient light, is also a feature. . Letting the transreflective aspect of the screen in mono do it's thing, is also a feature to me. Of course, turning off the backlight is accomplished by using an fn-f2 on one box, an fn-f4, on another and a special feature key on the last; but, who's looking for standards? :-) I also have a another three of all the same devices with their factory standard LCD
Re: [Sugar-devel] automatic backlight control
On 21.11.2011, at 15:22, Paul Fox wrote: it quickly became clear (to me, at least) that it would be confusing if user-dimming behaved differently than auto-backlight-control, with respect to monochrome mode. whether or not it's confusing to the user, it's definitely confusing to the code, since it's difficult to always do the right thing if the user and the sensor are both changing the brightness at the same time. so i disabled the switch to monochrome entirely -- using the brightness keys doesn't change the color/mono setting. IMHO (and not having tried it yet) the current behavior (switching to mono when manually reducing brightness) is fine, and the best compromise we found so far. When you add the auto-turnoff, it should only toggle the backlight, not the mono-color setting. I don't think that would be too confusing, from a user's POV it just means when it's bright outside, the backlight's power gets cut. I can see how it would lead to confusion if you map this desired behavior onto the existing olpc-brightness command. What's needed I think is an additional override independent of the brightness setting that just turns the backlight off. Everything else would stay the same. - Bert - ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: automatic backlight control
Can the keyboard backlight control have an extra step at the end, going trom bright to dim to off/color to off/mono ? Then the auto-backlight would be allowed to bring it down to off/color, and the user could go the extra step to off/mono. (assuming, based on my scant knowledge of the technology, that backlight+mono doesn't make sense here). Alternately, have the system remember when the user manually switches from off/color to off/mono, and use that as the new auto target (i.e. remember both the off user preference (off/color or off/mono) as well as the on user preference (bright..dim)). Think of it (perhaps document it) as switching between indoor and outdoor modes automatically, with the user able to adjust the settings on a per-mode basis. On the older XOs, it could at least remember the color/mono preference for each state, for consistency. Might be amusing to see if the sensor is good enough to at least tell the difference between indoor lighting (i.e. a classroom) vs night reading (i.e. nighttime without any lights) and offer a third remembered setting for that. As for the undiscoverable control, make it a Sugar science activity. Give the user the actual sensor readings, sliders to control the thresholds and hysteresis, etc, and let them play with it. Teaches them about the sensor, the circuitry behind it, the concept of hysteresis, energy conservation (tie in the battery power meter), contrast, and industrial controls. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] automatic backlight control
Just to reinforce a few points which maybe might not be clear to people who haven't played with the new hardware: 1) the switch point is set that *you cannot tell when we turn the backlight off*. Ie, the threshold is so high that by the time we turn it off, you couldn't never have told whether the backlight was on or not. This is very different from the auto dim feature in Macs, for example. (And it's the primary reason why the switch to monochrome was so visible -- you couldn't tell that we were turning the backlight on and off, you could only tell that the images on the display were shifting greyscale values intermittently for no obvious reason.) 2) this is a very important power-saving feature for young kids, who generally aren't savvy enough to manually do all these measures which prolong battery life. So, even if power tweakers might want a little more control, it's important to make the default behavior as power-friendly as possible (especially as we move further into deployments where access to power is a big big deal). We should keep in mind the trade-offs here. --scott -- ( http://cscott.net ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] automatic backlight control
walter wrote: Paul, Unless the display design is different than it was in 2007, then there is no way to decouple turning off the backlight and going into monochrome. Also, turning on the backlight adds color back (although the amount of color vs monochrome in the mix is a function of the backlight vs ambient-light levels. So I am not sure we could implement your proposal with the current hardware. i guess it's changed since 2007 -- at least, it's been this way since 2008. try the following, at any brightness level: while sleep 1 do echo $(( i = ! i )) /sys/devices/platform/dcon/monochrome don =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] automatic backlight control
kevin wrote: Not sure if I have gleaned all of what is desired here, but I will share my experience. I have a Samsung N130, a Lenovo S10-2, and an Adam Notion Ink all with Pixel Qi screens. Turning the backlight off and automatically being in monochrome is a desired feature and matches the usage pattern. Initiating the change to brightness by keystroke, instead of via ambient light, is also a feature. . Letting the transreflective aspect of the screen in mono do it's thing, is also a feature to me. Of course, turning if i read this right, you're saying that you wouldn't want the display to stay colored with the backlight off? what's your reasoning? the screen is transflective whether in mono mode or not. off the backlight is accomplished by using an fn-f2 on one box, an fn-f4, on another and a special feature key on the last; but, who's looking for standards? :-) I also have a another three of all the same devices with their factory standard LCD screent. Brightness down to 0 on a colour LCD screen, or turning the backlight off, (without the transreflective screen in monochrome) gives me unreadable screens in any light conditions. Down to 1 and staying in colour is fine enough, imo. Backlight off direct to mono on the PQ is fine with me too, imo. Again, just from my point of view, auto-dim was one of the most disturbing UI changes to Lion on the Mac, and one which most of our Mac users have elected to defeat. One person's user experience feature can become another's defect. (Tap-to-click anyone? ) So, if there becomes an ambient light control that in turn auto-dims or changes mode handling or the screen, I would like there to be an easily configurable UI to disable that feature. My 2 cents. bear in mind that this really only kicks in when the surrounding light is bright enough that you literally can't tell whether the backlight is on or not. currently there's no way to disable it. that will change, but i'm not sure what form the UI might take. paul Cheers, KG paul [1] http://wiki.laptop.org/go/Display#The_theory =- paul fox, p...@laptop.org ___ Sugar-devel mailing list sugar-de...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] automatic backlight control
bert wrote: On 21.11.2011, at 15:22, Paul Fox wrote: it quickly became clear (to me, at least) that it would be confusing if user-dimming behaved differently than auto-backlight-control, with respect to monochrome mode. whether or not it's confusing to the user, it's definitely confusing to the code, since it's difficult to always do the right thing if the user and the sensor are both changing the brightness at the same time. so i disabled the switch to monochrome entirely -- using the brightness keys doesn't change the color/mono setting. IMHO (and not having tried it yet) the current behavior (switching to mono when manually reducing brightness) is fine, and the best compromise we found so far. have we actually tried anything else? the coupling of monochrome to brightness has been this way forever, as far as i know. honestly, i'm surprised people consider this coupling to be so important. given how subtle the difference between color and mono modes with the backlight off, i really doubt most users would even notice the change. When you add the auto-turnoff, it should only toggle the backlight, not the mono-color setting. I don't think that would be too confusing, from a user's POV it just means when it's bright outside, the backlight's power gets cut. I can see how it would lead to confusion if you map this desired behavior onto the existing olpc-brightness command. What's needed I think is an additional override independent of the brightness setting that just turns the backlight off. Everything else would stay the same. it's not that easy. unless neither brightness mechanism messes with the mono setting, then they need to be coupled somehow. otherwise if the backlight is auto-offed (still color), then the user uses the dim key (no brightness change, but now mono), and then the backlight auto-ons, it will now be in mono. there's perhaps a way around that, but you can see that it gets tricky to cover all cases. do you also object to the new color/mono toggle, via the control key (or via the UI)? please try os12, when available, and see how it feels. paul - Bert - =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: automatic backlight control
[ resending to cc: the lists ] dj wrote: Can the keyboard backlight control have an extra step at the end, going trom bright to dim to off/color to off/mono ? Then the auto-backlight would be allowed to bring it down to off/color, and the user could go the extra step to off/mono. (assuming, based on my scant knowledge of the technology, that backlight+mono doesn't make sense here). perhaps. in practice, i suspect most users simply hold the dim key and let it auto-repeat until the backlight is off. backlight + mono actually does make sense, and has been requested in the past. because there's no color averaging going on, you get the full 1200x900 resolution, instead of something effectively less. so reading an ebook, for instance, you might prefer it. paul Alternately, have the system remember when the user manually switches from off/color to off/mono, and use that as the new auto target (i.e. remember both the off user preference (off/color or off/mono) as well as the on user preference (bright..dim)). Think of it (perhaps document it) as switching between indoor and outdoor modes automatically, with the user able to adjust the settings on a per-mode basis. On the older XOs, it could at least remember the color/mono preference for each state, for consistency. Might be amusing to see if the sensor is good enough to at least tell the difference between indoor lighting (i.e. a classroom) vs night reading (i.e. nighttime without any lights) and offer a third remembered setting for that. As for the undiscoverable control, make it a Sugar science activity. Give the user the actual sensor readings, sliders to control the thresholds and hysteresis, etc, and let them play with it. Teaches them about the sensor, the circuitry behind it, the concept of hysteresis, energy conservation (tie in the battery power meter), contrast, and industrial controls. =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] automatic backlight control
On 21.11.2011, at 18:06, Paul Fox wrote: bert wrote: On 21.11.2011, at 15:22, Paul Fox wrote: it quickly became clear (to me, at least) that it would be confusing if user-dimming behaved differently than auto-backlight-control, with respect to monochrome mode. whether or not it's confusing to the user, it's definitely confusing to the code, since it's difficult to always do the right thing if the user and the sensor are both changing the brightness at the same time. so i disabled the switch to monochrome entirely -- using the brightness keys doesn't change the color/mono setting. IMHO (and not having tried it yet) the current behavior (switching to mono when manually reducing brightness) is fine, and the best compromise we found so far. have we actually tried anything else? the coupling of monochrome to brightness has been this way forever, as far as i know. I remember the command line interface, and some GUI tool with checkboxes. Admittedly that's from before the XO-1 was even mass-produced. But I do remember discussing how the keyboard control should work. honestly, i'm surprised people consider this coupling to be so important. I personally would like to have a way to toggle it on and off all the time, independent of backlight brightness. I'm just saying coupling it to the brightness control is a brilliantly simple way to make it work for users who aren't even aware of the details. given how subtle the difference between color and mono modes with the backlight off, i really doubt most users would even notice the change. To me it's striking how much sharper the image gets all of a sudden. But then I do have a graphics background and am a hobby-typophile. Most users wouldn't consciously notice the change, agreed. But that's not the same as saying it doesn't matter. When you add the auto-turnoff, it should only toggle the backlight, not the mono-color setting. I don't think that would be too confusing, from a user's POV it just means when it's bright outside, the backlight's power gets cut. I can see how it would lead to confusion if you map this desired behavior onto the existing olpc-brightness command. What's needed I think is an additional override independent of the brightness setting that just turns the backlight off. Everything else would stay the same. it's not that easy. unless neither brightness mechanism messes with the mono setting, then they need to be coupled somehow. otherwise if the backlight is auto-offed (still color), then the user uses the dim key (no brightness change, but now mono), and then the backlight auto-ons, it will now be in mono. That's not what I had in mind. Taking your example, the display would not auto-on since the user explicitly set it to off. Auto-off should be completely independent of the user adjusting the brightness. E.g.: Brightness is set to 10. User goes outside, ambient sensor overrides, turning backlight off. User presses brightness-down, level is set to 9. Backlight is still overridden due to ambient light. User goes inside, ambient override stops, backlight comes back on at level 9. See what I mean? The user shouldn't have to care about the ambient light sensor turning off the display. All the controls would still work the same. Just like on older XOs. do you also object to the new color/mono toggle, via the control key (or via the UI)? Not at all. please try os12, when available, and see how it feels. paul Will do. - Bert - ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Re: automatic backlight control [Devel Digest, Vol 69, Issue 47]
What would be the energy waste if auto-dimming was going to 1 instead of 0? This could keep the current setting, user experience and the advantages of monochrome mode. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
VPN Client.conf File
Good Morning All, In installing openvpn I didn’t see a client.conf file. I want my XS to connect to a vpn server. In essence the XS will be the vpn client. I have my vpn keys and in trying to create the client.conf file I received some errors. The issue is that when I created my client.conf file then restarted the openvpn service, it did not start. Iam able to stop it but not start. I had previously gotten a site to look at regarding openvpn configuration however the site is now down. See the below client.conf file I created using a couple web sites. client dev tun proto upd user nobody group nogroup ca /etc/openvpn/keys/*.crt cert /etc/openvpn/keys/*.crt key /etc/openvpn/keys/*.key remote IP_ADDRESS 1194 resolv-retry infinite nobind mute-replay-warnings ___ Not sure where I went wrong. Iam assuming that I missed a couple lines..Not sure where. Regards, Brian ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [OLPC-AU] VPN Client.conf File
Hi Brian: First thing is you have a typo in the .conf file correct the proto line, is should be udp. For further setup information have a look at: http://openvpn.net/index.php/open-source/documentation/howto.html#config Jerry On 21 November 2011 08:20, HALL,Brian C brian.hal...@uwimona.edu.jm wrote: Good Morning All, In installing openvpn I didn’t see a client.conf file. I want my XS to connect to a vpn server. In essence the XS will be the vpn client. I have my vpn keys and in trying to create the client.conf file I received some errors. The issue is that when I created my client.conf file then restarted the openvpn service, it did not start. Iam able to stop it but not start. I had previously gotten a site to look at regarding openvpn configuration however the site is now down. See the below client.conf file I created using a couple web sites. client dev tun proto upd user nobody group nogroup ca /etc/openvpn/keys/*.crt cert /etc/openvpn/keys/*.crt key /etc/openvpn/keys/*.key remote IP_ADDRESS 1194 resolv-retry infinite nobind mute-replay-warnings ___ Not sure where I went wrong. Iam assuming that I missed a couple lines..Not sure where. Regards, Brian ___ OLPC-AU mailing list olpc...@lists.laptop.org http://lists.laptop.org/listinfo/olpc-au ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
automatic backlight control
The shift from colour to monochrome is noticable and would be annoying if it happened a lot, for example as clouds pass, trees and people move. If the hysterisis, the difference between cutin and cutout brightness is large, the change in mode will happen a lot less frequently and not be annoying. I would like to try it switching automatically to monochrome but with large hysterisis. I'll wait to try OS12 Tony ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] automatic backlight control
bert wrote: On 21.11.2011, at 18:06, Paul Fox wrote: bert wrote: When you add the auto-turnoff, it should only toggle the backlight, not the mono-color setting. I don't think that would be too confusing, from a user's POV it just means when it's bright outside, the backlight's power gets cut. I can see how it would lead to confusion if you map this desired behavior onto the existing olpc-brightness command. What's needed I think is an additional override independent of the brightness setting that just turns the backlight off. Everything else would stay the same. it's not that easy. unless neither brightness mechanism messes with the mono setting, then they need to be coupled somehow. otherwise if the backlight is auto-offed (still color), then the user uses the dim key (no brightness change, but now mono), and then the backlight auto-ons, it will now be in mono. That's not what I had in mind. Taking your example, the display would not auto-on since the user explicitly set it to off. Auto-off should be completely independent of the user adjusting the brightness. E.g.: Brightness is set to 10. User goes outside, ambient sensor overrides, turning backlight off. User presses brightness-down, level is set to 9. Backlight is still overridden due to ambient light. User goes inside, ambient override stops, backlight comes back on at level 9. See what I mean? The user shouldn't have to care about the ambient light sensor turning off the display. All the controls would still work the same. Just like on older XOs. yes, i see. but that's not really how i think a brightness control works. the control doesn't adjust a virtual target level of some sort, for use in the future -- it simply adjusts the screen brightness. let me reword: Brightness is set to 10. User goes outside, ambient sensor turns backlight off. User presses brightness-down, level *doesn't change, because it's already 0*. User goes inside, ambient override stops, backlight comes back on at level 10. how does a switch to monochrome (and back to color) fit into that? i think the only easy thing to do is what a couple of people have suggested: add an extra step to the manual control, such that if the level is 0, and it's adjusted down, it switches to monochrome. on any upward adjustment it switches to color. auto-turnoff would take it to the 0-but-still-color level, and also always turn on color when adjusting upward. there's still an issue integrating with a mono only mode, since both the manual and automatic controls would need to honor that. and if any other entity (e.g., sugar) wants to join in the fun, they'll have to honor that mode too. paul do you also object to the new color/mono toggle, via the control key (or via the UI)? Not at all. please try os12, when available, and see how it feels. paul Will do. - Bert - ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] automatic backlight control
On Mon, Nov 21, 2011 at 9:22 AM, Paul Fox p...@laptop.org wrote: i've already had some guarded negative feedback on both of these new behaviors, so i'm looking for more of that, as well as positive feedback to balance it out. :-) Hi folks -- I was one of the early commenters on this. And Paul gave me a, ahem, strong recommendation. All caps. Neon lights, blinking: TRY IT OUT ON AN XO-1.75 None of what Paul says seems to make sense until you try it out on an XO-1.75. Outdoors, in the sun. You can yum update now, or you can get os12 in a couple hours. You can mimic it on earlier hw -- take it to the bright sunlight. Dim it to the lowest backlight. Now hit the 'dimmer' key for greyscale. hth, m -- martin.langh...@gmail.com mar...@laptop.org -- Software Architect - OLPC - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: automatic backlight control
Hi, On Mon, Nov 21 2011, Martin Langhoff wrote: Hi folks -- I was one of the early commenters on this. And Paul gave me a, ahem, strong recommendation. All caps. Neon lights, blinking: TRY IT OUT ON AN XO-1.75 And when *pgf* types in all caps, you *know* it's serious. -- Chris Ball c...@laptop.org http://printf.net/ One Laptop Per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: automatic backlight control
fors...@ozonline.com.au wrote: The shift from colour to monochrome is noticable and would be annoying if it happened a lot, for example as clouds pass, trees and people move. If the hysterisis, the difference between cutin and cutout brightness is large, the change in mode will happen a lot less frequently and not be annoying. I would like to try it switching automatically to monochrome but with large hysterisis. I'll wait to try OS12 you may be in a better position to play with this, geographically speaking, than i am -- we're running low on sunlight these days. the hysteresis is currently hard-coded in powerd -- you'll find it in the function ambient_adjust_init(). it only gets set once, though, so after powerd starts, you can change the limits directly and they should take effect immediately. additionally, to cause auto-monochrome to happen, uncomment the obvious lines at the end of set_brightness() and brightness_ramp(). paul Tony ___ 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: automatic backlight control
On Mon, Nov 21, 2011 at 4:16 PM, Chris Ball c...@laptop.org wrote: And when *pgf* types in all caps, you *know* it's serious. :-) -- actually, he didn't go that far. But I lack his subtlety so I went for it guns ablazing. m -- martin.langh...@gmail.com mar...@laptop.org -- Software Architect - OLPC - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] automatic backlight control
i wrote: please try os12, when available, and see how it feels. i'm afraid the necessary firmware didn't make the deadline for os12, so you'll need to either wait for os13, or q4c05 firmware, whichever comes first. paul =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Announcing Q4C05
http://wiki.laptop.org/go/OLPC_Firmware_q4c05 This is a maintenance release for the C1 build, focusing on support for Linux suspend/resume testing, but also including: - new EC firmware which shortens the duration of the LED blinks for the light sensor, - fixes for save-mfg-data and restore-mfg-data, - enable keyboard interrupt using del key on mechanical keyboards, - keep the storage LED lit during fs-update and flash, - show the clock in the banner, - test fast mode access to accelerometer. -- James Cameron http://quozl.linux.org.au/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
11.3.1 build 12 released for XO-1.75
The Saturday night fever build, where audio seems to work at last, clocks make sense again, and we have some power mgmt improvements. Download from: http://build.laptop.org/11.3.1/os12/ Bugs fixed: #11353 SD Card cannot detected in OS881 #11436 XO-1.75 runin battery discharge characterisation #11400 Date resets to 1970 each boot #11397 DCON freeze not working under X Audio related fixes -- please help us test! #11411 Audio recorded on 1.75 may switch channels or not play when output #11421 Simple alsa pcm example only plays back on one channel #11288 XO-1.75 accelerometer chip change #11296 mmap to snd-mmp2-pcm fails #11366 XO-1.75 C1 os24 runin 0.15.3p audio underrun overrun messages excessive #11454 [APP issue] Etoy app:Play SelfMode and eToy will hang-up at the first time but start again normally. . #11193 XO-1.75: Scratch Etoys freeze when playing audio Progress on: #11395 Implement Linux Suspend/Resume on MMP2 #11406 and #11412 - kernel powerd wakeup events queue work #11465 Proposed activities updates to 11.3.1: rolled back TamTam* and Measure Kernel changelog: Andres Salomon (2): Revert add config option to allow disabling of console switch during suspend pxa168: disable VT switching when entering suspend Chris Ball (7): pxa sdhci: introduce PXA_FLAG_CARD_PERMANENT for eMMC and internal SD, use it for XO-1.75 mmc: pxa: Allow specifying caps in MMC cap syntax directly mmc: pxa: Allow specifying pm_flags in MMC syntax directly olpc-xo-1-75.c: Specify non-removable MMC in .caps as well as flags mmc: pxa: Remove unnecessary use of pxa flags, replaced by caps mmc: pxa: Add 8-bit cap directly, remove unnecessary pxa flag olpc-xo-1-75.c: Add MMC PM flags for libertas staying up over suspend Jonathan Corbet (2): ASOC mmp2-pcm: Limit period size to half the buffer size sound: do not let the start threshold exceed the buffer size (dlo#11193) Martin Langhoff (3): xo_175_defconfig: disable MMC_UNSAFE_RESUME Revert pm - put wireless chip to sleep when suspending (#2) xo-1.75 defconfig: use rtc1 for HCTOSYS at boottime (dlo#11400) Paul Fox (3): remove the ifdefed support for EC-connected keyboards add config option to allow disabling of console switch during suspend fix off-by-one error which kept d-pad-left key from causing wakeup Saadia Baloch (2): alc5631.c: Go back to a selected number of playback rates. alc5631.c: Minimum playback channels value is 2. Sven Neumann (1): cfg80211: really ignore the regulatory request --- os11/xo1.75/os11.packages.txt 2011-11-15 18:21:03.0 -0500 +++ os12/xo1.75/os12.packages.txt 2011-11-21 18:10:40.0 -0500 -kernel-3.0.0_xo1.75-2014.1639.olpc.184b135.armv7l +kernel-3.0.0_xo1.75-2018.1738.olpc.e3f6aac.armv7l -olpc-powerd-38-1.fc14.armv5tel -olpc-powerd-dbus-38-1.fc14.armv5tel -olpc-runin-tests-0.16.0-1.armv7l +olpc-powerd-39-1.fc14.armv5tel +olpc-powerd-dbus-39-1.fc14.armv5tel +olpc-runin-tests-0.16.1-1.armv7l -olpc-utils-1.3.7-1.fc14.armv5tel +olpc-utils-1.3.8-1.fc14.armv5tel --- os11/xo1.75/os11.activities.txt 2011-11-15 18:21:03.0 -0500 +++ os12/xo1.75/os12.activities.txt 2011-11-21 18:10:40.0 -0500 -Measure-34.1 +Measure-34 -TamTamEdit-60.1 -TamTamJam-60.1 -TamTamMini-60.1 +TamTamEdit-60 +TamTamJam-60 +TamTamMini-60 cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- Software Architect - OLPC - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
[Server-devel] VPN Client.conf File
Good Morning All, In installing openvpn I didn’t see a client.conf file. I want my XS to connect to a vpn server. In essence the XS will be the vpn client. I have my vpn keys and in trying to create the client.conf file I received some errors. The issue is that when I created my client.conf file then restarted the openvpn service, it did not start. Iam able to stop it but not start. I had previously gotten a site to look at regarding openvpn configuration however the site is now down. See the below client.conf file I created using a couple web sites. client dev tun proto upd user nobody group nogroup ca /etc/openvpn/keys/*.crt cert /etc/openvpn/keys/*.crt key /etc/openvpn/keys/*.key remote IP_ADDRESS 1194 resolv-retry infinite nobind mute-replay-warnings ___ Not sure where I went wrong. Iam assuming that I missed a couple lines..Not sure where. Regards, Brian ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
