This clean repost of Bug 48652, as was requested by Jani Nikula. Short summary: - reproducible with current drm-intel-nightly.git f7def439e21ca 14.03.2015 - affected hardware: Asus Zenbook ux31a Vendor: 0x8086, Device: 0x0166, Revision: 0x09 (??) render clock: unknown sampler clock: unknown - if external VGA is attached, internal eDP will stay blank. - known workaround: switch from VGA to eDP in grub or BIOS - it is not possible to configure BIOS to use eDP as default output.
Created attachment 114306 [details] dmesg - no vga is attached.
Created attachment 114307 [details] dmesg - vga attached + switched to eDP in grub.
Created attachment 114308 [details] dmesg - vga attached This is actual bug + some more problems probably depending on this bug. In this case only VGA is working. eDP is blank with enabled backlight. X recognized two enabled outputs, but hanged after login.
*** Bug 48652 has been marked as a duplicate of this bug. ***
I appears we haven't had a clue, but we may have inadvertently fixed this anyway. Does the problem persist with latest kernels?
Still same issue, may be even worse...
Can we get a set fresh dmesgs from latest drm-intel-nightly with drm.debug=0xe please (from all three scenarios)? Also a copy of /sys/kernel/debug/dri/0/i915_opregion would be good to have here.
I didn't hadright now acassable VGA display, so i used HDMI port wich has same issue.
Created attachment 123166 [details] dmesg - no hdmi is attached.
Created attachment 123167 [details] dmesg - hdmi attached
Created attachment 123168 [details] dmesg - hdmi attached + switched to eDP in grub.
Created attachment 123169 [details] i915_opregion - no hdmi is attached.
Created attachment 123170 [details] i915_opregion - hdmi attached
Created attachment 123171 [details] i915_opregion - hdmi attached + switched to eDP in grub.
Created attachment 123724 [details] [review] [PATCH]
We don't have too many details in this report about the symptom, so it's a bit hard to know what was happening. But unless I totally misread that earlier bug report, the problem gets fixed after a modeset? If so, the patch I just attached might do something. In the bad case the BIOS left VDD on, and we never turn it off prior to enabling the eDP port. That does make sense since it's a good way to avoid the power cycled delay during boot, but in this case perhaps the panel is confused and we have to power it down first.
Hi suddenly this patch not fixing the problem. I can workaround this problem by switching the screen in the grub (using Fn+F8), or by using Win7.. After linux kernel started Fn+F8 is not working any more.
I found one more workaround: After Linux is started (i used the kernel with "force edp vdd off at boot" patch), go to suspend S3 and then wake it. After this both screen work normal.
Oleksij - I'm sorry about this long lead time until getting back to you. Does the problem persist with latest kernels?
Hi, i just gave this device to other people. So i can't test it any more :( Any way, thank you for your work!
(In reply to Oleksij Rempel from comment #20) > Hi, > > i just gave this device to other people. So i can't test it any more :( > > Any way, thank you for your work! Thanks Oleksij Rempel, then assuming that it is fixed by now. In case it is occurring again, use lastest kernel and don't hesitate to re-open it with new logs.
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.