Bug 444686 - xbacklight fails to adjust backlight brightness level
xbacklight fails to adjust backlight brightness level
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: xorg-x11-server (Show other bugs)
9
All Linux
low Severity low
: ---
: ---
Assigned To: Adam Jackson
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-04-29 21:21 EDT by Trustin Lee
Modified: 2008-10-20 17:31 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-10-20 17:31:29 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
My current xorg.conf (1.70 KB, application/octet-stream)
2008-05-03 03:27 EDT, Trustin Lee
no flags Details

  None (edit)
Description Trustin Lee 2008-04-29 21:21:00 EDT
Description of problem:

xbacklight fails to adjust backlight brightness level in Fujitsu Lifebook S6510
laptop.  I am using "intel" driver, and the following is what I get when I run
lspci:

00:00.0 Host bridge: Intel Corporation Mobile PM965/GM965/GL960 Memory
Controller Hub (rev 03)
00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960
Integrated Graphics Controller (rev 03)
00:02.1 Display controller: Intel Corporation Mobile GM965/GL960 Integrated
Graphics Controller (rev 03)

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

1.1-2.fc9

How reproducible:

Always reproducible.

Steps to Reproduce:
1. Run 'xbacklight =10' to set the backlight brightness level to 10%
2. The backlight brightness level doesn't change at all.
3. Run 'xbacklight' to check the current brightness level
4. It prints out '0.000000'
  
Actual results:

The backlight level doesn't change no matter what I do with xbacklight. 

Expected results:

The backlight level should change properly.

Additional info:

This regression appeared after recent xorg update in rawhide.  Therefore, the
problem might lie in xorg intel driver or xorg server itself.
Comment 1 Michel Alexandre Salim 2008-05-03 00:06:42 EDT
That is probably it. None of the backlight control worked for me for a while,
but it works just fine now:

$ xbacklight =20
$ xbacklight
20.000000
$ rpm -q xbacklight xorg-x11-drv-i810
xbacklight-1.1-2.fc9.x86_64
xorg-x11-drv-i810-2.2.1-23.fc9.x86_64

Could you re-verify? I'll close the bug in a week or so barring a confirmation
that the problem is ongoing.
Comment 2 Trustin Lee 2008-05-03 03:26:23 EDT
The problem still exists for me.

[trustin@hermes ~]$ rpm -q xbacklight xorg-x11-drv-i810
xbacklight-1.1-2.fc9.x86_64
xorg-x11-drv-i810-2.2.1-23.fc9.x86_64
[trustin@hermes ~]$ xbacklight
14.285714
[trustin@hermes ~]$ xbacklight =10
[trustin@hermes ~]$ xbacklight
0.000000
Comment 3 Trustin Lee 2008-05-03 03:27:23 EDT
Created attachment 304443 [details]
My current xorg.conf

Let me attach my current xorg.conf which might be helpful.
Comment 4 Trustin Lee 2008-05-03 03:29:58 EDT
And here's my hardware information:
http://www.smolts.org/show?uuid=pub_11284cb4-ab16-44e3-b3cd-5dc9361dfb5d
Comment 5 Trustin Lee 2008-05-03 03:32:03 EDT
Interesting X log messages I get whenever I run xbacklight:

(II) intel(0): I2C device "LVDSDDC_C:ddc2" registered at address 0xA0.
(II) intel(0): I2C device "LVDSDDC_C:ddc2" removed.
Comment 6 Bug Zapper 2008-05-14 06:24:33 EDT
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 7 Trustin Lee 2008-06-20 21:43:00 EDT
It's not a xbacklight bug but a problem with the kernel backlight control.  I 
changed the BACKLIGHT_CONTROL property from 'kernel' to 'native' and it works 
perfectly just like before.  Probably this property should be native by default 
for a certain hardware which is known to have a problem with kernel-level 
backlight level adjustment?  My laptop is the case.

[trustin@hermes ~]$ xrandr --prop
Screen 0: minimum 320 x 200, current 1280 x 800, maximum 2048 x 1536
VGA disconnected (normal left inverted right x axis y axis)
LVDS connected 1280x800+0+0 (normal left inverted right x axis y axis) 0mm x 0mm
	PANEL_FITTING: full
		supported: center       full_aspect  full        
	BACKLIGHT_CONTROL: kernel
		supported: native       legacy       combination  kernel      
	BACKLIGHT: 0 (0x00000000) range:  (0,7)
...
[trustin@hermes ~]$ xrandr --output LVDS --set BACKLIGHT_CONTROL native
[trustin@hermes ~]$ xbacklight 30
Yay!
Comment 8 Trustin Lee 2008-06-20 21:47:05 EDT
In my laptop's case, kernel backlight control has very coarse level range - (0, 
7) while native backlight control has very fine level range - (0,52031).

Shouldn't X server choose the defauly backlight control method as the method 
with the most fine-grained level range? (Perhaps in preference of the following 
order: kernel, native, legacy, combination)
Comment 9 Axel 2008-07-01 10:06:11 EDT
I experience the same problem as reported above with a Panasonic CF-W7, running
a fully updated Fedora 9. 

$ rpm -q xbacklight xorg-x11-drv-i810
xbacklight-1.1-2.fc9.x86_64
xorg-x11-drv-i810-2.2.1-24.fc9.x86_64

The only difference is that with "xbacklight =0" the backlight turns very dimm
(now change for all other values).  The solution proposed in comment 7 fixes the
problem, however, even under "native" control the Fn-F1 and Fn-F2 keys (which
are apparently interpreted by the gnome-power-manager), still show the buggy
behavior (no change in brightness, and then very low brightness at minimum setting).
Comment 10 Trustin Lee 2008-07-01 10:10:20 EDT
This issue also makes me think GNOME Backlight applet also should use XRandR 
instead of accessing kernel resource directly.

Comment 11 Matěj Cepl 2008-07-01 10:37:38 EDT
Thanks for the bug report.  We have reviewed the information you have provided
above, and there is some additional information we require that will be helpful
in our diagnosis of this issue.

Please attach your X server log file (/var/log/Xorg.*.log) to the bug report as
individual uncompressed file attachment using the bugzilla file attachment link
below.

We will review this issue again once you've had a chance to attach this information.

Thanks in advance.
Comment 12 Trustin Lee 2008-07-01 21:34:43 EDT
Axel, could you upload your log?  I had to wipe my Fedora installation recently 
due to some issue.
Comment 13 Matěj Cepl 2008-09-12 15:49:11 EDT
Axel, could you please reply to the previous question? If you won't reply in one month, I will have to close this bug as INSUFFICIENT_DATA. Thank you.
Comment 14 Matěj Cepl 2008-10-20 17:31:29 EDT
Since there are insufficient details provided in this report for us to investigate the issue further, and we have not received feedback to the information we have requested above, we will assume the problem was not reproducible, or has been fixed in one of the updates we have released for the reporter's distribution.

Users who have experienced this problem are encouraged to upgrade to the latest update of their distribution, and if this issue turns out to still be reproducible in the latest update, please reopen this bug with additional information.

Closing as INSUFFICIENT_DATA.

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