with kernel 3.14.x it it seems that everything is rendered correctly, but just the display is turned off as soon as an external monitor is attached.

here is the output of lspci on kernel 3.14:
# uname -r
3.14.4-200.fc20.x86_64
# lspci -n -vv -s 00:02.0
00:02.0 0300: 8086:0166 (rev 09) (prog-if 00 [VGA controller])
	Subsystem: 17aa:21fa
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Interrupt: pin A routed to IRQ 43
	Region 0: Memory at f0000000 (64-bit, non-prefetchable) [size=4M]
	Region 2: Memory at e0000000 (64-bit, prefetchable) [size=256M]
	Region 4: I/O ports at 5000 [size=64]
	Expansion ROM at <unassigned> [disabled]
	Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
		Address: fee0200c  Data: 41d1
	Capabilities: [d0] Power Management version 2
		Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [a4] PCI Advanced Features
		AFCap: TP+ FLR+
		AFCtrl: FLR-
		AFStatus: TP-
	Kernel driver in use: i915
	Kernel modules: i915

Hi,

Thanks for the bug report. Note this sounds like a duplicate of bug 1032978. But lets keep your case in this separate bug for now. A couple of questions:

1) Can you make the black screen work again by pressing the brightness up key-combo on your keyboard?

2) Does the brightness up/down key-combo on your keyboard work when not docked?

3) Can you please do "ls /sys/class/backlight" and copy and paste the output here?

4) Can you try adding "video.use_native_backlight=0" to your kernel commandline and see if that fixes things ?

5) If 4) fixes things, can you try if:
 5.1) the brightness up/down key-combo still works ? 
 5.2) things still work after suspend / resume when not docked
 5.3) things still work after suspend / resume when docked

Thanks & Regards,

Hans

Also can you please try the latest 3.15 kernel? With some luck this has already been fixed, you cfan find the latest 3.15 kernel build for Fedora here:
http://koji.fedoraproject.org/koji/buildinfo?buildID=520926

Download the kernel-3.15...rpm for your architecture and then install it using:

sudo rpm -ivh kernel-3.15...rpm

Note when installing kernels it is important to rpm -i so that you keep your current kernel as a backup.

Hello Hans,
here are my findings:
1) Can you make the black screen work again by pressing the brightness up key-combo on your keyboard?

Yes this worked. The brightness was off, i.e.  
# cat /sys/class/backlight/intel_backlight/brightness
0
After using the keys this number increased.

When GDM is started this value is set to zero and immediately after successful login it is reset to zero again.

2) Does the brightness up/down key-combo on your keyboard work when not docked?
yes -- it is working.

3) Can you please do "ls /sys/class/backlight" and copy and paste the output here?

# ls /sys/class/backlight
intel_backlight

4) Can you try adding "video.use_native_backlight=0" to your kernel commandline and see if that fixes things ?

Yes, things are fixed. After using this boot-option I see:
# ls /sys/class/backlight
acpi_video0  intel_backlight

5) If 4) fixes things, can you try if:
 5.1) the brightness up/down key-combo still works ? 
 Yes, works sort of. Initially the screen is shown, after pressing any of the brightness keys the brightness value is set to 0 (aka black screen).

 5.2) things still work after suspend / resume when not docked
=> So I check this later
 5.3) things still work after suspend / resume when docked
=> So I check this later

Hi,

(In reply to Markus Koch from comment #4)
> Hello Hans,
> here are my findings:
> 1) Can you make the black screen work again by pressing the brightness up
> key-combo on your keyboard?
> 
> Yes this worked. The brightness was off, i.e.  
> # cat /sys/class/backlight/intel_backlight/brightness
> 0
> After using the keys this number increased.
> 
> When GDM is started this value is set to zero and immediately after
> successful login it is reset to zero again.
> 
> 2) Does the brightness up/down key-combo on your keyboard work when not
> docked?
> yes -- it is working.
> 
> 3) Can you please do "ls /sys/class/backlight" and copy and paste the output
> here?
> 
> # ls /sys/class/backlight
> intel_backlight
> 
> 4) Can you try adding "video.use_native_backlight=0" to your kernel
> commandline and see if that fixes things ?
> 
> Yes, things are fixed. After using this boot-option I see:
> # ls /sys/class/backlight
> acpi_video0  intel_backlight
> 
> 5) If 4) fixes things, can you try if:
>  5.1) the brightness up/down key-combo still works ? 
>  Yes, works sort of. Initially the screen is shown, after pressing any of
> the brightness keys the brightness value is set to 0 (aka black screen).

I would not call that working, so forget about 5.1 and 5.2 for now. Can you try adding 
acpi_osi="!Windows 2012"
to the kernel cmdline, while keeping the video.use_native_backlight=0, so you should end up with the following extra arguments on your kernel cmdline:

video.use_native_backlight=0 acpi_osi="!Windows 2012"

Note the quotes around !Windows 2012, these must be present for this to work. Hopefully this will fix your brightness keys not working when using video.use_native_backlight=0.

Thanks,

Hans

5.2) things still work after suspend / resume when not docked
 yes, it's working. The screen remains off until a key is pressed
 This is the same behaviour, when:
   - suspend docked and resume undocked
   - suspend undocked and resume docked
5.3) things still work after suspend / resume when docked
  yes, it's working. The screensaver shows up before something is typed


