[Kde-hardware-devel] Review Request 109792: Update 'dim display' algorithm.

[Thomas Lübking]

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