Description of problem: In recent kernel 3.10.3-300.fc19.x86_64 screen goes black when Xorg starts, nothing to do except reboot the system. Hardware: asus n56vb laptop, intel hd4000 video (intel core i7 3630QM). No errors in Xorg log. Works fine with 3.9.9-302.fc19.x86_64 kernel. Version-Release number of selected component (if applicable): 3.10.3-300.fc19.x86_64 How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Same issue here with Integrated Graphics Chipset: Intel(R) Ivybridge Mobile (GT2) / i965
This might be a duplicate of 989093. Please test the 3.10.4 build later today.
Tested kernel-3.10.4-300.fc19.x86_64, has the same problem/effect as kernel-3.10.3-300.fc19.x86_64.
I confirm, in 3.10.4 problem still persists
Same problem here (ASUS X202E, Intel HD4000, i3-3217U CPU) and kernel 3.10.4-300.fc19.x86_64. Workaround: I discovered that "just" the brightness appears to be at 0. Using the brightness related key on the keyboard switches it on. Note: There was no such problem in F18, I just updated with fedup to F19. lspci -nn | grep Intel 00:00.0 Host bridge [0600]: Intel Corporation 3rd Gen Core processor DRAM Controller [8086:0154] (rev 09) 00:02.0 VGA compatible controller [0300]: Intel Corporation 3rd Gen Core processor Graphics Controller [8086:0166] (rev 09) 00:04.0 Signal processing controller [1180]: Intel Corporation 3rd Gen Core Processor Thermal Subsystem [8086:0153] (rev 09) 00:14.0 USB controller [0c03]: Intel Corporation 7 Series/C210 Series Chipset Family USB xHCI Host Controller [8086:1e31] (rev 04) 00:16.0 Communication controller [0780]: Intel Corporation 7 Series/C210 Series Chipset Family MEI Controller #1 [8086:1e3a] (rev 04) 00:1a.0 USB controller [0c03]: Intel Corporation 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #2 [8086:1e2d] (rev 04) 00:1b.0 Audio device [0403]: Intel Corporation 7 Series/C210 Series Chipset Family High Definition Audio Controller [8086:1e20] (rev 04) 00:1c.0 PCI bridge [0604]: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 1 [8086:1e10] (rev c4) 00:1c.1 PCI bridge [0604]: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 2 [8086:1e12] (rev c4) 00:1c.3 PCI bridge [0604]: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 4 [8086:1e16] (rev c4) 00:1d.0 USB controller [0c03]: Intel Corporation 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #1 [8086:1e26] (rev 04) 00:1f.0 ISA bridge [0601]: Intel Corporation HM76 Express Chipset LPC Controller [8086:1e59] (rev 04) 00:1f.2 SATA controller [0106]: Intel Corporation 7 Series Chipset Family 6-port SATA Controller [AHCI mode] [8086:1e03] (rev 04) 00:1f.3 SMBus [0c05]: Intel Corporation 7 Series/C210 Series Chipset Family SMBus Controller [8086:1e22] (rev 04) 00:1f.6 Signal processing controller [1180]: Intel Corporation 7 Series/C210 Series Chipset Family Thermal Management Controller [8086:1e24] (rev 04)
Integrated Graphics Chipset: Intel(R) Ivybridge Mobile (GT2) / i965 I can confirm the workaround "adjusting brightness up" works for me too, good find markusN!
This workaround doesn't work for me because function keys on my laptop is not always recognized properly. Some work only after login, some (calc, cam) can even scramble future function key sequences (what's the problem with asus laptop keyboards? function keys almost never worked properly). However I can type password 'blindly' and login, and brightness gets automatically adjusted to 100% after login.
(In reply to The Source from comment #7) > This workaround doesn't work for me because function keys on my laptop is > not always recognized properly. Confirmed for the brightness keys (kind of random behaviour). > However I can type password 'blindly' and login, and brightness > gets automatically adjusted to 100% after login. Also confirmed, I work like this at time rather than trying my previous workaround. I wonder if the value is store here (and initially at 0): /sys/class/backlight/acpi_video0/brightness
(In reply to markusN from comment #8) > (In reply to The Source from comment #7) The recent update to3.10.6-200.fc19.x86_64 did not help. > > However I can type password 'blindly' and login, and brightness > > gets automatically adjusted to 100% after login. Still valid.
I'm now using 'provider output source' randr extension to render everything on nvidia card. I had to place some additional commands into login manager startup script to make such setup work properly. I found out that brightness on login screen is perfectly fine with 3.10.6 kernel in this case. I'm not sure if it will work with pure intel rendering but could you try placing 'xrandr --auto' into your login manager startup script? (for kdm it's /etc/kde/kdm/Xsetup)
(In reply to The Source from comment #10) > ... but could you try placing > 'xrandr --auto' into your login manager startup script? (for kdm it's > /etc/kde/kdm/Xsetup) I am using lightdm-1.6.0-10.fc19.x86_64 and wonder where to find the login manager startup script in this case. Or any other place to put the command?
OK, I found a new trick: I have added in file /etc/profile the line: echo "80" > /sys/class/backlight/acpi_video0/brightness Dirty hack but helpful.
This bug report may be of interest: https://bugzilla.kernel.org/show_bug.cgi?id=51231 as well as https://bugzilla.kernel.org/show_bug.cgi?id=60682
(In reply to markusN from comment #9) > (In reply to markusN from comment #8) > > (In reply to The Source from comment #7) > > > However I can type password 'blindly' and login, and brightness > > > gets automatically adjusted to 100% after login. > > Still valid. The same with kernel 3.10.9-200.fc19.x86_64
After login the backlight is 0%: [root@oboe grassdata]# intel_backlight current backlight value: 0% Like this it switch properly on: [root@oboe grassdata]# intel_backlight 100 current backlight value: 0% set backlight to 100% The command is available in the RPM intel-gpu-tools. Kernel 3.10.10-200.fc19.x86_64 still shows the backlight=0% bug.
It seems that I found a solution: Edit /boot/efi/EFI/fedora/grub.cfg and add to the grub bootline acpi_backlight=vendor See attachment "grub_intel_backlight_fix.diff" for the change. Now also the Asus brightness function keys work properly and no longer randomly. See also Bug 991707 comment 23
Created attachment 796069 [details] diff fixing backlight issue for grub bootline (/boot/efi/EFI/fedora/grub.cfg)
markusN, Thank you, works for me. Gr, J
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 19 kernel bugs. Fedora 19 has now been rebased to 3.11.1-200.fc19. Please test this kernel update and let us know if you issue has been resolved or if it is still present with the newer kernel. If you experience different issues, please open a new bug report for those.
This bug is being closed with INSUFFICIENT_DATA as there has not been a response in 2 weeks. If you are still experiencing this issue, please reopen and attach the relevant data from the latest kernel you are running and any data that might have been requested previously.
For the record: As reported above, editing manually the boot option in /boot/efi/EFI/fedora/grub.cfg helps. With each update, I add acpi_backlight=vendor (However, due to other severe bugs (alx driver bug, mei_me bug which both fill the hard disk with log junk), I have to stick with kernel 3.10.6, so not much to report here)
I'm finding that the work around does no solve the problem for kernel-3.11.6-200.fc19.x86_64 adding acpi_backlight=vendor to the /etc/sysconfig/grub GRUB_CMDLINE_LINUX variable still results in screen blank early in the boot process.