Bug 173382 - g-p-m seems to default to lowest LCD brightness for AC power
g-p-m seems to default to lowest LCD brightness for AC power
Status: CLOSED UPSTREAM
Product: Fedora
Classification: Fedora
Component: gnome-power-manager (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: John (J5) Palmieri
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-11-16 14:55 EST by Bill Nottingham
Modified: 2014-03-16 22:56 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-11-17 16:10:42 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Patch against CVS (1.37 KB, patch)
2005-11-17 15:54 EST, Richard Hughes
no flags Details | Diff

  None (edit)
Description Bill Nottingham 2005-11-16 14:55:25 EST
Description of problem:

SSIA. I've certainly never configured it otherwise, and it seems somewhat odd -
AC should default to highest brightness.

Version-Release number of selected component (if applicable):

gnome-power-manager-0.2.8-1

There are other issues with this interface as it's implemented:

- it's done as a gradual fade
- the BIOS *already* handles this on my laptop, so you have two different
  entities changing it

The combination of this means that when you unplug the AC, you get:

- immediate shift downwards about 50%
- a half second later, a fade even more

Not sure how you'd fix it, but it looks odd.
Comment 1 Richard Hughes 2005-11-16 19:11:08 EST
Have you tried 0.3.0? The spec file was improved in early in 0.3.0 development
to actually install the schema (rather than install it, and then immediatly
uninstall it...) -- that should fix the default values.
About the gradual fade -- what laptop make and model do you have (IBM thinkpad?)
because I can blacklist these based on the smbios properties -- that's easy to do.
Comment 2 Bill Nottingham 2005-11-17 12:03:55 EST
0.3.0 hasn't been packaged up yet.

Yes, this is a thinkpad. I'm assuming you're using /proc/acpi/ibm/brightness.
Looking at that file, I see it supports:

$ cat brightness
level:          7
commands:       up, down
commands:       level <level> (<level> is 0-7)

The fade would imply that you're using up/down instead of just 'level X' - is
that the case?
Comment 3 Richard Hughes 2005-11-17 12:23:10 EST
No, I'm actually fading up and down by setting the level to a new value after I
think 150ms steps. This makes non-fading laptops fade quite nicely, and it's
much better than a suddern brightness change. I can blacklist thinkpads from the
gradual change algorithm, so worry not.
Comment 4 Richard Hughes 2005-11-17 15:54:07 EST
Created attachment 121202 [details]
Patch against CVS

This should fix the double dim problem -- I'm pretty sure it should patch
against 0.2.8.1 as I don't think the source has changed. Please could you test,
and if okay I'll commit into HEAD.
Comment 5 Bill Nottingham 2005-11-17 16:10:42 EST
Seems to work for me. Closing as UPSTREAM, we'll get it then.

Note You need to log in before you can comment on or make changes to this bug.