[Bug 76811] Kernel sets wrong screen brightness resuming from suspend on Optimus enabled laptop

[bugzilla-daemon at bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=76811

--- Comment #3 from JU <poeticrpm at gmail.com> ---
(In reply to Jani Nikula from comment #2)
> What driver do you use for optimus?
Driver? I use bumblebee and primusrun, though the bug exists whether bumblebeed
is enabled or not.

As for video drivers, I use xf86-video-intel and proprietary nvidia drivers
(both installed from the Arch repos; no 3rd party builds).

> Which ones of the interfaces at /sys/class/backlight change the backlight
> brightness if you echo there? (Note the potentially differing max_brightness
> values.)
> 
> Echo distinct values to the brightness, cat brightness and actual_brightness
> for each and paste here, do a suspend/resume, and repeat the cat and paste.

===Before suspend/resume, backlight at 50% (set with brightness keys on
keyboard, no xorg-xbacklight isntalled)===

cat /sys/class/backlight/intel_backlight/brightness   --->  578
cat /sys/class/backlight/intel_backlight/actual_brightness   --->  578
cat /sys/class/backlight/intel_backlight/max_brightness   ---> 4437
echo "4437" > /sys/class/backlight/intel_backlight/brightness   ---> Seems to
go full bright
echo "0" > /sys/class/backlight/intel_backlight/brightness   ---> Literally
kills the backlight
echo "<some number>" > /sys/class/backlight/intel_backlight/actual_brightness  
---> permission denied (ran as root)
Note: if I echo a number between 0 and 4437 to .../intel_backlight/brightness,
the brightness scales (higher numbers = brighter screen). 50% brightness
equates to 578 strangely.


cat /sys/class/backlight/acpi_video1/max_brightness   ---> 100
cat /sys/class/backlight/acpi_video1/actual_brightness   ---> 50
cat /sys/class/backlight/acpi_video1/brightness   ---> 50
echo "100" > /sys/class/backlight/acpi_video1/brightness   ---> screen goes
full bright
echo "10" > /sys/class/backlight/acpi_video1/brightness   ---> Screen goes full
dim, but is still visible
echo "<some number>" > /sys/class/backlight/acpi_video1   ---> permission
denied (ran as root)
Note: if I echo a number between 10 and 100, the screen brightness scales as
expected


cat /sys/class/backlight/acpi_video0/max_brightness   ---> 100
cat /sys/class/backlight/acpi_video0/actual_brightness   ---> 50
cat /sys/class/backlight/acpi_video0/brightness   ---> 50
echo "100" > /sys/class/backlight/acpi_video0/brightness   ---> Screen full
bright.
echo "10" > /sys/class/backlight/acpi_video0/actual_brightness   --->
permission denied (ran as root)

Time to suspend.

Heres where it gets complicated:

1) When I resume from suspend, the kernel reads the value from
/sys/class/backlight/acpi_video1/brightness. I know this because:
    A) echo "100" > /sys/class/backlight/acpi_video1/brightness
    B) echo "50" > /sys/class/backlight/acpi_video0/brightness
    C) Suspend
    Result: Computer goes into suspend at half screen brightness, and comes out
of suspend full bright.
If instead I do the following:
    A) echo "100" > /sys/class/backlight/acpi_video0/brightness
    B) echo "50" > /sys/class/backlight/acpi_video1/brightness
    C) Suspend
    Result: Computer goes into suspend at half screen brightness, and comes out
of suspend at half brightness.
2) The brightness keys change the value of .../acpi_video0/brightness and NOT
.../acpi_video1/brightness. Yet whatever value is echoed to
.../acpi_video1/brightness is the value the kernel sets the screen brightness
from after resuming from suspend.

/sys/class/backlight/intel_backlight/brightness changes no matter whether I use
the brightness keys, or echo manually to acpi_video0 and acpi_video1 brightness
files.

Note: All the cat and echoing I did in the first 3 paragraphs functions exactly
the same when doing them after suspend.

Summary: The kernel is checking the brightness file on acpi_video1, yet when
the kernel changes the screen brightness using the brightness keys on the
keyboard, it changes the brightness file value of acpi_video0. Thus, anytime
one resumes from suspend, the kernel will choose the wrong device to read
brightness values from.

I think it may be possible to cheat with Xorg by setting a rule in the
xorg.conf. I should note that when Optimus is disabled in BIOS, suspend works
fine (only the intel card is seen by Linux).

Also, heres a snippet from journalctl that might be of interest to you:
May 26 17:12:14 codething kernel: Non-volatile memory driver v1.3
May 26 17:12:14 codething kernel: thinkpad_acpi: ThinkPad ACPI Extras v0.25
May 26 17:12:14 codething kernel: thinkpad_acpi: http://ibm-acpi.sf.net/
May 26 17:12:14 codething kernel: thinkpad_acpi: ThinkPad BIOS G4ET98WW (2.58
), EC unknown
May 26 17:12:14 codething kernel: thinkpad_acpi: Lenovo ThinkPad T530, model
2359CTO
May 26 17:12:14 codething kernel: thinkpad_acpi: Unsupported brightness
interface, please contact ibm-acpi-devel at lists.sourceforge.net
May 26 17:12:14 codething kernel: thinkpad_acpi: radio switch found; radios are
enabled
May 26 17:12:14 codething kernel: thinkpad_acpi: This ThinkPad has standard
ACPI backlight brightness control, supported by the ACPI video driver
May 26 17:12:14 codething kernel: thinkpad_acpi: Disabling thinkpad-acpi
brightness events by default...
May 26 17:12:14 codething kernel: thinkpad_acpi: rfkill switch
tpacpi_bluetooth_sw: radio is unblocked
May 26 17:12:14 codething kernel: thinkpad_acpi: Console audio control enabled,
mode: monitor (read only)
May 26 17:12:14 codething kernel: input: PC Speaker as
/devices/platform/pcspkr/input/input8


Whew, I hope that wasnt too confusing; I tried to be clear. Let me know if you
need any other info.

-- 
You are receiving this mail because:
You are on the CC list for the bug.