| Summary: | Switching between VESA fb console and X leaves blank screen | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | xorg | Reporter: | Helge Bahmann <helge.bahmann> | ||||||||
| Component: | Driver/intel | Assignee: | 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: | git | Keywords: | NEEDINFO | ||||||||
| Hardware: | x86 (IA32) | ||||||||||
| OS: | Linux (All) | ||||||||||
| Whiteboard: | |||||||||||
| i915 platform: | i915 features: | ||||||||||
| Attachments: |
|
||||||||||
|
Description
Helge Bahmann
2009-01-16 06:46:00 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 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.