[UPSTREAM] Move backlight handling out of pcf50633 driver
mwester at dls.net
Sun Oct 19 23:57:41 CEST 2008
Sean McNeil wrote:
> I know the tone here sounds a little harsh. I really am not trying to
> sound that way, but it kind of inherits the tone from previous email.
> So, please excuse me for saying this, but...
No excuses necessary, clear and concise communication is important, and
people who lack thick skins don't seem to hang about Linux very long.
> Again, you comment with absolutely no examples or proof of breakage:
Nor do you. So the issue could be the question of who has the burden of
In this case, to be completely blunt about it, my heartburn is way out
of proportion to the technical issue. The fact is that what has me so
concerned here is the process problem involved in making (yet another)
ABI change (however trivial or even arguably-correct that change might
be) without involving those who use the ABIs. So is the process your
problem? No, of course not, it's an Om problem -- which is why this
conversation is happening on-list, and not privately!
> 1) You didn't explain anything. There is no ABI that specifies
> brightness control shall be 0-63. This is why max_brightness was
> invented. In fact, the only thing I've seen in the wiki site is
> which states there is a sysfs entry to get max_brightness. I'd be
> interested in knowing where it says brightness shall be 0-63.
Neither is there an ABI that says 100, or 255 -- therefore it's not
appropriate to change it just because to a kernel developer 63 is a
silly number. As for the max value -- it's been on the mailing list.
> 2) Your contribution to this discussion is counter productive until you
> can give a reason (any REAL reason not related to this false sense of an
> ABI) not to make the change. In this case, we will use the #define
> approach and leave it at 0x3f for compatibility. I doubt that anyone
> relies on it, though, save perhaps you.
Burden of proof issue. Are you really suggesting that anyone can propose
any change at all, and that it's up to everyone else to respond with
researched answers as to why NOT to do it?
That's not any process I'm familiar with -- in my experience the person
proposing the change provides information on the impact, and preferably
proactively consults with the affected parties to get their feedback.
(Of course that's overkill for this simple problem -- but that doesn't
mean that the process doesn't apply.)
But, as you observe below, it is neither you nor I that determine this -
that's Om. So we're both probably wasting electrons arguing any of this.
> 3) Neither you or I are the voice of the community. As in any large
> group of people there needs to be compromise. Your stance is
> unacceptable as it limits both growth and the ability to correct what
> might have been poor decisions. Think where Linux would be if they never
> allowed for improvements.
My stance is that any change that would be incompatible with current
shipping application software cannot be unilaterally applied. How is
> 4) OM can do anything they want with the kernel. It is their project.
> They have control over it. If you don't like it then put up your own git
> tree. I've had to compromise on several issues because it is the OM way.
> Sometimes you just don't get your way, other times you do. It helps when
> you are rational and reasonable when discussing the issue.
Yep, Om owns it - and yes, I can put up my own kernel, if I don't like
it. But just look at the user-space area to see what that sort of
philosophy has done. Eight (or perhaps 9) unique flashable distros,
according to recent IRC conversations -- and only two of those are Om's
-- that's fragmentation and isn't good for anyone. So i prefer to pick
the specific issues that I think matter the most, and do battle on
those, rather than arbitrarily forking projects. Forking is an absolute
last resort, and I surely hope that it never comes to that.
Regarding "rational and reasonable" -- frankly it seems your position is
that the burden of proof is on everyone else to react to proposed
user-visible changes. I don't accept that -- the one proposing a change
that will break shipping application code, or change the user experience
in a negative or arbitrary way has some requirement in terms of impact
analysis. In fact, 22 years of experience in dealing with commercial
software as a vendor has taught me that it in some cases even fixing
obvious bugs falls in that category! (And yes, Om has customers -- and
some of them are even trying to use the device as a day-to-day phone,
and as it relates to this proposed change, I rather think that those
paying customers also expect that their favorite applications and tools
will continue to blank the screen after an upgrade. So in your mind,
who owns the burden of ensuring that things continue to work?)
But we've been over this ground before, so I expect we'll just have to
agree to disagree.
> Looking forward to a more concrete discussion of the issue...
What's left to discuss? You've said your part, I've said mine. I'm not
going to go digging through the source code for the numerous distros,
nor review all the wikis and blogs out there, just to figure out what
the impact will be. And neither will you! :-D
It's up to Om to see what they want to do.
More information about the openmoko-kernel