Bug 19603

Summary: Switching between VESA fb console and X leaves blank screen
Product: xorg Reporter: Helge Bahmann <helge.bahmann>
Component: Driver/intelAssignee: Jesse Barnes <jbarnes>
Status: RESOLVED FIXED QA Contact: Xorg Project Team <xorg-team>
Severity: normal    
Priority: medium CC: helge.bahmann, marcus, michael.fu, zahlberer, zhenyu.z.wang
Version: gitKeywords: NEEDINFO
Hardware: x86 (IA32)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
Vesa mode switch
none
ensure known state at RestoreHW and EnterVT time
none
create known state, preserve pipe a force quirk none

Description Helge Bahmann 2009-01-16 06:46:00 UTC
Created attachment 22031 [details] [review]
Vesa mode switch

Using driver from git, tag xf86-video-intel-2.5.99.2

When using (U)VESA fb, switching between the X server and the frame buffer console back and forth is broken on several 855GM-based laptops (tested with Thinkpads X40 and T60). Switching back and forth results in a blank screen in console, X server or both.

According to my (naive) investigation, the core of the problem is that VESA uses Pipe B/Plane B to drive the screen, while the X server uses Pipe A/Plane B. The driver neglects to deactivate Pipe B used by VESA before setting up its own hardware state, and neglects to deactivate Pipe A before restoring the original state. (This also results in the message "tried to update DSPARB with both planes enabled" being generated).

The attached patch fixes the problem for me in all cases by forcefully deactivating all left-over pipes and planes.

Note: QUIRK_PIPEA_FORCE is active on these laptop models, however I have not been able to produce any ill effects by actually disabling pipe A.
Comment 1 Gordon Jin 2009-01-18 01:41:30 UTC
Not sure if this relates to bug#19578.
Comment 2 Helge Bahmann 2009-01-18 23:51:38 UTC
I don't think bug#19578 is related, for me display remains blank no matter if we use XAA nor EXA (didn't try UXA), and it is 855GM.

But this one may be related: bug#18032
Comment 3 Michael Fu 2009-01-23 18:40:55 UTC
I don't think we claim support co-exist of vesafb with our driver... this is also listed at http://intellinuxgraphics.org/how_to_report_bug.html
Comment 4 Helge Bahmann 2009-01-25 00:44:15 UTC
I understand that peaceful coexistence with VESA is not an intended goal (though it worked with driver versions up to 2.2 in all instances we could test, though probably by accident) -- would you nevertheless consider a change like the one proposed if it does not have any ill effects?

My understanding of the hardware is obviously very limited, but I think that the current behaviour of silently relying on a specific pre-existing hardware state is rather brittle and unnecessary.
Comment 5 Matthias Weidle 2009-01-26 03:04:23 UTC
(In reply to comment #3)
> I don't think we claim support co-exist of vesafb with our driver... this is
> also listed at http://intellinuxgraphics.org/how_to_report_bug.html
> 

Please consider reading the comments in bug #14481, especially the comments #7 and following.

I really do hope that it's possible to solve that issue as it was possible before, given that a patch was already suggested to fix it.
Comment 6 Jesse Barnes 2009-01-26 10:27:02 UTC
Yeah we really should support interacting with vesafb... Something like your patch might be a good way to do it.
Comment 7 Jesse Barnes 2009-01-26 10:28:29 UTC
*** Bug 18032 has been marked as a duplicate of this bug. ***
Comment 8 Jesse Barnes 2009-01-28 15:04:42 UTC
Created attachment 22330 [details] [review]
ensure known state at RestoreHW and EnterVT time

Does this patch also work?  I'd rather share code with i830_display if possible (since the DPMS code should be almost exactly what we need).
Comment 9 Helge Bahmann 2009-02-06 04:40:21 UTC
Thanks Jesse, I believe your patch works as well. While I am pretty certain I had exactly once found an instance where I still ended up with a blank screen, I have been unable to reproduce it a second time -- so even if there is a problem still it is very elusive. Unless I manage to reproduce it again I think I can consider it fixed.
Comment 10 Michael Fu 2009-02-06 06:22:53 UTC
reopen for Jesse to commit the patch, if everything is ok.
Comment 11 Jesse Barnes 2009-02-06 09:17:42 UTC
Yeah, thanks for testing, Helge.  But don't close it too soon or I'll forget to actually commit the code. :)
Comment 12 Jesse Barnes 2009-03-16 11:32:59 UTC
Created attachment 23926 [details] [review]
create known state, preserve pipe a force quirk

My last patch had a bug in the pipe a quirk that Zhenyu caught.  Can you retest with this one so I can push?  Thanks.
Comment 13 Helge Bahmann 2009-03-18 00:47:51 UTC
Yes, this also works. Note that on all of the machines originally affected, the VESA mode setting code actually disables pipe A, contrary to what the X driver does -- I wonder what this careful stepping around pipe A actually does on those systems?
Comment 14 Jesse Barnes 2009-03-18 09:30:34 UTC
It was originally intended to handle platforms where the BIOS code touched the graphics hardware at suspend/resume time, or at other times (e.g. during a output switch, lid event, or AC power event).  It's probably still necessary, but this known state patch is a good fix for the competing graphics drivers case (e.g. vesafb vs xf86-video-intel).
Comment 15 Jesse Barnes 2009-03-18 09:41:03 UTC
Fix pushed:

commit 6deb26ae7bd796e88a5dd90df5f6c35fbc44e798
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date:   Wed Mar 18 09:36:58 2009 -0700

    Create known output configuration at EnterVT time

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.