Bug 79581 - [Regression] Internal backlight brightness initially set to 0 when external display is connected
Summary: [Regression] Internal backlight brightness initially set to 0 when external d...
Status: CLOSED INVALID
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: highest major
Assignee: Intel GFX Bugs mailing list
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-06-03 10:42 UTC by Michael Monreal
Modified: 2016-10-13 08:28 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:

Attachments
drm.debug=6 dmesg (243.95 KB, text/plain)
2014-06-03 21:03 UTC, Michael Monreal 		no flags Details
View All

Description Michael Monreal 2014-06-03 10:42:34 UTC 
When I boot my laptop with "Intel(R) HD Graphics 4000" and my external display connected via Mini DisplayPort (only connector), the brightness (/sys/class/backlight/intel_backlight/brightness) of the internal screen is set to 0 each time the X server is started:

a) After boot, GDM starts and the internal screen turns black. I can still log in blindly. I can also go to a VT and back (ctrl-alt-f2, alt-f1) and the brightness will be fine.

b) When GNOME starts (new X server I suppose?) the same thing happens again. Going to a VT and back does NOT work around the problem, I need to do something like "echo 4000 > /sys/class/backlight/intel_backlight/brightness" or try to navigate to the brightness control manually.

This is on Fedora 20 with the following packages:
- xorg-x11-drv-intel-2.21.15-5.fc20.x86_64
- kernel-3.14.4-200.fc20.x86_64

I can also reproduce this 100% on the Fedora 20 live CD, which has:
- xorg-x11-drv-intel-2.21.15-5.fc20.x86_64
- kernel-3.11.10-301.fc20.x86_64

This is a regression from Fedora 19, where it used to work fine. I just verified again and the problem does not show onf the Fedora 19 live CD, which has:
- xorg-x11-drv-intel-2.21.8-1.fc19.x86_64
- kernel-3.9.5-301.fc19.x86_64

If there is anything else I can provide please ask me.
Comment 1 Chris Wilson 2014-06-03 11:17:43 UTC 
Let's start with a drm.debug=6 dmesg from boot.
Comment 2 Michael Monreal 2014-06-03 21:03:33 UTC 
Created attachment 100371 [details]
drm.debug=6 dmesg

The attached drm.debug=6 dmesg output shows:
- boot (brightness ok) to gdm (brightness 0)
- switch to tty 2 (brightness ok)
- switch to gdm (brightness ok)
- login to gnome (brightness 0)
- manually set brightness in gnome
Comment 3 Michael Monreal 2014-06-03 21:04:59 UTC 
(clear needinfo for now, please ask for more logs etc if you need them)
Comment 4 Chris Wilson 2014-06-03 21:13:01 UTC 
Actually, since you are only on 2.21.15, this likely to be an issue with

commit 28a057105b6974803aee0d68c2a71f322095dfde
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Mon Jan 6 14:37:09 2014 +0000

    uxa: Disable updating properties upon reading their values
    
    Backport commit e76b08cad2770015346fd4cd757de3bb3b6ff37c
    Author: Chris Wilson <chris@chris-wilson.co.uk>
    Date:   Tue Oct 15 12:46:09 2013 +0100
    
        sna: Disable updating properties upon reading their values
    
    in order to prevent random screen blanking upon return from DPMS.
    
    Reported-by: Alexander Monakov <amonakov@gmail.com>
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73181
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Comment 5 Michael Monreal 2014-06-03 21:30:06 UTC 
>> since you are only on 2.21.15

Well 2.21.15 is the very latest for Fedora 20. Is this supposed to be fixed in a newer release? If so, I could try a Fedora 21/Rawhide Live and check.
Comment 6 Michael Monreal 2014-07-03 20:45:53 UTC 
The problem seems to be gone on Fedora 20 with latest updates:

kernel-3.14.9-200.fc20.x86_64
xorg-x11-drv-intel-2.21.15-7.fc20.x86_64
Comment 7 Jari Tahvanainen 2016-10-13 08:28:55 UTC 
Closing resolved+invalid, verified by Reporter: "The problem seems to be gone on Fedora 20 with latest updates"

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.