Update 'dim display' algorithm.
Review Request #109792 - Created March 29, 2013 and discarded
This change does two things: - No longer dim display before the dim time set by the user elapses. This fixes bug #304696 - No longer assume that 0% display brightness produces a visible result. This doesn't work with the intel-backlight backlight interface (as it turns off the backlight at 0% brightness). According to the kernel developers (see  and ), this isn't a safe assumption to make for other backlight interfaces either. Instead of always dimming to 0%, make the amount of dimming configurable.  http://lists.freedesktop.org/archives/intel-gfx/2013-March/026152.html  http://lists.freedesktop.org/archives/intel-gfx/2013-March/026140.html
To be honest I don't like adding yet another configuration option by default, a configuration option that apparently is needed only in some systems. There is no other alternative than this?
Resolving bug #304696 is good, in my eyes. I'd like affirmation from Dario though. A couple of questions: - Can you say a few words why you decided to drop the multi-stage dimming and go straight to the final brightness? - What do you think should be done about migrating existing profiles, if anything? This change benefits users who are confused by powerdevil's behaviour, but may worsen things for users who have got wise to this quirk and set the dim display idle time to twice their desired value. I don't know what the relative populations of these two groups are. * Upgrading profiles in powerdevilprofilegenerator.cpp and halving the stored idle time means no change in dimming time for any user and makes the config UI accord with powerdevil's behaviour. Users in the first group will now be able to see that the idle time is set to a surprisingly low value and change it. * leaving the profile as is means dimming behaviour suddenly rights itself for users in the first group and changes unexpectedly for users in the second group. If the new effective dimming time is longer than certain other timeouts, such as screen power saving or system suspend, this means that the display will never dim.
Just a note that I think that dimming to an absolute brightness is indeed the right approach. I can't speak to the original intent of the code, but I think the relative dimming on the way from the original brightness to zero is just to ensure good intermediate values during the transition to the final brightness. Now the the final brightness is non-zero we need to make sure we never brighten, of course. But this is taken care of. If we were to re-introduce a multi-stage dimming we should again pick an appropriate point between the original brightness and the final brightness.