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!
Regards,
Mike (mwester)
