Bug 844985
Summary: | ASUS Zenbook UX31E: internal LCD is not enabled if external HDMI connected at boot | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Nick Coghlan <ncoghlan> | ||||||
Component: | kernel | Assignee: | Kernel Maintainer List <kernel-maint> | ||||||
Status: | CLOSED UPSTREAM | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||
Severity: | unspecified | Docs Contact: | |||||||
Priority: | unspecified | ||||||||
Version: | 17 | CC: | airlied, gansalmon, itamar, jonathan, kernel-maint, madhu.chinakonda | ||||||
Target Milestone: | --- | ||||||||
Target Release: | --- | ||||||||
Hardware: | Unspecified | ||||||||
OS: | Unspecified | ||||||||
Whiteboard: | |||||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||||
Doc Text: | Story Points: | --- | |||||||
Clone Of: | Environment: | ||||||||
Last Closed: | 2012-08-14 12:17:32 UTC | Type: | Bug | ||||||
Regression: | --- | Mount Type: | --- | ||||||
Documentation: | --- | CRM: | |||||||
Verified Versions: | Category: | --- | |||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||
Embargoed: | |||||||||
Attachments: |
|
Description
Nick Coghlan
2012-08-01 12:05:47 UTC
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. |