RFE: "Dim display when computer has been inactive for x minutes"

[Aaron Whitehouse]

It would be great if gpm had an option to dim the monitor to its lowest brightness setting after a certain time. This would allow the user to, for example, dim the brightness right down after 1 min of inactivity before turning the display off completely after 10.

I was playing with an Apple laptop and was really impressed by the feature as it provides a good compromise for people who are not actually using the machine but like to see what it going on. I often leave my machine to downloading and installing updates, for example, but like to see the progress when I walk into the room or look up from what I am reading.

From a more empirical viewpoint, I have been watching in my lectures this week and have noticed that all the people that have their monitor blank completely or have a screensaver come on move something to get their display back. Those on the Apple machines that dim left them dimmed until they started typing again.

Given that the blanking after a certain amount of time already works, and dimming is already supported, I don't see that this feature would be hard to implement.

[Zack Cerza (zcerza-deactivatedaccount)]

I second this. I also advocate shamelessly copying the sexy fade effect they get by stepping down the dim levels sequentially. Mmm. :)

[Aaron Whitehouse (aaron-whitehouse)]

See: Bug #43572

[Aaron Whitehouse (aaron-whitehouse)]

Apparently this feature has been added.

[Richard Hughes (richard-hughes)]

Yes, upstream works great - see the screenshots here : http://www.hughsie.com/applications/Coppermine/thumbnails.php?album=9 for how much power this saves.

[Andrew Conkling (andrewski)]

Thanks for the screenshots; that looks awesome. Are you running this on Ubuntu? This has said "Fix Committed" for two weeks, and that's the longest package gestation I've seen on any bug I've tracked. Am I missing something?

[Aaron Whitehouse (aaron-whitehouse)]

"Fix Committed" means that the fix has been committed to a CVS, Subversion or an upstream release. "Fix Released" means that it has been made available in the Ubuntu repositories.

Because Ubuntu freezes and does not allow extra features after a certain point, Dapper will stick with the 2.14.x Gnome Power Manager and will not get these features until it upgrades to the latest GPM in Dapper+1.

[Andrew Conkling (andrewski)]

> "Fix Committed" means that the fix has been committed to a CVS,
> Subversion or an upstream release. "Fix Released" means that it has been
> made available in the Ubuntu repositories.

Hmm, wouldn't that have gone on an upstream package/product? I thought that for "g-p-m (Ubuntu)", "Fix Committed" meant that the fix was committed to Ubuntu. Have I misunderstood?

> Because Ubuntu freezes and does not allow extra features after a certain
> point, Dapper will stick with the 2.14.x Gnome Power Manager and will
> not get these features until it upgrades to the latest GPM in Dapper+1.

True, but there are exceptions left and right to this rule; we've seen lots of updates to g-p-m, let alone other programs. Would it be possible for this one to be backported before release? The changes look quite optimal.

[Aaron Whitehouse (aaron-whitehouse)]

From: https://wiki.ubuntu.com/Bugs/CommonTasks

Fix Committed:
 * Means for upstream projects, that the fix is in CVS/SVN/bzr or commited to some place
 * Means for package maintainers, that the changes are pending and to be uploaded soon (it's what PENDINGUPLOAD was in Bugzilla)

Fix Released:
 * Means for upstream projects, that a release tarball was announced and is publically available
 * Means for package maintainers, that a fix was uploaded
          o Please don't be hesitant to add a changelog as a comment, so people know what to look out for

So it looks like I am wrong. Sorry about that. I changed the status to reflect that it was done, but not yet available in the repository. It is difficult because there is no real upstream bug here as this bug was filed after the changes had been made. If you can think of something that better conveys the situation, feel free to make the change.

As to the exceptions, I don't really see it as overly likely a week before release but you can try :).

[Sebastien Bacher (seb128)]

if I understand comments correctly it should be fixed to edgy. Feel free to reopen if that's the case

[Andrew Conkling (andrewski)]

Well, the current screenshots (http://www.gnome.org/projects/gnome-power-manager/gpp.html) don't match my available options, but I get the impression that that could be because those options are detected from available interfaces?

Assuming the software is there, how do we enable this specific option, and/or how should we report bugs on this? Per-model?

[Aaron Whitehouse (aaron-whitehouse)]

Andrew: I also do not have this working, but it is because of my laptop. If you follow the link to the Gnome bug on the right, you will see that some laptops do not identify themselves as supporting brightness changes. It also steps through finding that out.

For my laptop (a Dell), it doesn't use ACPI to do brightness stuff and instead does it in BIOS. This means that HAL is going to have to write a module to talk to my brightness controls in the BIOS. On other laptops, I understand that the issue would be ACPI not working correctly - it will depend on the laptop.

If I were you, I would go through the steps on the linked bug report and file a support request so that someone can help you isolate it down to a bug/feature request.

As I say, I don't have a laptop that this works on, so that is why I haven't been able to change its status. If this is working for someone in Edgy, that is great news :).

[Aaron Whitehouse (aaron-whitehouse)]

The other bug in this report, Bug #43572 , may be useful to you, Andrew.