Bug 713946 - Backlight control does not work in Fedora 15 on Samsung X360 (worked in F12)
Backlight control does not work in Fedora 15 on Samsung X360 (worked in F12)
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
All Linux
unspecified Severity medium
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
first= tested=3.3.4 backlight
Depends On:
  Show dependency treegraph
Reported: 2011-06-16 16:38 EDT by JanS
Modified: 2013-01-02 08:10 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2013-01-02 08:10:44 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
dmesg (123.23 KB, text/plain)
2011-06-16 16:38 EDT, JanS
no flags Details
/var/log/messages (178.72 KB, text/plain)
2011-06-16 16:39 EDT, JanS
no flags Details
Xorg.0.log (28.71 KB, text/plain)
2011-06-16 16:40 EDT, JanS
no flags Details
lspci -vvnn (12.82 KB, text/plain)
2011-06-16 16:40 EDT, JanS
no flags Details

  None (edit)
Description JanS 2011-06-16 16:38:03 EDT
Created attachment 505140 [details]

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 #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 16:39:47 EDT
Created attachment 505141 [details]
Comment 2 JanS 2011-06-16 16:40:14 EDT
Created attachment 505142 [details]
Comment 3 JanS 2011-06-16 16:40:46 EDT
Created attachment 505143 [details]
lspci -vvnn
Comment 4 Josh Boyer 2011-10-20 21:40:24 EDT
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 11:31:50 EDT
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 10:29:37 EDT
Are you still having issues with the 2.6.43/3.3 kernel updates?
Comment 7 JanS 2012-06-07 10:47:27 EDT
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 15:59:47 EDT
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:
(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:
These are consantly equal to 7, regardless of a true brightness! Next wierd thing.
Comment 9 Justin M. Forbes 2012-12-07 10:52:07 EST
Has this gotten any better with 3.6.9?

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