From: Thomas Martitz <thomas.martitz_at_fhtw-berlin.de>
Date: Mon, 12 Jan 2009 18:02:30 +0100

Recently, there has been some discussion on IRC regarding the backlight
fading settings.

Some people (including me) think they are suboptimal. Suboptimal as in
overkill for PWM fading, and weird for other types.
Personally, I cannot speak for the former one, but during the discussion
it was pointed out that the current defaults are sufficient and just
fine, providing a decent fading, and don't need further configurability.
The latter have 2 settings, 1 for fading in, 1 for fading out, but
provide only on/off for each. That is due to reusing existing lang
strings of PWM fading.

The proposal is: Remove the PWM settings and use the defaults as
hard-coded (including some code clean up that is).
Plus: Fuse the 2 settings to be only 1, having

• Off
• Fade in only
• Fade out only
• On (/Fade in and out)

as options.

The Fade in/Fade out options could potentially, probably depending on
the language a bit, use the existing strings which are now used for the
settings titles. But that wouldn't solve that the setting needs a new title.

The pro I see is that it will at least slightly decrease binsize, remove
the potential of confusion (this surely depends on how confusing the PWM
and/or SW/beast fading options are) and lead to some code cleanup in
backlight.c and the settings (currently much #ifdef, which can be
reduced a bit), and make targets a bit more consistent.

There's 1 con of this proposal that comes immediately into my mind: The
existing lang strings will be (mostly) invalid, and new ones are needed.
Also, it sort of removes existing functionality (well maybe
functionality, but configurability).

I'd like to get some opinions.
(Is messing up LANGs worth it? Do you even change the default settings
on any backlight fading target? Is binsize decrease and code cleanup
worth removing configurability?)

I personally would answer: Yes. No. In this case, yes.
Received on 2009-01-12