Comment 11 for bug 1437510

@ken-vandine
> If we don't want to set dim-timeout separately, and remain relative to activity-timeout,
> we should drop the setting completely and ubuntu-system-compositor should dim the
> screen on activity-timeout - 10
@ogra
> this is still not properly fixed, can we eventually get a fix inside u-s-c please ...

USC was designed to offer a setInactivityTimeouts(poweroff, dim) interface for maximum flexibility, and also so that it could provide only mechanism, not enforce policy. We believe USC shouldn't hardcode policy like "dim timeout is 10 seconds before power-off timeout". Perhaps there needs to be a central place to handle power management policy, but USC shouldn't be it.

This debate is yet another effect of this bug: https://bugs.launchpad.net/unity-system-compositor/+bug/1444042.

> a) if you dont switch the time (i.e. before the OTA with the fix you have set your lock timeout to 10min)
> it will use 50sec hardocded after OTA

I don't understand this statement, which probably means I missing some background info here...

> b) if you set your device to "never" where you likely want to use the GPS while driving, the dim value
> defaults to 50sec which most likely can even risk your life while tapping madly on teh screen to see where
> you are going with your GPS ...

From a quick look at the requests that USC receives when changing the lock timeout from the UI, this seems to be an effect of the code that sets the timeouts in ubuntu-system-settings. In particular, when selecting "Never" in the UI, USC receives (-1 means don't change):

set_inactivity_timeouts(0, -1) // set power-off timeout to 0s (disable)
set_inactivity_timeouts(-1, 50) // set dim timeout to 50s

i.e.. we get an explicit request to set the dim timeout to 50 seconds, whereas we should get a request to disable it (set it to 0).