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.
Created attachment 361140 [details] log from running g-p-m manually
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?
(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.
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.
ah that's the problem, then. he's running 5.3. closing... *** This bug has been marked as a duplicate of bug 513461 ***
(In reply to comment #4) > Do we have the level checking code in the 5.4 hal? Yes, since build 50.
Changing which bug this is dupped against to bug 475850 for clarity *** This bug has been marked as a duplicate of bug 475850 ***