Review Request 109792: Update 'dim display' algorithm.
Thomas Lübking
thomas.luebking at gmail.com
Fri Apr 12 21:04:18 BST 2013
My 3¢
(I assume this is about the "dim after n minutes" feature, i only remotely tracked the thread)
The config UI says "dim" not "alter brightness", so the behavior should simply be to lower the brightness to n% of the present value ("n" being little enough to spot the difference but not enough to turn it off) - and never brighten up.
If one wants to reach a certain brightness (because the weather alters between sun and clouds like every 5 minutes or you move indoors etc.), one should use a slider plasmoid or whatever - the "dim" feature is certainly not meant for such case (personally i use i as "time to judder the mouse" hint ;-)
=>
- using a static value for dimming (even precompiled from the brightnes base config) is wrong. It's even wronger when it can turn off the screen (since neither is what the GUI suggests)
- demanding the ability to set a specific ratio or value is also wrong, since that does really not seem the idea of the feature.
=>
as loong as a fix can ensure that the screen "significantly" darkens but does not turn off, i don't think any more config key is required.
If this can *not* be guaranteed because HW vendors use any kind of unpredictable shit values for the brightness range (like "-100 being least and -1 being max") the dimming factor needs to be configurable and that needs to be exposed to the GUI ("fix ya hw") - otherwise it's pointless, resp. hinting that the problem does not exist in reality.
The GUI could then come with a checkbox and be disabled by default.
Cheers,
Thomas
Sorry for TP, it's not directly related to Danny's particular mail.
On Donnerstag, 11. April 2013 17:59:03 CEST, Danny Baumann wrote:
> Hi,
>
> >> Having said that, my current plan is the following:
>>> - Drop the UI option
>>> - However, leave the configurability via kconfig intact. That
>>> way, users who
>>> are not happy with the defaults do at least have a remote chance of
>>> changing it without recompiling KDE (after they found it's
>>> configurable, of
>>> course - but there's a huge step between looking something up
>>> and compiling
>>> a whole DE to change it) - Additionally add a dimRelative
>>> kconfig setting.
>>> With dimRelative=true, dimRatio is interpreted as a factor
>>> (dimmedBrightness = origBrightness * dimRatio), with it being false it's
>>> interpreted as an absolute value (dimmedBrightness = 100f * dimRatio). -
>>> The defaults are set up as dimRatio = 0.05, dimRelative = false
>>> - Do the dimming in 2 steps, the first one being done after
>>> the configured
>>> time, the second one 10 seconds later
>>>
>>> Is that approach ok?
>>
>> Nope, even a config key just adds maintainability and support burden. I've
>> been there, done that, and didn't like the ride.
>>
>> The bug you are addressing is entirely fixable without an option, there is
>> simply not a good reason to make this configurable.
>
> So you say whoever is not happy with the proposed defaults
> (e.g. me) is suppposed to either recompile KDE or use another
> DE? My patch is _not_ addressing a bug only (although that
> ultimately was the trigger), but aims at improving the algorithm
> in the process.
>
> (In case you're wondering, I'd like to make it dim to 30% of
> the original brightness to make it work seamlessly in the
> evening where the non-dimmed brightness is lower. I understand
> this may not be deemed a suitable default behaviour.)
>
> Regards,
>
> Danny
>
>
More information about the kde-core-devel
mailing list