Bug 90151

Summary: Laptop Backlight Issue with Hybrid Graphics System
Product: DRI Reporter: Kevin Sarendranath <k.sarendranath>
Component: DRM/RadeonAssignee: Default DRI bug account <dri-devel>
Status: RESOLVED NOTABUG QA Contact:
Severity: normal    
Priority: medium    
Version: unspecified   
Hardware: x86-64 (AMD64)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
dmesg output
none
xorg log none

Description Kevin Sarendranath 2015-04-23 04:25:41 UTC
Kernel Version: 3.19.3
Radeon Version: 1:7.5.0-2
Xorg Verison: 1.17.1-5


The system being used is a Lenovo Thinkpad configured with an R7 M260DX discrete card attached to an A10-7300. Upon booting it, the kernel spits out this message:


[drm:radeon_acpi_init [radeon]] *ERROR* Cannot find a backlight controller


with the quirk of having the brightness hotkeys not being able to control the brightness. Looking into the radeon source, here is where the call came from (radeon_acpi.c):


atif->encoder_for_bl = target;
		if (!target) {
			/* Brightness change notification is enabled, but we
			 * didn't find a backlight controller, this should
			 * never happen.
			 */
			DRM_ERROR("Cannot find a backlight controller\n");
		}

Is this an issue within the driver or from Lenovo's acpi implementation?

If anything, I can control the backlight by using the /sys/ subsystem so I can remap the hotkeys to control the brightness while systemd will store it on reboot. In essence, I just wanted to bring this to attention due to the comment in the source.

Also a quick question on hybrid graphics, the radeon feature matrix states that Enduro is mostly complete and I believe that this lenovo system is muxless. Checking vgaswitcheroo, the integrated card is used while the discrete card is "DynOff" which I presume is dynamically off. Does that mean the driver is currently powering on the discrete card when rendering is required? Or is something else required?

Thanks for any answers.
Comment 1 Alex Deucher 2015-04-23 14:10:19 UTC
(In reply to Kevin Sarendranath from comment #0)
> 
> Is this an issue within the driver or from Lenovo's acpi implementation?
> 

Please attach your xorg log and dmesg output.

> If anything, I can control the backlight by using the /sys/ subsystem so I
> can remap the hotkeys to control the brightness while systemd will store it
> on reboot. In essence, I just wanted to bring this to attention due to the
> comment in the source.
> 
> Also a quick question on hybrid graphics, the radeon feature matrix states
> that Enduro is mostly complete and I believe that this lenovo system is
> muxless. Checking vgaswitcheroo, the integrated card is used while the
> discrete card is "DynOff" which I presume is dynamically off. Does that mean
> the driver is currently powering on the discrete card when rendering is
> required? Or is something else required?

By default the dGPU is powered off.  It's powered on dynamically when you want to use it for rendering.  See:
https://wiki.archlinux.org/index.php/PRIME
Comment 2 Kevin Sarendranath 2015-04-23 16:02:23 UTC
Created attachment 115296 [details]
dmesg output
Comment 3 Kevin Sarendranath 2015-04-23 16:02:54 UTC
Created attachment 115297 [details]
xorg log
Comment 4 Kevin Sarendranath 2015-04-23 16:09:25 UTC
Thanks for pointing out PRIME. 

Here's the dmesg and xorg logs.
Comment 5 Alex Deucher 2015-04-23 16:16:40 UTC
(In reply to Kevin Sarendranath from comment #0)
> The system being used is a Lenovo Thinkpad configured with an R7 M260DX
> discrete card attached to an A10-7300. Upon booting it, the kernel spits out
> this message:
> 
> 
> [drm:radeon_acpi_init [radeon]] *ERROR* Cannot find a backlight controller
> 

This message is from the dGPU which is not connected to any displays so it can be ignored.  The backlight control is properly initialized on the APU which is the chip that controls the backlight.

[    2.419773] [drm] radeon atom DIG backlight initialized

> 
> with the quirk of having the brightness hotkeys not being able to control
> the brightness. Looking into the radeon source, here is where the call came
> from (radeon_acpi.c):

What the brightness keys do is up to the OEM.  On most modern laptops, they tend to just generate key press events rather than actually changing the brightness or generating acpi events.  It's up to the desktop environment to map that event to the brightness controls exposed by the kernel.
Comment 6 Kevin Sarendranath 2015-04-23 17:27:15 UTC
Well that explains it. Good to know it's not a real issue.

Thanks again for the help.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.