[UPSTREAM] Move backlight handling out of pcf50633 driver
sean at mcneil.com
Sun Oct 19 23:16:09 CEST 2008
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...
Again, you comment with absolutely no examples or proof of breakage:
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.
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.
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.
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.
Looking forward to a more concrete discussion of the issue...
Mike (mwester) wrote:
> Sean McNeil wrote:
>> Hi Mike,
>> Once again you get totally pissed off without explanation.
> I explained it -- what do you not understand about ABI compatability?
> You are proposing to break existing software. That's not cause for concern?
>> As stated by
>> Andy, most software stacks use the sysfs value to get the
>> max_brightness. Tell us what breaks?
> No - if YOU want to change this, then YOU tell us why it WON'T break.
> Right now YOU represent ONLY YOUR user-space apps -- that's not adequate.
> And no, the fact is that the requirement to use max_brightness is NOT
> well known, or well documented -- and not all the distros use it.
> Should they? That's a different question.
> Just because you have excellent control over YOUR user space does not
> entitle you or Om to make this sort of change with ONLY your input!
> Other existing distros, ESPECIALLY the ones that actually out in common
> use (!) should also be considered.
>> If it is new code, why not check
> Yes, ****NEW*** code should do this. But hey! News flash! There is
> EXISTING code for these devices, and it doesn't do that!!! It's
> unfortunate that I seem to be the only one advocating for that community...
> (OOPS! But then since this ABI change was ONLY posted to the kernel
> list, I guess maybe it isn't so surprising there are no objections...
> Hmmm.... could there be a process problem here?)
>> 0-63 for brightness? Come on, anyone hard-coding for
>> this is guaranteed not to be portable to other platforms - even GTA03
>> possibly. 0-255, however, has been in many kernels, for many years and
>> has been thought to be a safe assumption.
> Come on, ABI changes are ABI changes and it matters not how stupid or
> irrational the original ABI might have been. The reasonableness of the
> value is not the point, and you know it.
> (although why not 63? It makes as much sense to the typical developer
> as any of the other numerous values passed into APIs of all sorts.)
>> So, explain yourself and stop ranting
> No. I might as well ask you to stop advocating your distro/company. We
> both have an interest in this, and my voice is no less important than
> yours. (I don't know who you are -- perhaps you represent one of the
> major Linux distros with a almost-ready-for-market project that will
> propel the vision of Openmoko forward? In that case, I happily defer to
> you. But right now, you are just an individual lobbying for your
> personal position, just as I am.)
>> What will break?
> Sorry, that's NOT how ABI's work. YOU tell me what will work, and how it
> will be remediated, and preferably have the distro managers for the
> affected software chime in to support the ABI breakage with a plan. In
> this, doing that should be trivial. But for some reason, even in
> trivial cases like this, NOBODY in Om "Kernel-land" seems to see fit to
> even consider the user apps! (You aside, Sean -- you are doing an
> excellent job in representing your distro/company's needs, and the other
> Om distros should use your active involvement as an example.)
>> I wanted a
>> #define so I could build a kernel for any desired max. Andy thinks we
>> should just go with what is a de-facto standard. Either is OK with me.
> Then we don't have an issue, do we? Seems that if someone doesn't like
> the #define (defaulting to the current value), then they should explain
> why it should be changed. Like I said, this should be trivial --
> there's only 8 (or maybe 9 since I heard of another new one this week)
> distros for the devices, and a few wiki pages -- if someone REALLY wants
> to change the ABI, it shouldn't be so hard to do it the right way with a
> quick RFC sent to the appropriate distro mailing lists, etc.
> I would think that with the new focus Om is claiming, that changes such
> as this that provide no functionality improvements would be WAY down the
> priority list, especially when implementing the change might have the
> impact of negatively affecting ANY user space stuff.
> We've now invested more time and energy in discussing this than it was
> I can't see any reason that justifies changing the existing ABI.
> Mike (mwester)
More information about the openmoko-kernel