Bug 713946

Summary: Backlight control does not work in Fedora 15 on Samsung X360 (worked in F12)
Product: [Fedora] Fedora Reporter: JanS <jan.skowron>
Component: kernelAssignee: Kernel Maintainer List <kernel-maint>
Status: CLOSED INSUFFICIENT_DATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 17CC: gansalmon, itamar, jforbes, jonathan, kernel-maint, madhu.chinakonda
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard: first=2.6.38.8 tested=3.3.4 backlight
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-01-02 13:10:44 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
dmesg
none
/var/log/messages
none
Xorg.0.log
none
lspci -vvnn none

Description JanS 2011-06-16 20:38:03 UTC
Created attachment 505140 [details]
dmesg

There is some regression in this matter. Prevoiusly, on Fedora 12, backlight brightness did not worked out of the box (on Samsung x360), however it started to work perfectly after this simple workaround:
xrandr --output LVDS --set BACKLIGHT_CONTROL legacy

Now, after fresh install of Fedora 15, it stopped working at all, and xrandr workaround issues this error:

# xrandr --output LVDS1 --set BACKLIGHT_CONTROL legacy
X Error of failed request: BadName (named color or font does not exist)
Major opcode of failed request: 149 (RANDR)
Minor opcode of failed request: 11 (RRQueryOutputProperty)
Serial number of failed request: 41
Current serial number in output stream: 41

The command "xrandr --prop | grep BACK" returns only this:
BACKLIGHT: 7 (0x00000007) range: (0,7)

I have tried other solutions found on Bugzilla:

- changing this file: "/sys/devices/virtual/backlight/acpi_video1/brightness" - does not change brightness
- there is no "/proc/acpi/video" directory
- command "xrandr --output LVDS1 --set BACKLIGHT 5" changes the value in "/sys/devices/virtual/backlight/acpi_video1/brightness", but this does not change brightness
- "xbacklight" does not work


The only way I was able to change the backlight brightness was:
setpci -s 00:02.0 F4.B=50


I am sending in attachment all logs I was able to figure out might be needed in this case:
- dmesg
- /var/log/messages
- /var/log/Xorg.0.log
- lspci -vvnn


My System:
Fedora 15 i686
Linux walter 2.6.38.8-32.fc15.i686 #1 SMP Mon Jun 13 20:01:50 UTC 2011 i686 i686 i386 GNU/Linux
lspci | grep VGA
00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07)

Comment 1 JanS 2011-06-16 20:39:47 UTC
Created attachment 505141 [details]
/var/log/messages

Comment 2 JanS 2011-06-16 20:40:14 UTC
Created attachment 505142 [details]
Xorg.0.log

Comment 3 JanS 2011-06-16 20:40:46 UTC
Created attachment 505143 [details]
lspci -vvnn

Comment 4 Josh Boyer 2011-10-21 01:40:24 UTC
The samsung-laptop platform driver was added in the 2.6.39 kernel and seems to
contain support for this model.  Do you still have problems with this in the
2.6.40.x F15 kernel updates?

Comment 5 JanS 2011-11-04 15:31:50 UTC
With new kernels from the 2.6.40 family, my Samsung x360 now reacts to the brightness keys (Fn+Up). However, the result is, that brightness is set to == 100% regardless of what key and how many times I push.

When I go to the Display Settings and use mouse to set brightness on the slider, there is a jerky reactions when marker jumps back and fourth between 100% and the chosen setting, screen is blinking, and finally sets on 100%. 

The only way I can decrease brightness from 100% is by the command like:
 setpci -s 00:02.0 F4.B=40


What debug files I should send to help to investigate this problem?

Comment 6 Josh Boyer 2012-06-06 14:29:37 UTC
Are you still having issues with the 2.6.43/3.3 kernel updates?

Comment 7 JanS 2012-06-07 14:47:27 UTC
Yes, 
I am running 3.3.6-3.fc16.i686 on Fedora 16, and I still have issues with brightness. Now I am using KDE, but previously it was Gnome where I noticed the issues for the first time.
1. whenever I close the lid and screen goes blank, after reopening it has 100% brightness.
2. when I press Brightness Up button (Fn+Up) nothing happens
3. when I press Brightness Down button (Fn+Dn) screen goes to 100% regardless of previous position. Each subsequent hit makes screen blink, but eventually screen brightness stays at 100%.
4. slider called "Screen Brightness" in the settings, or in the tray widget in KDE (the one with the battery), works well, in the way it changes the screen brightness to the desired level.
5. when closed, this slider in the tray looses track of the real screen brightness, and shows 100% when reopened - even when nothing happened to the actual brightness.
6. the slider in the Power Management settings is more stable, but shows wrong position often, since does not update when screen brightness goes wrongly to 100%, in cases described above (closing the lid, or pushing Fn+Dn).
7. Command "setpci -s 00:02.0 F4.B=50" works well, in a sense, it sets the brightness to the desired level, however it does not updates the brightness sliders.

