Bug 523533 - screen dims to ~60% or so on login
Summary: screen dims to ~60% or so on login
Keywords:
Status: CLOSED DUPLICATE of bug 475850
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: hal
Version: 5.3
Hardware: All
OS: Linux
low
medium
Target Milestone: rc
: ---
Assignee: David Zeuthen
QA Contact: desktop-bugs@redhat.com
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-09-15 20:52 UTC by Ray Strode [halfline]
Modified: 2013-03-06 03:59 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-09-16 15:06:00 UTC


Attachments (Terms of Use)
log from running g-p-m manually (5.31 KB, text/plain)
2009-09-15 20:54 UTC, Ray Strode [halfline]
no flags Details

Description Ray Strode [halfline] 2009-09-15 20:52:50 UTC
When gnome-power-manager starts on RHEL 5.3 (gnome-power-manager-2.16.0-10.el5) on Paul Cormier's X300 laptop, the internal display's brightness dims considerably.  Pressing the brightness key shows that he on-screen display thinks that the brightness is 100%.

cat /proc/ibm/brightness says:

level: 7
commands: up, down
commands: level <level> (<level> is 0-15)

running

echo "level 15" > /proc/ibm/brightness

makes the screen bright again (until hitting one of the laptop brightness controls).

The g-p-m log has:

[gpm_hal_device_get_bool] gpm-hal.c:572 (16:28:11):	 No property laptop_panel.brightness_in_hardware on device with id /org/freedesktop/Hal/devices/acpi_brightness
[gpm_brightness_init] gpm-brightness.c:207 (16:28:11):	 Starting: (11 of 7)
...
*** WARNING ***
[gpm_brightness_set_hw] gpm-brightness.c:297 (16:28:11):	 set outside range (11 of 7)
*** WARNING ***
[gpm_brightness_set_hw] gpm-brightness.c:297 (16:28:11):	 set outside range (10 of 7)
*** WARNING ***
[gpm_brightness_set_hw] gpm-brightness.c:297 (16:28:11):	 set outside range (9 of 7)
*** WARNING ***
[gpm_brightness_set_hw] gpm-brightness.c:297 (16:28:11):	 set outside range (8 of 7)
[gpm_brightness_set_hw] gpm-brightness.c:301 (16:28:11):	 Setting 7 of 7


So it seems like g-p-m may be hardcoding an upper bound of 7 since /org/freedesktop/Hal/devices/acpi_brightness isn't set?  Or maybe the kernel is misreporting the upperbound somewhere else?

I'm not sure if the fix here is in gnome-power-manager, kernel, or a need for a new hal quirk.

Comment 1 Ray Strode [halfline] 2009-09-15 20:54:48 UTC
Created attachment 361140 [details]
log from running g-p-m manually

Comment 2 Ray Strode [halfline] 2009-09-16 14:46:34 UTC
Looking at g-p-m, it seems to get the number of brightness levels from the hal keylaptop_panel.num_levels

Looking at the hal source code I see this:

       acpi_type = hal_device_property_get_int (d, "linux.acpi_type");
       hal_device_property_set_string (d, "info.category", "laptop_panel");
       if (acpi_type == ACPI_TYPE_TOSHIBA_DISPLAY) {
               type = "toshiba";
               desc = "Toshiba LCD Panel";
               br_levels = 8;
[...]
       } else if (acpi_type == ACPI_TYPE_IBM_DISPLAY) {
               type = "ibm";
               desc = "IBM LCD Panel";

               /* some older laptops have 8 states, some newer ones 16, but
                * if we can't find the correct value use 8, as this was the
                * previous hardcoded default */
               br_levels = get_ibm_brightness_levels ("/proc/acpi/ibm/brightness");
               if (br_levels == 0)
                       br_levels = 8;

[...]
       } else if (acpi_type == ACPI_TYPE_SONY_DISPLAY) {
               type = "sony";
               desc = "Sony LCD Panel";
               br_levels = 8;
       } else if (acpi_type == ACPI_TYPE_OMNIBOOK_DISPLAY) {
               type = "omnibook";
               desc = "Omnibook LCD Panel";
               br_levels = 8;
       }
[...]
       /*
        * We can set laptop_panel.num_levels as it will not change, and allows us
        * to work out the percentage in the scripts.
        */
       hal_device_property_set_int (d, "laptop_panel.num_levels", br_levels);

if br_levels ends up being 8, then this problem would happen, I think.

A couple possibilities:

1) acpi_type is not ACPI_TYPE_IBM_DISPLAY for some reason?
2) acpi_type is ACPI_TYPE_IBM_DISPLAY but get_ibm_brightness_levels ("/proc/acpi/ibm/brightness") is failing and returning 0? Maybe the output of /proc/acpi/ibm/brightness changed between kernel versions?

Comment 3 Richard Hughes 2009-09-16 14:59:29 UTC
(In reply to comment #2)
> 1) acpi_type is not ACPI_TYPE_IBM_DISPLAY for some reason?

We would need the output of lshal to tell that.

> 2) acpi_type is ACPI_TYPE_IBM_DISPLAY but get_ibm_brightness_levels
> ("/proc/acpi/ibm/brightness") is failing and returning 0? Maybe the output of
> /proc/acpi/ibm/brightness changed between kernel versions?  

Hmm, in your first comment you mentioned /proc/ibm/brightness, but in the hal patch we're referring to /proc/acpi/ibm/brightness. Are you sure it's really the former?

If that's the case, then the location of the proc file must have changed from 0.5.3 to 0.5.4. Could you just confirm it's not a typo pls.

Comment 4 Matthew Garrett 2009-09-16 14:59:52 UTC
Do we have the level checking code in the 5.4 hal? Older versions just assume 8 all the time. In any case, it looks like this is a dupe of #513461 in hal.

Comment 5 Ray Strode [halfline] 2009-09-16 15:06:00 UTC
ah that's the problem, then. he's running 5.3.   closing...

*** This bug has been marked as a duplicate of bug 513461 ***

Comment 6 Richard Hughes 2009-09-16 15:18:36 UTC
(In reply to comment #4)
> Do we have the level checking code in the 5.4 hal?

Yes, since build 50.

Comment 7 Ray Strode [halfline] 2009-09-16 15:28:30 UTC
Changing which bug this is dupped against to bug 475850 for clarity

*** This bug has been marked as a duplicate of bug 475850 ***


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