Another intersting thing happens: The screen cannot be turned black again with the brightness keys after suspend/resume just very dark (lowest value):
# cat /sys/class/backlight/intel_backlight/brightness
68
also the highest value 4437 could not be reached, just 4435.

or in other words - with the "video.use_native_backlight=0" paramter the brightness keys are not working in the full range any more - which is ok for me

Installing the 3.15.x kernel did not help. It is the same behaviour.

I read through bug 1032978 and it seems like a duplicate, but I didn't have the problem with 3.13.x kernels as some other people had.

Hi Hans,

Now it's working perfectly fine:
video.use_native_backlight=0 acpi_osi="!Windows 2012"

The valuse of /sys/class/backlight/acpi_video0/brightness can be changed between 0 and 100

thes map to intel_backlight values between 68 and 4335 

I completely happy now with these settings

LG
Markus

Hi Markus,

Good to hear that:

video.use_native_backlight=0 acpi_osi="!Windows 2012"

On the kernel commandline fixes things for you.

But I'm not quite sure that that is the fix we want to move forward with, reading your comments about everything being fine until gdm starts, combined with similar comments in bug 1032978 , I'm getting the feeling that this is a userspace issue which gets triggered by video.use_native_backlight=1 (*)

Could you run one more test for me ? 

I've done a scratch build of the Fedora-20 intel driver with some debugging added to try and see
where the 0 it is allegedly writing to brightness is coming from.  You can find it here:
http://koji.fedoraproject.org/koji/taskinfo?taskID=6917469

Please install this, reboot with an external monitor plugged in. Once the screen has turned black in gdm, please wait at least 30 seconds before doing anything (so that I can use the timestamps to determine when the going black happened).

Then log in and collect the /var/log/Xorg.0.log file and attach it here.

Thanks,

Hans


*) Which was enabled in 3.14 for your laptop to fix the brightness keys misbehaving.

Created attachment 901901 [details]
Xorg log with debugging messages

Hi Hans,
I attached the file. Interesting part seems to be this one:
[    20.464] (II) intel(0): XRANDR backlight property set to 4437, DPMS mode 0
[    20.906] (II) intel(0): DPMS off mode 3, saved backlight level 0
[    21.296] (II) intel(0): DPMS on mode 0, setting backlight to 0
[    21.296] (II) intel(0): XRANDR backlight property get, active_level 0, DPMS 

These lines are shown when gdm is started and probably after the successful login. 
If you need or prefer I can open an account on my laptop and you can login directly.

HTH
 Markus

Hi Hans,
I suspended the system yesterday and resumed this morning. I figured out that suspend/resume already restores the backlight correctly.
So I attach the Xorg log with the resume from this morning included.

I tested suspend resume several times then and ended up in a kernel panic.
I have attached the corresponding screenshot -- I do not have kdump enabled :-( 

Regards
 Markus

Created attachment 901986 [details]
Xorg with additional suspend/resume log

Created attachment 901989 [details]
Screenshot from kernel panic

Not sure if the kdump is releated

Created attachment 901993 [details]
Screenshot from kernel panic (sharper)

Hi,

I think I know what is causing this, here is a new (scratch) xorg-x11-drv-intel package, which should fix this:

http://koji.fedoraproject.org/koji/taskinfo?taskID=6926499

Please give this a try without using any special kernel commandline options, and let me know if it fixes things. Please also collect and attach Xorg.0.log again.

Thanks & Regards,

Hans

As for the panic, that is in the block layer, and as such likely unrelated to the backlight issues you've been seeing. May be triggered by the acpi_osi="!Windows 2012", or (more likely) just a glitch / unrelated hard to trigger bug.

Created attachment 902532 [details]
Xorg log with fixed package

Hi Hans,
well done. Everything works as expected.
I also tested suspend/resume with external monitor and brightness keys
Seems to be all fine.

Cheers
 Markus

Markus,

Upstream has come up with a fix which in some ways is quite different, which I've backported to the intel driver version in F-20. Can you please give this build a try:

https://bugzilla.redhat.com/show_bug.cgi?id=1032978

Once I've confirm that the (backported) upstream commit also fixes the backlight issues people have reported, then I'll do an official build with these fixes in, and we can finally close this bug.

Thanks,

Hans

Something went wrong with copy-ing and pasting the scratch build url, this is the correct url for the build to test:

http://koji.fedoraproject.org/koji/taskinfo?taskID=7042962

Thanks,

Hans

Hi Hans,
thumbs up :-) This patch is also working. To be sure I have tested with exactly the same environment as before upgrade to the latest kernel, which I will do now.

I did the checks of suspend resume in with ext. monitor & without. All is working fine.

Cheers
 Markus

Markus,

Once more thanks for all the testing and the quick turn around time on all the tests. I'm going to wait a bit for people with similar problems (bug 1032978) to get back to me on their results with the latest build, and if things work for them too I'll kick of an official build and send it to updates-testing.

In the mean time please keep using the build from comment #19, and let me know if you see any issues with it.

Regards,

Hans

xorg-x11-drv-intel-2.21.15-7.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/xorg-x11-drv-intel-2.21.15-7.fc20

Package xorg-x11-drv-intel-2.21.15-7.fc20:
* should fix your issue,
* was pushed to the Fedora 20 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing xorg-x11-drv-intel-2.21.15-7.fc20'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2014-7476/xorg-x11-drv-intel-2.21.15-7.fc20
then log in and leave karma (feedback).

xorg-x11-drv-intel-2.21.15-7.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.