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.
Not sure if this relates to bug#19578.
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
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
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.
(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.
Yeah we really should support interacting with vesafb... Something like your patch might be a good way to do it.
*** Bug 18032 has been marked as a duplicate of this bug. ***
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).
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.
reopen for Jesse to commit the patch, if everything is ok.
Yeah, thanks for testing, Helge. But don't close it too soon or I'll forget to actually commit the code. :)
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.
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?
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).
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.