Description of problem: If an external HDMI monitor is connected while booting the ASUS Zenbook UX31E, the internal LCD monitor is not enabled, preventing use in dual screen mode until the device is rebooted without the HDMI monitor connected. Version-Release number of selected component (if applicable): kernel-3.4.6-2.fc17.x86_64 How reproducible: Always Steps to Reproduce: 1. Connect external monitor to HDMI port with the Zenbook powered off 2. Switch on the Zenbook 3. BIOS splash screen and disk decryption prompt are displayed on external monitor 4. Enter disk decryption password Actual results: Internal LCD screen (eDP1) remains deactivated even though xrandr considers two monitors to be available (eDP1 and HDMI) Content configured for display on eDP1 is not visible at all "Identify outputs" in KDE dual monitor settings displays both the eDP1 and HDMI labels on the HDMI monitor. The eDP1 label appears to be in roughly the right position for a 1600x900 display anchored to the top left of the 1920x1080 external HDMI display Expected results: Internal LCD screen is reactivated during the boot process (either before or after disk decryption). Content configured for display on eDP1 is visible on the internal monitor "Identify outputs" displays the eDP1 label on the internal monitor and the HDMI label on the external monitor Additional info: It all works fine if the HDMI monitor is left unplugged until after the disk decryption prompt has been displayed. The external monitor then remains blank until later in the boot process (presumably whenever X starts up the dual monitor support). I previously had TrueCrypt + Windows on this machine. With that configuration, when booting with the HDMI connected, the TrueCrypt prompt would display on the external monitor and then Windows (presumably via an ASUS supplied driver) would do something to reactivate the internal monitor while completing the boot process. My current theory is that something in the firmware is switching the "internal" output over to the external monitor during boot, which the OS is then expected to explicitly switch back. I've gone looking for a setting in the BIOS to try and tell it to ignore the HDMI while booting, but haven't seen anything that seems even remotely related.
After tinkering a bit more, it looks like this isn't a boot-specific problem. If I use the Fn+F8 button combination to switch the laptop between internal-only, external-only and internal+external, the "turn off the internal screen" aspect of the "external-only" setting is a one way trip: once the laptop enters external-only, the internal screen is never powered back on, no matter how many times I hit the Fn+F8 button. That makes a certain amount of sense, since it would help explain why hitting Fn+F8 doesn't help recover the internal monitor after the laptop switches to external-only during the boot process.
I was able to show the misbehaviour to Dave Airlie, and he discovered a workaround: forcing the internal monitor to a different mode reactivates it, and it then remains active when switching back to the original mode. For example (starting with the internal monitor deactivated), this works: xrandr --output eDP1 --mode 1024x768 xrandr --output eDP1 --auto But this does not: xrandr --output eDP1 --off xrandr --output eDP1 --auto He also noted that when the internal monitor was deactivated xrandr still reported that it was switched on (displaying a "*" against the configured resolution)
OK, I've done some more investigation and it seems that, while the two problems (monitor disable at boot, monitor not switching back when Fn+F8) give similar symptoms from a user point of view, they're not actually be the same. When I showed this to Dave we were using the Fn+F8 method, and the workaround effectively dealt with that problem. However, I've since had a closer look at the "connected at boot" problem and in that case, it turns out that the internal display doesn't show up as a monitor *at all*. I'm attaching two "xrandr --verbose" outputs, one showing the output when the HDMI monitor was connected before booting the machine (eDP1 missing) and one where I didn't connect it until afterwards (eDP1 present).
Created attachment 604268 [details] xrandr --verbose, eDP1 missing
Created attachment 604269 [details] xrandr --verbose, eDP1 found
I tried poking around at some of same things Dave was looking at today and came up with this (the starred one looks rather suspicious!): # dmesg | grep drm [ 1.284336] [drm] Initialized drm 1.1.0 20060810 [ 1.371256] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [ 1.371257] [drm] Driver supports precise vblank timestamp query. *[ 1.372701] [drm] bad panel power sequencing delays, disabling panel [ 1.501167] [drm] Enabling RC6 states: RC6 on, RC6p off, RC6pp off [ 1.722827] fbcon: inteldrmfb (fb0) is primary device [ 2.013090] fb0: inteldrmfb frame buffer device [ 2.013092] drm: registered panic notifier [ 2.025119] [drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0 Which then leads me to: https://bugs.freedesktop.org/show_bug.cgi?id=48652 Progress of a sort... I'll reboot to check the driver messages in the "good" case, but I suspect this will hitting CLOSED UPSTREAM pretty soon
And, as expected, no power sequencing problems if the HDMI is connected *after* boot (connected while sitting at the LUKS prompt, to be precise): # dmesg | grep drm [ 1.284105] [drm] Initialized drm 1.1.0 20060810 [ 1.378045] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [ 1.378048] [drm] Driver supports precise vblank timestamp query. [ 2.606788] [drm] Enabling RC6 states: RC6 on, RC6p off, RC6pp off [ 2.882398] fbcon: inteldrmfb (fb0) is primary device [ 3.945828] fb0: inteldrmfb frame buffer device [ 3.945829] drm: registered panic notifier [ 3.956569] [drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0 There's still the matter of the Fn+F8 misbehaviour, though.
Turns out the Fn+F8 misbehaviour is also being discussed in that upstream bug, so it makes more sense to continue any further investigation over there.