[UPSTREAM] Move backlight handling out of pcf50633 driver

[Mike (mwester)]

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
> max_brightness?

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
worth.

I can't see any reason that justifies changing the existing ABI.

Regards,
Mike (mwester)