Bug 90151 - Laptop Backlight Issue with Hybrid Graphics System
Summary: Laptop Backlight Issue with Hybrid Graphics System
Status: RESOLVED NOTABUG
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Radeon (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Default DRI bug account
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-04-23 04:25 UTC by Kevin Sarendranath
Modified: 2015-04-23 17:27 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
dmesg output (68.91 KB, text/plain)
2015-04-23 16:02 UTC, Kevin Sarendranath
no flags Details
xorg log (44.40 KB, text/plain)
2015-04-23 16:02 UTC, Kevin Sarendranath
no flags Details

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.