<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW --- - [Intel G45] Screen turns blank when terminating a low res X server on a different low res KMS mode." href="https://bugs.freedesktop.org/show_bug.cgi?id=61457#c10">Comment # 10</a> on <a class="bz_bug_link bz_status_NEW " title="NEW --- - [Intel G45] Screen turns blank when terminating a low res X server on a different low res KMS mode." href="https://bugs.freedesktop.org/show_bug.cgi?id=61457">bug 61457</a> from <a class="email" href="mailto:eich@pdx.freedesktop.org" title="Egbert Eich <eich@pdx.freedesktop.org>"> Egbert Eich</a> <pre>I've played around a bit more - my original workaround seems to work without the not-understood mdelay(9) if I do a: u32 fw_blc_self = I915_READ(FW_BLC_SELF); I915_WRITE(FW_BLC_SELF, fw_blc_self & ~FW_BLC_SELF_EN); before I enable the cursor plane and restore the previous value after I disable it again. If the cursor plane is off already or (fw_blc_self & FW_BLC_SELF_EN) == 0 I don't have to do anything. Of course this is only to the extent I've tested using the described test case and and a limited number of test cycles - since this involves visual inspection if the screen lights up it's hard to automate. I was a bit surprised that it wasn't sufficient to unset the FW_BLC_SELF_EN bit before enabling the display plane and restore the old value after it's enabled but that also the cursor had to be enabled when enabling the display plane.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the QA Contact for the bug.</li> <li>You are the assignee for the bug.</li> </ul> </body> </html>