backlight device, suspend/resume... [RANT]
mwester at dls.net
Wed Jul 9 02:38:59 CEST 2008
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.
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!
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!
More information about the openmoko-kernel