Description of problem: After upgrading to 3.10.3-300.fc19 brightness in X session is reduced to 0. Text session has correct brightness. Switching back to older kernel 3.9.5-301 (this was fresh install + updates) all works fine. I can change brightness using /sys/devices/pci0000:00/0000:00:02.0/drm/card0/card0-LVDS-1/intel_backlight/brightness but after reboot it backs to 0. Version-Release number of selected component (if applicable): # rpm -q kernel kernel-3.9.5-301.fc19.i686 kernel-3.10.3-300.fc19.i686 How reproducible: Steps to Reproduce: 1. update system to latest 2. reboot, and select 3.10.3-300 kernel 3. boot in to X session, or start it manually Actual results: brightness is set to 0 in /sys/devices/pci0000:00/0000:00:02.0/drm/card0/card0-LVDS-1/intel_backlight/brightness Expected results: Brightnesss should be different from 0 (it should inherit values from text mode). Additional info: I have 3 laptops with F19, and only this one has the problem: ASUS K55VJ. Problem doesn't exist on ASUS EeePc 1215N and ASUS UX21e. So it is hardware specific problem.
Created attachment 780138 [details] dmesg Three last line occurs when I run lspci (three times).
Created attachment 780139 [details] dmidecode
Created attachment 780140 [details] lspci
Created attachment 780481 [details] Xorg.log
I noticed brightness going to zero with kernel-3.10.2-301.fc19.x86_64 and also kernel-3.11.0-0.rc2.git3.2.fc20.x86_64 on a Thinkpad T420s. [with intel sandy-bridge gpu] But I could recover from with with the brightness-increase function on the keyboard. Now I'm with kernel-3.11.0-0.rc3.git0.1.fc20.x86_64 - and I haven't noticed this issue [so perhaps the fix is somewhere in the 3.11 rc tree..]
I see this, but only when I hibernate the system, on an older Thinkpad X200s (Montevina, Intel graphics only). - Laptop booted up normally with brightness to maximum. - Laptop stays plugged in to AC throughout this sequence. - Laptop is on docking station, through which it's connected to a second display through HDMI2 (per xrandr -q). - I start hibernation (whether with Fn-F12 or "systemctl hibernate", same behavior). - After the state is saved to disk and right before the machine powers off, the laptop panel is set to minimum brightness. - Laptop panel still in minimum brightness when I power up the machine again; I have to manually increase brightness to be able to read the grub menu. I have not been able to reproduce this with sleep; only hibernation seems to trigger it on this system. This started with kernel 3.10.3-300.fc19. I'll try to install the latest rawhide kernel and see what that does.
Well, 3.11.0-0.rc3.git0.1.fc20 did not fix this for me...
(In reply to Dimitris from comment #7) > Well, 3.11.0-0.rc3.git0.1.fc20 did not fix this for me... And for what it's worth neither did 3.10.4-300.fc19.x86_64
Just to confirm, I'm seeing the same thing: just installed Fedora 19 on an Asus UX31A, yum update installed a new kernel, and I get the blank screen.
I can confirm problem on Asus G46VW. All testing updates r installed. kernel-3.10.3-300.fc19.x86_64 & kernel-3.10.4-300.fc19.x86_64 are affected
Per comment 6, my symptoms were different but after going through https://bugzilla.kernel.org/show_bug.cgi?id=51231 and https://bugzilla.kernel.org/show_bug.cgi?id=60682 I finally got my thinkpad to behave more or less correctly, so this might help others: I can get the laptop panel brightness to behave, including across suspends and hibernations, by the following three additions to the kernel command line: acpi_osi=Linux I prefer this over acpi_osi="!Windows 2012" as the latter breaks (this older thinkpad's) mute key. acpi_backlight=vendor thinkpad_acpi.brightness_enable=0 With Intel graphics at least, this allows me to control brightness from both X and consoles, and when in X have OSD feedback. The "grading" of the OSD bar and brightness levels themselves isn't "linear", i.e. each step down seems to subtract a certain percentage of remaining brightness, instead of a fixed "slice". Also, the lowest brightness level turns the screen off, unlike the ACPI video driver. Hope this helps.
I tried acpi_osi=Linux acpi_backlight=vendor with my Asus Zenbook UX31A, and the screen was still stuck blank and black once booting was complete. I also got error messages in dmesg about not being able to parse something: Aug 5 22:26:11 falkor kernel: [ 5.166248] ACPI Error: [IIA0] Namespace lookup failure, AE_ALREADY_EXISTS (20130328/dsfield-211) Aug 5 22:26:11 falkor kernel: [ 5.166255] ACPI Error: Method parse/execution failed [\_SB_.ATKD.WMNB] (Node ffff880118ea1fc8), AE_ALREADY_EXIS TS (20130328/psparse-537) Aug 5 22:26:11 falkor kernel: [ 5.166343] ACPI Error: [IIA0] Namespace lookup failure, AE_ALREADY_EXISTS (20130328/dsfield-211) Aug 5 22:26:11 falkor kernel: [ 5.166346] ACPI Error: Method parse/execution failed [\_SB_.ATKD.WMNB] (Node ffff880118ea1fc8), AE_ALREADY_EXIS TS (20130328/psparse-537) Aug 5 22:26:11 falkor kernel: [ 5.166397] ACPI: Marking method WMNB as Serialized because of AE_ALREADY_EXISTS error Aug 5 22:26:11 falkor kernel: [ 5.196638] asus-nb-wmi: probe of asus-nb-wmi failed with error -5 Aug 5 22:26:11 falkor kernel: [ 5.267636] type=1305 audit(1375755971.086:4): audit_pid=487 old=0 auid=4294967295 ses=4294967295 Aug 5 22:26:11 falkor kernel: [ 5.267636] subj=system_u:system_r:auditd_t:s0 res=1 Also, the line about probe of asus-nb-wmi looks suspicious. I see that with kernel-3.10.4 but not 3.9.5 (I think -- it's a lot of logs to go through)
(In reply to Garrett Mitchener from comment #12) I have the same error on an Asus Zenbook UX32VD but it works with 3.9: with 3.9.9-302 that works and on 3.10.4-300 that don't. I see the problem as 2 issues: 1) Black screen The Black screen start after 1-3s into the kernel boot and it stays black. This also happens without "quiet". This is the main problem. Can it be VT/DRM switch related? 2) Backlight off for some seconds. The backlight goes off for 1-2s and it look like it happens also when X/DM starts. And then it switch off after some time and i can' get it on again. If I login to X on the black screen the backlight level goes back to the 30% level that I have configure in X(fce) and I can adjust the level with the keyboard Fn + F6/F5. it looks like the backlight works in X with xbacklight -set XX. The screen is black the hole time but the backlight is visible the edge of the screen. This was with: pcie_aspm=force drm.vblankoffdelay=1 i915.semaphores=1 acpi_osi='!Windows 2012' I have blacklist nouveau because of switchable “Optimus” technology. Have try with/out:pcie_aspm=force drm.vblankoffdelay=1 i915.semaphores=1 acpi_osi='!Windows\x202012'
I also was affected by this problem, but just upgraded to kernel-3.11.0-0.rc5.git2.1.fc20.x86_64 from rawhide and, so far, it looks as though the problem has been resolved.
(In reply to Hal Finkel from comment #14) > I also was affected by this problem, but just upgraded to > kernel-3.11.0-0.rc5.git2.1.fc20.x86_64 from rawhide and, so far, it looks as > though the problem has been resolved. Unfortunately, while the screen issue still seems solved, I should warn you that it seems that with this prerelease suspend support seems broken (after the machine wakes up from suspend, the wireless card no longer works, the kernel log is full of messages: alx 0000:03:00.0: invalid PHY speed/duplex: 0xffff -- and unloading the ath9k driver then crashes the kernel).
I found the kernel bug that are related to display goes blank: Issue: bw/lanes/clocks required for bpp=24 and then clamps it down to 18 https://bugzilla.kernel.org/show_bug.cgi?id=59841 UEFI: Boot > Launch CSM don't work in secure boot mode on my Asus Zenbook UX32VD:-(. Workaround: Disable secure boot and enable Launch CSM Disable: Boot > Secure Boot and enable: Boot > Launch CSM. And it works: boot 3.10.7-200 with drm.debug=0xe: [ 1.618948] [drm:intel_modeset_stage_output_state], [CONNECTOR:12:eDP-1] to [CRTC:3] [ 1.618962] [drm:intel_modeset_pipe_config], [CRTC:3] [ 1.618963] [drm:intel_modeset_pipe_config], plane bpp: 24, pipe bpp: 24, dithering: 0 I boot 3.10.7-200 with drm.debug=0xe and CSM disabled then the timing match when display goes blank: [ 1.633515] [drm:intel_modeset_stage_output_state], [CONNECTOR:12:eDP-1] to [CRTC:3] [ 1.633516] [drm:intel_modeset_stage_output_state], crtc changed, full mode switch [ 1.633517] [drm:intel_crtc_set_config], attempting to set mode from userspace [ 1.633519] [drm:drm_mode_debug_printmodeline], Modeline 13:"1920x1080" 60 138780 1920 1966 1996 2080 1080 1082 1086 1112 0x48 0xa [ 1.633522] [drm:intel_dp_compute_config], DP link computation with max lane count 2 max bw 0a pixel clock 138780KHz [ 1.633523] [drm:intel_dp_compute_config], DP link bw 06 lane count 2 clock 162000 bpp 18 [ 1.633525] [drm:intel_dp_compute_config], DP link bw required 249804 available 259200 [ 1.633526] [drm:intel_modeset_pipe_config], [CRTC:3] [ 1.633527] [drm:intel_modeset_pipe_config], plane bpp: 24, pipe bpp: 18, dithering: 1
(In reply to Lars S. Jensen from comment #16) > Disable: Boot > Secure Boot and enable: Boot > Launch CSM. > And it works: boot 3.10.7-200 with drm.debug=0xe: This is now OK but I still have the backlight issue 2 from comment #13 with the login manager after the backlight has been turned off: if I wait with the login the the lightdm switch the backlight off after some time and I can't get backlight on again in lightdm. When I login to Xcfe the problem is gone but I may need to login on a black screen if the lightdm have turn off the backlight!
Problem is still present in kernel 3.10.11-200... I see the fedora logo during graphical boot, then the screen goes black. I can then ssh into my notebook (* enable sshd, plug in an ethernet cable first), run systemctl gdm restart, and then the login screen comes up visible.
*********** 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.
Now I checked on 64bit (orginally was on 32bit) and it works for me. Thank you.
Thank you for letting us know.
On my Zenbook 21, the latest update still has the same problem as in Comment #18. Only kernel-3.9.* work...
The bug for Asus Zenbook UX32VD is: https://bugzilla.redhat.com/show_bug.cgi?id=998096 I am updated the bug with the information from Comment #16.
Cautiously optimistic here... I upgraded my Asus Zenbook UX31A to kernel 3.11.1-200, and I haven't seen the black screen problem. FYI: I've disabled secure boot, but it's booting through EFI otherwise.