Re: [Sugar-devel] automatic backlight control
On Thu, Nov 24, 2011 at 10:09 AM, Paul Fox p...@laptop.org wrote: - hitting brightness down one more time when at level 0 will switch to mono. users that use auto-repeat to get there probably won't see a difference. ... - sunlight-driven auto-turnoff will go all the way to 0, but won't invoke mono mode. Great! Does it stick? Or will the auto-brighten aspect of auto-dimming kick in when a cloud comes over? 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
martin wrote: On Thu, Nov 24, 2011 at 10:09 AM, Paul Fox p...@laptop.org wrote: - hitting brightness down one more time when at level 0 will switch to mono. users that use auto-repeat to get there probably won't see a difference. as discussed on this thread on friday (i think), this part is no longer right. there will be no extra step to get to mono mode. i.e., the behavior of the keyboard controls will be unchanged. ... - sunlight-driven auto-turnoff will go all the way to 0, but won't invoke mono mode. this is (still) correct. Great! Does it stick? Or will the auto-brighten aspect of auto-dimming kick in when a cloud comes over? it doesn't stick currently. if you dim (to any level) before auto-dimming happens (i.e., while you're still inside), then auto-dim/auto-brighten will take you back to the previous level that you set manually. but if you manually dim while auto-dim is already in effect, your manual change (which only caused a color -- mono switch, since the backlight was already off) will be lost -- you'll be back in color mode. but since the backlight is now on, this is the correct behavior. now, you could argue that it should go back to mono on the next auto-dim, since that's what the user wanted last time, but that argument would require patches to both powerd and olpc-brightness to give it any teeth. (it's complications like this which led me to try and simplify the whole mechanism in the first place.) so, currently, to get mono mode every time auto-dim happens, you have to use ctrl-brightness-down to force mono mode always. paul 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 =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] automatic backlight control
Today is a sunny day in cold Germany, unlike in the first half of the week. So I took the 1.75 outside. IMHO the auto-off is fine as implemented in os12. Not distracting at all. Someone suggested turning it back on quicker, I tried that (replaced brightness_ramp with set_brightness), but that was much less nice. As I said previously I like the new mono toggle using the brightness keys with ctrl. But I also like the switch to mono when turning the brightness down manually. Much more convenient (and way more discoverable) than having to remember the ctrl-modifier. So I added those two lines back just as they were before, and it works fine. I would find it a foolish consistency to drop this just because automatic switch-off doesn't do it. - Bert - ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] automatic backlight control
bert wrote: Today is a sunny day in cold Germany, unlike in the first half of the week. So I took the 1.75 outside. IMHO the auto-off is fine as implemented in os12. Not distracting at all. Someone suggested turning it back on quicker, I tried that (replaced brightness_ramp with set_brightness), but that was much less nice. As I said previously I like the new mono toggle using the brightness keys with ctrl. But I also like the switch to mono when turning the brightness down manually. Much more convenient (and way more discoverable) than having to remember the ctrl-modifier. So I added those two lines back just as they were before, and it works fine. I would find it a foolish consistency to drop this just because automatic switch-off doesn't do it. okay, sold. i did have a very brief chance to play with the laptop in the sun two days ago, and after trying more varied types of content, i better appreciate the value of mono mode. it's sunny here today, so i hope to get to play with it some more myself. i've implemented what a couple of people suggested for brightness key behavior: - reducing brightness manually to level 0 remains colored (unlike past releases, where level 0 also implied mono). - hitting brightness down one more time when at level 0 will switch to mono. users that use auto-repeat to get there probably won't see a difference. - alt-brightness-down goes to level-0 in mono mode, as it always did. i think it's a coin-toss whether it should go to level-0 in mono or level-0 in color. (thoughts?) - brightness up from level 0 (whether from the color or mono version of level 0) will always go to level 1, and restore color. - sunlight-driven auto-turnoff will go all the way to 0, but won't invoke mono mode. bert, i think you approved of the idea of this scheme on irc, please let me know if you still think so. paul - 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
Hi Paul, On 24 Nov 2011, at 15:09, Paul Fox wrote: bert wrote: Today is a sunny day in cold Germany, unlike in the first half of the week. So I took the 1.75 outside. IMHO the auto-off is fine as implemented in os12. Not distracting at all. Someone suggested turning it back on quicker, I tried that (replaced brightness_ramp with set_brightness), but that was much less nice. As I said previously I like the new mono toggle using the brightness keys with ctrl. But I also like the switch to mono when turning the brightness down manually. Much more convenient (and way more discoverable) than having to remember the ctrl-modifier. So I added those two lines back just as they were before, and it works fine. I would find it a foolish consistency to drop this just because automatic switch-off doesn't do it. okay, sold. i did have a very brief chance to play with the laptop in the sun two days ago, and after trying more varied types of content, i better appreciate the value of mono mode. it's sunny here today, so i hope to get to play with it some more myself. i've implemented what a couple of people suggested for brightness key behavior: I've been trying to keep up with the thread, but just wanted to ask, why would anyone not want to auto switch to mono mode when setting the back light brightness to 0? Mono mode is just so much sharper and clear! For me switching the backlight off in direct sunlight is almost never to do with saving power, I'm after the sharp, crisp, clear, high contrast display. --Gary - reducing brightness manually to level 0 remains colored (unlike past releases, where level 0 also implied mono). - hitting brightness down one more time when at level 0 will switch to mono. users that use auto-repeat to get there probably won't see a difference. - alt-brightness-down goes to level-0 in mono mode, as it always did. i think it's a coin-toss whether it should go to level-0 in mono or level-0 in color. (thoughts?) - brightness up from level 0 (whether from the color or mono version of level 0) will always go to level 1, and restore color. - sunlight-driven auto-turnoff will go all the way to 0, but won't invoke mono mode. bert, i think you approved of the idea of this scheme on irc, please let me know if you still think so. paul - Bert - ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel =- paul fox, p...@laptop.org ___ 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: [Sugar-devel] automatic backlight control
On 24.11.2011, at 16:09, Paul Fox wrote: bert wrote: Today is a sunny day in cold Germany, unlike in the first half of the week. So I took the 1.75 outside. IMHO the auto-off is fine as implemented in os12. Not distracting at all. Someone suggested turning it back on quicker, I tried that (replaced brightness_ramp with set_brightness), but that was much less nice. As I said previously I like the new mono toggle using the brightness keys with ctrl. But I also like the switch to mono when turning the brightness down manually. Much more convenient (and way more discoverable) than having to remember the ctrl-modifier. So I added those two lines back just as they were before, and it works fine. I would find it a foolish consistency to drop this just because automatic switch-off doesn't do it. okay, sold. i did have a very brief chance to play with the laptop in the sun two days ago, and after trying more varied types of content, i better appreciate the value of mono mode. it's sunny here today, so i hope to get to play with it some more myself. i've implemented what a couple of people suggested for brightness key behavior: (haven't seen that yet in your git repo) - reducing brightness manually to level 0 remains colored (unlike past releases, where level 0 also implied mono). - hitting brightness down one more time when at level 0 will switch to mono. users that use auto-repeat to get there probably won't see a difference. Not needed, see below. - alt-brightness-down goes to level-0 in mono mode, as it always did. i think it's a coin-toss whether it should go to level-0 in mono or level-0 in color. (thoughts?) Mono. - brightness up from level 0 (whether from the color or mono version of level 0) will always go to level 1, and restore color. - sunlight-driven auto-turnoff will go all the way to 0, but won't invoke mono mode. bert, i think you approved of the idea of this scheme on irc, please let me know if you still think so. paul I now think having two zero-brightness settings (crisp / blurred) does not make sense for general usage. +1 to what Gary wrote in his followup. For those who want to play with that we have ctrl-brightness-down/up to toggle blurryness ;) So I would rather not add that extra step below 0. - Bert - ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] automatic backlight control
bert wrote: On 24.11.2011, at 16:09, Paul Fox wrote: bert wrote: Today is a sunny day in cold Germany, unlike in the first half of the week. So I took the 1.75 outside. IMHO the auto-off is fine as implemented in os12. Not distracting at all. Someone suggested turning it back on quicker, I tried that (replaced brightness_ramp with set_brightness), but that was much less nice. As I said previously I like the new mono toggle using the brightness keys with ctrl. But I also like the switch to mono when turning the brightness down manually. Much more convenient (and way more discoverable) than having to remember the ctrl-modifier. So I added those two lines back just as they were before, and it works fine. I would find it a foolish consistency to drop this just because automatic switch-off doesn't do it. okay, sold. i did have a very brief chance to play with the laptop in the sun two days ago, and after trying more varied types of content, i better appreciate the value of mono mode. it's sunny here today, so i hope to get to play with it some more myself. i've implemented what a couple of people suggested for brightness key behavior: (haven't seen that yet in your git repo) not pushed yet. - reducing brightness manually to level 0 remains colored (unlike past releases, where level 0 also implied mono). - hitting brightness down one more time when at level 0 will switch to mono. users that use auto-repeat to get there probably won't see a difference. Not needed, see below. - alt-brightness-down goes to level-0 in mono mode, as it always did. i think it's a coin-toss whether it should go to level-0 in mono or level-0 in color. (thoughts?) Mono. good. - brightness up from level 0 (whether from the color or mono version of level 0) will always go to level 1, and restore color. - sunlight-driven auto-turnoff will go all the way to 0, but won't invoke mono mode. bert, i think you approved of the idea of this scheme on irc, please let me know if you still think so. paul I now think having two zero-brightness settings (crisp / blurred) does not make sense for general usage. +1 to what Gary wrote in his followup. For those who want to play with that we have ctrl-brightness-down/up to toggle blurryness ;) So I would rather not add that extra step below 0. okay, i'm fine with that -- i was on the fence. but i think you and gary are saying two slightly different things. you're saying that the manual keypresses shouldn't have an intermediate level 0 in color step. gary's saying that auto-turnoff should go to level 0 in mono. i'm happy to agree with you. i don't think i'm ready to agree with gary. reason for not agreeing with gary: the switch from color to mono and back is very noticeable when you're in bright sunlight. the auto-turnoff should be designed to be as transparent to the user as possible. there will be times when the auto-turnoff won't do quite the right thing -- perhaps your hands are shading the sensor momentarily, or perhaps your laptop was sleeping when you came outside, and the auto-turnoff won't take effect until your first keystroke wakes it up. in those cases i think the auto-turnoff should stay in color mode. paul - 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
I too will test this weekend. Silly q: should I test both sugar and gnome, or just sugar? KG On Thu, Nov 24, 2011 at 11:23 AM, Paul Fox p...@laptop.org wrote: bert wrote: On 24.11.2011, at 16:09, Paul Fox wrote: bert wrote: Today is a sunny day in cold Germany, unlike in the first half of the week. So I took the 1.75 outside. IMHO the auto-off is fine as implemented in os12. Not distracting at all. Someone suggested turning it back on quicker, I tried that (replaced brightness_ramp with set_brightness), but that was much less nice. As I said previously I like the new mono toggle using the brightness keys with ctrl. But I also like the switch to mono when turning the brightness down manually. Much more convenient (and way more discoverable) than having to remember the ctrl-modifier. So I added those two lines back just as they were before, and it works fine. I would find it a foolish consistency to drop this just because automatic switch-off doesn't do it. okay, sold. i did have a very brief chance to play with the laptop in the sun two days ago, and after trying more varied types of content, i better appreciate the value of mono mode. it's sunny here today, so i hope to get to play with it some more myself. i've implemented what a couple of people suggested for brightness key behavior: (haven't seen that yet in your git repo) not pushed yet. - reducing brightness manually to level 0 remains colored (unlike past releases, where level 0 also implied mono). - hitting brightness down one more time when at level 0 will switch to mono. users that use auto-repeat to get there probably won't see a difference. Not needed, see below. - alt-brightness-down goes to level-0 in mono mode, as it always did. i think it's a coin-toss whether it should go to level-0 in mono or level-0 in color. (thoughts?) Mono. good. - brightness up from level 0 (whether from the color or mono version of level 0) will always go to level 1, and restore color. - sunlight-driven auto-turnoff will go all the way to 0, but won't invoke mono mode. bert, i think you approved of the idea of this scheme on irc, please let me know if you still think so. paul I now think having two zero-brightness settings (crisp / blurred) does not make sense for general usage. +1 to what Gary wrote in his followup. For those who want to play with that we have ctrl-brightness-down/up to toggle blurryness ;) So I would rather not add that extra step below 0. okay, i'm fine with that -- i was on the fence. but i think you and gary are saying two slightly different things. you're saying that the manual keypresses shouldn't have an intermediate level 0 in color step. gary's saying that auto-turnoff should go to level 0 in mono. i'm happy to agree with you. i don't think i'm ready to agree with gary. reason for not agreeing with gary: the switch from color to mono and back is very noticeable when you're in bright sunlight. the auto-turnoff should be designed to be as transparent to the user as possible. there will be times when the auto-turnoff won't do quite the right thing -- perhaps your hands are shading the sensor momentarily, or perhaps your laptop was sleeping when you came outside, and the auto-turnoff won't take effect until your first keystroke wakes it up. in those cases i think the auto-turnoff should stay in color mode. paul - 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 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] automatic backlight control
kevin wrote: I too will test this weekend. Silly q: should I test both sugar and gnome, or just sugar? by all means, try both. it should work on VT console screens, too. paul =- 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 24.11.2011, at 17:23, Paul Fox wrote: bert wrote: So I would rather not add that extra step below 0. okay, i'm fine with that -- i was on the fence. but i think you and gary are saying two slightly different things. you're saying that the manual keypresses shouldn't have an intermediate level 0 in color step. gary's saying that auto-turnoff should go to level 0 in mono. i'm happy to agree with you. i don't think i'm ready to agree with gary. reason for not agreeing with gary: the switch from color to mono and back is very noticeable when you're in bright sunlight. the auto-turnoff should be designed to be as transparent to the user as possible. there will be times when the auto-turnoff won't do quite the right thing -- perhaps your hands are shading the sensor momentarily, or perhaps your laptop was sleeping when you came outside, and the auto-turnoff won't take effect until your first keystroke wakes it up. in those cases i think the auto-turnoff should stay in color mode. paul I agree with you, but I thought Gary was referring to the brightness keys, too. I interpreted his message as automatically switch to mono when the user sets brightness to 0, which is not what is in os12 right now, but will be reinstated as per this discussion. - Bert - ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] automatic backlight control
bert wrote: On 24.11.2011, at 17:23, Paul Fox wrote: bert wrote: So I would rather not add that extra step below 0. okay, i'm fine with that -- i was on the fence. but i think you and gary are saying two slightly different things. you're saying that the manual keypresses shouldn't have an intermediate level 0 in color step. gary's saying that auto-turnoff should go to level 0 in mono. i'm happy to agree with you. i don't think i'm ready to agree with gary. reason for not agreeing with gary: the switch from color to mono and back is very noticeable when you're in bright sunlight. the auto-turnoff should be designed to be as transparent to the user as possible. there will be times when the auto-turnoff won't do quite the right thing -- perhaps your hands are shading the sensor momentarily, or perhaps your laptop was sleeping when you came outside, and the auto-turnoff won't take effect until your first keystroke wakes it up. in those cases i think the auto-turnoff should stay in color mode. paul I agree with you, but I thought Gary was referring to the brightness keys, too. I interpreted his message as automatically switch to mono when the user sets brightness to 0, which is not what is in os12 right now, but will be reinstated as per this discussion. re-reading for Nth time, i see i might have misunderstood -- sorry gary! sounds like we're all agreed. thanks! paul =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] automatic backlight control
fors...@ozonline.com.au wrote: Thanks Paul thanks for testing! The logic appears to be buggy, see #11487: XO-1.75 OS12 backlight is off when you come back inside okay, more testing is needed. as you noted, it's quite hard to tell when it's on and off. i'll see if i can come up with an indicator, on the display or on the LEDs, which will help during debug. As it stands, neither the monochrome nor colour modes are OK in full sunlight. The colour mode causes a significant loss of resolution for reading small black text and even more resolution loss with coloured text. to clarify -- neither of these issues is caused by the auto-turnoff, but they might suggest that one or the other modes is a better target in full sun -- is that what you're saying? where can i find some colored text on the laptop? With the monochrome mode, the shadow of your hands as you type is enough to switch mode which is quite distracting the color/mono selection shouldn't have affect on how much light causes the mode switch. The cutin cutout settings are 50 (bright)and 80 (dark). It does not seem worth raising the 80 figure because there is still visible colour information at 70. The 50 figure could be lowered, direct sunlight is 5-10, so I tried 15, this still could give mode switching from your hands' shadow in direct sunlight. how can you tell the switch has occurred, if you're in full sunlight? i honestly can't tell when it's happened. What I suggest is that the backlight not switch off unless you have been in the sun for (eg) 5 minutes, but switch back on immediately in the dark. I don't have the coding skills or I would have tried it out. For anybody who wants to try it powerd is at /usr/sbin/power the brightness settings are at line1853 monochrome is commented out at lines 1764 1793 uncommenting these lines reenables monochrome in response to the sensor but surprisingly not the control keys i don't follow -- the code in powerd currently has (or should have) no effect on how the brightness keys work. they're handled by olpc-brightness. so they should continue doing what they were doing before you modified those lines to reenable zero brightness gives mono behavior. paul Tony 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 ___ Sugar-devel mailing list sugar-de...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel _ This mail has been virus scanned by Australia On Line see http://www.australiaonline.net.au/mailscanning =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Re: [Sugar-devel] automatic backlight control
fors...@ozonline.com.au wrote: Thanks Paul thanks for testing! The logic appears to be buggy, see #11487: XO-1.75 OS12 backlight is off when you come back inside okay, more testing is needed. as you noted, it's quite hard to tell when it's on and off. i'll see if i can come up with an indicator, on the display or on the LEDs, which will help during debug. Its not too hard to write a TurtleArt program which continuously prints the brightness sensor and the screen brightness, there is a block for the brightness sensor and sample python code 'sensor.py' for the screen bightness As it stands, neither the monochrome nor colour modes are OK in full sunlight. The colour mode causes a significant loss of resolution for reading small black text and even more resolution loss with coloured text. to clarify -- neither of these issues is caused by the auto-turnoff, but they might suggest that one or the other modes is a better target in full sun -- is that what you're saying? The loss of resolution in full sunlight results from disabling the monochrome mode, disabled for both manual and automatic triggering in OS12 where can i find some colored text on the laptop? I am not sure what you are asking, links in webpages is one example, you can create coloured text in Write With the monochrome mode, the shadow of your hands as you type is enough to switch mode which is quite distracting the color/mono selection shouldn't have affect on how much light causes the mode switch. no it doesn't, what are you saying? The cutin cutout settings are 50 (bright)and 80 (dark). It does not seem worth raising the 80 figure because there is still visible colour information at 70. The 50 figure could be lowered, direct sunlight is 5-10, so I tried 15, this still could give mode switching from your hands' shadow in direct sunlight. how can you tell the switch has occurred, if you're in full sunlight? i honestly can't tell when it's happened. I am running a Turtleart program to interrogate the sensor and screen brightness What I suggest is that the backlight not switch off unless you have been in the sun for (eg) 5 minutes, but switch back on immediately in the dark. I don't have the coding skills or I would have tried it out. For anybody who wants to try it powerd is at /usr/sbin/power the brightness settings are at line1853 monochrome is commented out at lines 1764 1793 uncommenting these lines reenables monochrome in response to the sensor but surprisingly not the control keys i don't follow -- the code in powerd currently has (or should have) no effect on how the brightness keys work. they're handled by olpc-brightness. so they should continue doing what they were doing before you modified those lines to reenable zero brightness gives mono behavior. The brightness keys no longer give monochrome at zero brightness. You must have coded that somewhere in powerd? Line 1793 looked like it was going to be the culprit. paul Tony 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 ___ Sugar-devel mailing list sugar-de...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel _ This mail has been virus scanned by Australia On Line see http://www.australiaonline.net.au/mailscanning =- paul fox, p...@laptop.org ___ Sugar-devel mailing list sugar-de...@lists.sugarlabs.org
Re: [Sugar-devel] automatic backlight control
fors...@ozonline.com.au wrote: fors...@ozonline.com.au wrote: Thanks Paul thanks for testing! The logic appears to be buggy, see #11487: XO-1.75 OS12 backlight is off when you come back inside okay, more testing is needed. as you noted, it's quite hard to tell when it's on and off. i'll see if i can come up with an indicator, on the display or on the LEDs, which will help during debug. Its not too hard to write a TurtleArt program which continuously prints the brightness sensor and the screen brightness, there is a block for the brightness sensor and sample python code 'sensor.py' for the screen bightness oh, of course. thx. As it stands, neither the monochrome nor colour modes are OK in full sunlight. The colour mode causes a significant loss of resolution for reading small black text and even more resolution loss with coloured text. to clarify -- neither of these issues is caused by the auto-turnoff, but they might suggest that one or the other modes is a better target in full sun -- is that what you're saying? The loss of resolution in full sunlight results from disabling the monochrome mode, disabled for both manual and automatic triggering in OS12 you were complaining about the visuals for both mono and color mode, and i was just verifying that you didn't think those visuals were powerd's fault. it's in a different mode now (color), but you don't seem to think monochrome mode would be any better. this is what's confusing me. where can i find some colored text on the laptop? I am not sure what you are asking, links in webpages is one example, you can create coloured text in Write With the monochrome mode, the shadow of your hands as you type is enough to switch mode which is quite distracting the color/mono selection shouldn't have affect on how much light causes the mode switch. no it doesn't, what are you saying? why did you say with the monochrome mode, ...? The cutin cutout settings are 50 (bright)and 80 (dark). It does not seem worth raising the 80 figure because there is still visible colour information at 70. The 50 figure could be lowered, direct sunlight is 5-10, so I tried 15, this still could give mode switching from your hands' shadow in direct sunlight. how can you tell the switch has occurred, if you're in full sunlight? i honestly can't tell when it's happened. I am running a Turtleart program to interrogate the sensor and screen brightness What I suggest is that the backlight not switch off unless you have been in the sun for (eg) 5 minutes, but switch back on immediately in the dark. I don't have the coding skills or I would have tried it out. For anybody who wants to try it powerd is at /usr/sbin/power the brightness settings are at line1853 monochrome is commented out at lines 1764 1793 uncommenting these lines reenables monochrome in response to the sensor but surprisingly not the control keys i don't follow -- the code in powerd currently has (or should have) no effect on how the brightness keys work. they're handled by olpc-brightness. so they should continue doing what they were doing before you modified those lines to reenable zero brightness gives mono behavior. The brightness keys no longer give monochrome at zero brightness. You must have coded that somewhere in powerd? Line 1793 looked like it was going to be the culprit. no, i coded it in /usr/bin/olpc-brightness. the code in powerd is there for suspend dimming, and now, auto-backlight turnoff. thanks, paul =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] automatic backlight control
2011/11/21 Paul Fox p...@laptop.org: 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. I think a UI for color-monochrome should be done, integrated in the Display Device feature: wiki.sugarlabs.org/go/Features/Display_Device -- .. manuq .. ___ 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 4:15 PM, Martin Langhoff martin.langh...@gmail.com 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 Do it with the 11.3.1/os13 I announced earlier. It has a new OFW (let it update itself ~ 2 reboots, one for OFW, one for EC update...). 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
Re: Re: [Sugar-devel] automatic backlight control
Thanks Paul The logic appears to be buggy, see #11487: XO-1.75 OS12 backlight is off when you come back inside As it stands, neither the monochrome nor colour modes are OK in full sunlight. The colour mode causes a significant loss of resolution for reading small black text and even more resolution loss with coloured text. With the monochrome mode, the shadow of your hands as you type is enough to switch mode which is quite distracting The cutin cutout settings are 50 (bright)and 80 (dark). It does not seem worth raising the 80 figure because there is still visible colour information at 70. The 50 figure could be lowered, direct sunlight is 5-10, so I tried 15, this still could give mode switching from your hands' shadow in direct sunlight. What I suggest is that the backlight not switch off unless you have been in the sun for (eg) 5 minutes, but switch back on immediately in the dark. I don't have the coding skills or I would have tried it out. For anybody who wants to try it powerd is at /usr/sbin/power the brightness settings are at line1853 monochrome is commented out at lines 1764 1793 uncommenting these lines reenables monochrome in response to the sensor but surprisingly not the control keys Tony 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 ___ Sugar-devel mailing list sugar-de...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel _ This mail has been virus scanned by Australia On Line see http://www.australiaonline.net.au/mailscanning ___ 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: [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: [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: [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: [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
