Bug 959 - Lock screen behaviour is different when Brightness != Switch Off period
: Lock screen behaviour is different when Brightness != Switch Off period
Status: CLOSED FIXED
Product: Settings and Maintenance
Control panel
: 3.0
: All All
: Medium enhancement (vote)
: 3.1
Assigned To: Karoliina T. Salminen
: control-panel-bugs
:
:
:
:
  Show dependency tree
 
Reported: 2007-01-21 08:05 UTC by Neil MacLeod
Modified: 2010-05-27 02:53 UTC (History)
2 users (show)

See Also:


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description Neil MacLeod (reporter) maemo.org 2007-01-21 08:05:19 UTC
In the Display applet, when the Brightness period is equal to the Switch Off
period, the screen will switch off immediately when the user select "Lock touch
screen and keys" and will not respond to touchscreen or keypress events other
than the Power key.

However, when the Brightness period is NOT equal to the Switch Off period (eg. 2
mins and 5 mins respectively) the screen will remain active after the user
selects "Lock touch screen and keys". This leads to reduced battery lifetime as
the N800 responds to touchscreen and key press events while in the users pocket etc.
Comment 1 Neil MacLeod (reporter) maemo.org 2007-01-21 08:05:59 UTC
Forgot to mention this is with firmware 2.2006.51-6.
Comment 2 Paul Klapperich 2007-01-23 22:09:02 UTC
This is a not a bug but a feature request.

I have my times set to 1 min and 2 min respectively. If I choose "Lock screen
and keys" the display immediately dims and turns on in approximately 1 minute,
at which point it's completely off.

2 minutes - 1 minute = 1 minute. For your example, the screen should turn off
completely in 3 minutes. This is quite obviously by design.

I agree with Neil, though, immediate off or perhaps something like Dim for 10
seconds and then off regardless of screen settings seems more appropriate.
Comment 3 Neil MacLeod (reporter) maemo.org 2007-01-23 22:35:59 UTC
Paul - it isn't logical to have entirely different behaviour depending on
seemingly unrelated time intervals, chosen by the user. And it certainly isn't
obvious!

To correct these flaws, the GUI should remove the guesswork and confusion by
implementing an appropriate true/false checkbox to control whether the screen is
disabled immediately once it is locked, or only after the longer of the two
timeouts has expired (in this case, the timer also needs to take into
consideration the shorter of the two timeouts... er yes, obvious really!)

:)
Comment 4 Paul Klapperich 2007-01-23 23:21:12 UTC
(In reply to comment #3)
I strongly discourage adding an additional option checkbox. More options will
just make this feature more confusing.

What's currently confusing is an apparent lack of consistency in the current
design. As I just suggested, it would be better to have 1 operation regardless
of system settings that is consistent and obvious.

To be clearer, I suggest:
1) Lock screen option is chosen
2) Screen dims for set time (perhaps 5-10 seconds)
3) After time expirey, screen is off and locked.

The time in step 2 is a constant and connect be user adjusted through the GUI.

It is nice to have a period where the screen is dimmed such that when tapped the
device tells you how to unlock. This is helpful for new users especially.
However, even 30 seconds is much too long and somewhat ridiculous, and a
configurable option will add more confusion than it's really worth.
Comment 5 Neil MacLeod (reporter) maemo.org 2007-01-24 04:37:25 UTC
See also bug #943 - some us (I believe - might be able to tell if voting [bug
#944] is ever enabled for for N800 bugs!) want a quick way to simulate the 770's
cover on. By "cover-on" I mean "disable wireless, lock and disable the screen so
as to minimise battery usage while the device is no longer in use".

Since the lock function gets us part way there (albeit using the tiny Power
button) some of us may also want to immediately disable all screen activity
immediately - such as when we pop the N800 into a jacket or trouser pocket.
Having the screen remain active for another 5, 10, 15 or whatever seconds is
wasted battery power and pointless - you want this, I don't. So...

Give me a GUI choice to decide how the device behaves, as there are obviously
some users who like the screen illuminating dimly while it's functionality
inactive, while others would rather avoid illuminating the insides of their
pockets. I've got three GCSE's you know, I think I can work it out without
becoming too flumoxed (and can't be any more confusing than the current
situation!) :) j/k
Comment 6 Jake Kunnari 2007-03-14 12:52:22 UTC
Changed to Enhancement and added Quim Gil to cc-field
Comment 7 Neil MacLeod (reporter) maemo.org 2007-03-14 14:15:00 UTC
Hi Jake

I'd beg to differ - this isn't discussing an enhancement, it's discussing a bug.
The screen continually remains active when the "dim" and "off" timeouts are
different, but does not behave in this way when the two timeouts are the same.

What we are asking for is consistency, the current behaviour must be due to a
bug as it makes no sense for it to be by design. The current design wastes
battery power. Please revert to "bug" status - I can't imagine it's a difficult
thing to fix...
Comment 8 Mike Lococo 2007-03-21 15:33:23 UTC
To be clear, the behavior is consistent (though poorly designed).  The display
_always_ "dims" when locked.  It then waits out the rest of the timeout between
"dim" and "off" at which point it turns "off".  When the timeout between "dim"
and "off" is zero, it "dims" and then immediately turns "off".

To my knowledge there isn't anyone who actually wants the "immediate dim,
delayed off" behavior, and a _ton_ of people who want "immediate off" (see Bug
#943).  Therefore, I still classify this as a bug.  It's a design bug, not an
implementation bug, though, and it is consistent (in it's own twisted way).
Comment 9 Neil MacLeod (reporter) maemo.org 2007-03-21 15:42:06 UTC
Thanks for the clear explanation Mike, that helps and I agree with your
conclusion - still a bug. :)
Comment 10 Neil MacLeod (reporter) maemo.org 2007-03-24 13:59:31 UTC
This bug now appears to be FIXED in 3.2007.10-7 - anyone else able to confirm?
Comment 11 Neil MacLeod (reporter) maemo.org 2007-03-25 07:23:57 UTC
Changing status to FIXED. Thanks Nokia :)