Bug 74381

Summary:	ASUS T100TA panel video cannot be reenabled after it is disabled
Product:	Drivers	Reporter:	Robert R. Howell (rhowell)
Component:	Video(DRI - Intel)	Assignee:	Daniel Vetter (daniel)
Status:	RESOLVED DUPLICATE
Severity:	normal	CC:	adamw, intel-gfx-bugs, jacek.m.danecki
Priority:	P1
Hardware:	x86-64
OS:	Linux
Kernel Version:	3.15.0_rc1	Subsystem:
Regression:	Yes	Bisected commit-id:

Description Robert R. Howell 2014-04-18 06:08:15 UTC

Starting approximately with the merge of the new i915 code into the 3.15 kernel about April 8, the panel video on my ASUS T100A cannot be renabled once it has been disabled, until the system is rebooted.

The panel display and an external HDMI display come up properly on boot, but if I do anything to turn off the panel display, such as "xrandr --output VGA1 --off", then nothing I do after that is able to make the panel display visible till I reboot.  After an "xrandr --output VGA1 --auto" the system seems to THINK the panel is active, as indicated by xrandr output and also the implied limits of the display when moving windows and the mouse from one display to the other, but there just isn't any visible panel output.  The HDMI is fine.  I don't see any error messages in any of the logs.  The system really acts like some part of the video output chain has been disabled, but never gets reenabled till a reboot.

Running the 3.14 kernel and versions of the partly merged 3.15 kernel before approximately April 8, I am able to turn off then turn on the panel.  For your information, I've compiled this as x86_64, am using the video=VGA-1:1368x768e parameter at boot, and also specify an edid file I created, as the display is otherwise scrambled.

Comment 1 Robert R. Howell 2014-04-20 06:10:34 UTC

As discussed more in my comment #45 under the related Bug 68451, <https://bugzilla.kernel.org/show_bug.cgi?id=68451> I've tested a new kernel using patches which Intel and Jani Nikula have just made available.  Those patches appear to resolve most of the above problems, although there still seem to be a few glitches in the new code.

Comment 2 Jani Nikula 2014-04-24 10:20:36 UTC

The DSI displays work by accident, after having been enabled by the firmware, and we won't have proper support for them until 3.16. That it no longer "works" in 3.15 is not surprising to me, since we don't test or support that it keeps working by accident.

Possibly the fastest way to determine whether we can easily do something about it for 3.15 would be to do a bisect. It's definitely too late to merge DSI enabling for 3.15.

Comment 3 Adam Williamson 2014-04-24 19:21:12 UTC

Just to confirm this is affecting the Venue 8 Pro too - once the display blanks under X (due to idle timeout, or a system suspend, or anything else) it never wakes up again. Worked fine throughout 3.14 cycle. Doesn't happen unless X is running - if you boot to runlevel 3 and let the screen go idle, it wakes up fine when you hit a key.

I do my kernel builds as modified Fedora packages so I'm not really set up brilliantly to do a bisect, but if no-one else has the time I can give it a shot...

Comment 4 Adam Williamson 2014-04-28 20:36:13 UTC

I think the fact that X fails to start correctly if I boot with Fedora 'graphical boot' enabled is the same bug as this, and it's also the same bug that if I try to manipulate the screen with xrandr at all, the display dies.

When booting with 'graphical boot' (rhgb parameter) - both in broken (3.15) and working (3.14) cases - there's this extra bit in the logs during X startup:

Apr 24 14:49:31 fedlet.happyassassin.net gdm-Xorg-:0[875]: (II) intel(0): resizing framebuffer to 800x1280
Apr 24 14:49:31 fedlet.happyassassin.net gdm-Xorg-:0[875]: (II) intel(0): switch to mode 800x1280@60.0 on pipe 0 using VGA1, position (0, 0), rotation normal

presumably the framebuffer is set to something else during graphical boot (which would explain why the graphical boot sequence is always corrupted), and X realizes it has to reset it. When booting without rhgb, this doesn't happen. The second operation there looks like an RandR operation.

So it looks like both waking from blank (or blanking itself, hard to tell which) and any kind of RandR mode change operation make the display stop working (go black).

Comment 5 Daniel Vetter 2014-05-11 17:45:09 UTC

I've upgraded the original bug as regression so that we can de-dupe this.

*** This bug has been marked as a duplicate of bug 68451 ***

Comment 6 Jani Nikula 2014-05-12 07:19:35 UTC

(In reply to Daniel Vetter from comment #5)
> I've upgraded the original bug as regression so that we can de-dupe this.
> 
> *** This bug has been marked as a duplicate of bug 68451 ***

As you wish, but that one will be fixed by us actually enabling DSI upstream. This one will still be busted in 3.15 after that, and the fix or workaround or whatever will be different.