Description of problem: If I change the brightness with the acpi keys on a t60w, I see 4 levels of brightness but the UI indicates 7 levels of brightness. Version-Release number of selected component (if applicable): gnome-power-manager-2.16.0-9.el5 How reproducible: Everytime Steps to Reproduce: 1.Increase the brightness to the max 2.Decrease the brightness and count the brightness levels until brightness stops changing 3.continue to decrease until the gui shows that it is at the dimmest setting. Actual results: 4 levels observable, 7 levels indicated by gui Expected results: Number brightness levels should match in the gui and observable(actual). Additional info:
# cat /proc/acpi/video/VID/LCD0/brightness levels: 100 30 30 40 50 60 70 80 90 100 current: 100 So I guess the correct number of levels is 7, but I only see 5 (not 4 as I said earlier) levels of brightness. If I step through the levels and then look at /proc/acpi/video/VID/LCD0/brightness, these are the levels: Going up: 30 40 60 80 100 Going down: 100 90 70 50 30
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release.
This request was previously evaluated by Red Hat Product Management for inclusion in the current Red Hat Enterprise Linux release, but Red Hat was unable to resolve it in time. This request will be reviewed for a future Red Hat Enterprise Linux release.
I suspect that this is down to the rounding code used in gnome-power-manager interacting poorly with the ACPI backlight driver's tendancy to export a discontiguous list of brightnesses. This was fixed in 2.6.25.
Created attachment 305394 [details] Patch from 2.6.25 This patch flattens the list of exported ACPI brightness values in order to make it practical for userspace to know which values are valid.
Actually, that's not the issue - we don't have backlight class support in our ACPI video driver. So this is clearly a g-p-m problem.
Won't g-p-m be invoking hal, which will be poking /proc/acpi/ibm/brightness in this case?
Given that HAL is just poking values into /proc/acpi/ibm/brightness in 5.5, I'll reassign to the kernel guys to comment on.
This request was evaluated by Red Hat Product Management for inclusion in Red Hat Enterprise Linux 5.6 and Red Hat does not plan to fix this issue the currently developed update. Contact your manager or support representative in case you need to escalate this bug.
This request was evaluated by Red Hat Product Management for inclusion in Red Hat Enterprise Linux 5.7 and Red Hat does not plan to fix this issue the currently developed update. Contact your manager or support representative in case you need to escalate this bug.
This request was evaluated by Red Hat Product Management for inclusion in Red Hat Enterprise Linux 5.8 and Red Hat does not plan to fix this issue the currently developed update. Contact your manager or support representative in case you need to escalate this bug.
This request was not resolved in time for the current release. Red Hat invites you to ask your support representative to propose this request, if still desired, for consideration in the next release of Red Hat Enterprise Linux.
Given how long this problem has gone unresolved, it's low severity, and the lifecycle stage that RHEL 5 is currently in, the problem reported will not be fixed in RHEL 5. -Lenny.