backlight device, suspend/resume... [RANT]
sean at mcneil.com
Wed Jul 9 02:57:10 CEST 2008
Mike (mwester) wrote:
> Sean McNeil wrote:
>> This is an area I have a strong opinion about...
> As do I.
>> IMHO, OLPC is doing the right thing here as an application. The kernel
>> provides functionality and does things at a very low level. You do not
>> want it to be providing any utilitarian functionality.
> Theoretically, I agree.
>> I would disagree
>> that there is compromise necessary. Sure, one can have debug code that
>> turns on the display coming out of sleep, but a release should do the
>> right thing and leave the display in exactly the same condition it was
>> in when it entered suspend.
> Ok, but you *DO* agree that there is a compromise necessary. I'm asking
> for nothing more than *EXACTLY* what you are suggesting here -- while
> this kernel and this hardware is in its current state, we need to make a
> compromise on these principles of purity, etc. and do the right thing
> for the user. That's all I'm asking for!
>> This is the same reasoning I don't want any of the LEDs to be doing
>> utilitarian things like being changed when external power is
>> applied/removed - the kernel is not an application. I would be surprised
>> if application capabilities such as these manage to make it upstream
>> into the main kernel tree.
> !!! Upstream??!!!!! (Ok, I went outside and screamed. I feel better
> now.) Now a general rant on this myopic focus on upstream, aimed at
> nobody in particular, and the entire OM development team specifically:
> Users care that it works, and care nothing for things like elegance of
> algorithm, or ability to push upstream. As such there will be constant
> friction; development for the sake of elegance and purity is a thing of
> beauty, a wonderful art-form. But it's been my experience that users
> seldom pay for "art" and "purity" and "elegance" if the device fails to
> deliver, reliably, on its primary purpose. People pay for results, not
> elegance, especially when they can't see the elegance and beauty of the
> code when it's in binary form in flash anyway.
> So, the OM thinking on this issue and on so many we've discussed in the
> past is that code should always be Pure, and Elegant, and it should
> always do what is "The Right Thing To Do(tm)" -- in this case, not turn
> on the backlight in the kernel. Agreed - at least I do agree that's the
> elegant thing to do. And also agreed is that to do otherwise will cause
> the code not go upstream.
> But to continue to pick on this single example we are discussing now, do
> any of you appreciate what sort of response you'll get from the user who
> has a non-responsive device with a blank screen in their hand? Will you
> explain to him that the code leaving the screen dark is not only
> deliberate, it is considered a thing of beauty, a bit of elegance in
> programming, and then will you inquire if the user is delighted to know
> that this code that left his display dark and his device undiagnosable,
> that bit of code was accepted upstream and will be part of the Linux
> kernel in the future? Hurray! I'm quite certain the user of that
> defunct device will be absolutely delighted to hear about that; this
> knowledge cannot fail to soothe any frustrations the user may have over
> the complete inability to determine what failed and the true state of
> the device with the dark display in his hand.
You are talking totally different things here. A user shouldn't get
his/her hands on things until suspend/resume has been ironed out and is
working properly. They shouldn't be getting things in this state. Only
developers should. Alternatively, does it make sense for a user to have
a device where the screen is constantly blinking on as it is doing now?
My application does the following:
Turn off the display.
Go into sleep waiting for an event (like from the GSM).
Handle the event.
If it was just something like the signal strength, go back to sleep.
In this case, you certainly do not want the resume to have turned on the
display for you. That is a no no. You want it off the whole time. Only
the application layer can determine if it is appropriate to turn it back
on. In fact, I'm not really OK with it being turned on for debug
either. As a developer, I can certainly determine if the unit has
crashed by some other means than to look at the display. I'm not really
sure what scenario this help to have it on. So we can say "well the
kernel is still working"? That doesn't have to be the case. The kernel
can crash with the screen on or off. How is this more diagnosible?
> I'm reminded of Douglas Adam's bit (somewhere in the "Hitchhiker's Guide
> to the Galaxy" trilogy) about the spaceship with the black indicators on
> the black instrument panel lighting up black -- I'm sure he would find
> it deliciously ironic that here we are, actually implementing that!
We are not asking to leave the screen off. We are saying the application
layer is suppose to control it. If you sleep with display on, wakes up
on. Sleep with display off, wake with display off. If you think it is
important to always wake up with display on, then always suspend with it
turned on. Doesn't that work for you?
> Ok, enough said. The community will maintain a patch to make sure that
> we can read the display when the thing crashes. Once the device
> ultimately makes it to the point where it becomes commonplace for the
> GTA02 to operate for 21 days as a normal cell phone without crashing or
> failing to come out of resume, then we can remove the patch to keep the
> backlight on, and ultimately elegance will win the day -- at least
> elegance will win the day once the device first delivers on the promise
> of being somewhat reliable. :-)
> Carry on, and code elegantly!
> Mike (mwester)
More information about the openmoko-kernel