If I should test the behavior on Gnome 3, or sent some debug logs, please let me know.

Comment 8 JanS 2012-06-07 19:59:47 UTC
I have tested the issue today on Fedora 17 Live Desktop i686 with kernel 3.3.4-5.fc17.i686 with Gnome 3 on Samsung X360, when booted from USB Live drive.
It is still not working. I managed to investigate brightness behavior in more detail:

There are 9 stages of brightness (values 0-8) in the file:
  /sys/devices/platform/samsung/backlight/samsung/brightness
(also the value that is in this file is consistent with what is being presented by the GUI and what is displayed on the brightness slider in Settings)

There are also 256 values (from 00 to FF) of the "real screen brightness" which can be seen on the screen and set by:
  setpci -s 00:02.0 F4.B=2b
(where  00:02.0 is: VGA compatible controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07) as given by lspci, Subsystem: Samsung Electronics Co Ltd Device c03e,	Kernel driver in use: i915 )

These two states are often disjoint (what is in the Settings, and what is in reality).


The state of the PCI register can be found by running this command:
  lspci -s 00:02.0 -xxx | tail -2 | awk '{print $6}'


My observations are:

1. Stage number 0 means "true pci brightness" = 02 hex. I have tested all 9 stages that are shown in  /sys/devices/platform/samsung/backlight/samsung/brightness. These are equal to according brightness levels :
0 -> 02
1 -> 0a
2 -> 16
3 -> 33
4 -> 56
5 -> 7c
6 -> a3
7 -> d6
8 -> d6
Note that two last one are equal in true brightness. Which I can confirm by looking at the screen. Note also that the highest achieveble level of brightness in Gnome 3 is much less than 0xff.

2. When I set my brighness to be 50% using slider in "Brightness and Lock" in the Gnome 3 Settings, I got:
> cat /sys/devices/platform/samsung/backlight/samsung/brightness
to return: 4
and my true screen rightness is 0x56.
Than, when I close "Brightness and Lock" window, and reopen, or go back to Settings and go formard to according , then I get no change in the real brightness, but the slider is completely to the right and
> cat /sys/devices/platform/samsung/backlight/samsung/brightness
gives: 8
My true brightness is still 0x56.

3. When I hit Brightness-Up button (Fn+Up) my stage jumps to 8 regardless of the previous position. And my true brightness does not change at all.

4. When I hit Brightness-Down button (Fn+Dn) my stage jumps to 7 (sic!) regardless of the previous position. And my true brightness jumps to 0xd6.

5. If I susend the laptop, after a resume I am geting Stage 8 in /sys/devices/platform/samsung/backlight/samsung/brightness, while the PCI register says: 0x7c ! Note, that this value is not accessible by using the GUI. Even if I move the brigtness slider completely to the right, or if I will hit Fn+Up many times, I am only geting up to 0xd6

6. I have /org/gnome/settings-daemon/plugins/power/lid-close-ac-action set to 'blank' the screen when the lid is closed. I I close the lid for less than ~10 seconds, my brightess is not change from the previous level. But if I will wait for more ~10 seconds, after the screen will turn on, it will be on 100% brightness (exactly 0xff value), and the stage will be 8.


So, there is a clear disjoint between real screen brightness, as reported by the 8-bit PCI registers, and by the internal discrete brightness stages that are shared between the Settings, whole GUI and a file /sys/devices/platform/samsung/backlight/samsung/brightness

This is certainly a bug in the Operating System, however I an not sure in which part of it.
I hope that my investigations will help.



PS. There are also files called:
  /sys/bus/pci/devices/0000:00:02.0/backlight/acpi_video0/actual_brightness
and
  /sys/bus/pci/devices/0000:00:02.0/backlight/acpi_video0/brightness
and 
  /sys/bus/pci/devices/0000:00:02.0/backlight/acpi_video0/max_brightness
These are consantly equal to 7, regardless of a true brightness! Next wierd thing.

Comment 9 Justin M. Forbes 2012-12-07 15:52:07 UTC
Has this gotten any better with 3.6.9?