When compiz is tried to be enabled, only a black screen is shown. Restoring to metacity works. OpenGL works in some other cases, but not with compiz. Used components: - xserver git - intel ddx git - drm git - mesa git DRI_MM is being used. This has been confirmed by Maxim Levitsky too now on the xorg mailing list: http://lists.freedesktop.org/archives/xorg/2008-February/032776.html As an additional information, if I _don't_ have TTM working, I get a screen of semi-random colored noise instead of the black screen I get with the TTM.
After removing bogus whitelist code and then removing the not-so-bogus blacklist code from the debian package, I can confirm this result.
I can confirm this using latest drm/mesa/xserver/intel driver (from batchbuffer branch) git, with both DRI and DRI2.
Seeing this as well on a G35 system using either master or batchbuffer branch.
Turns out it's not exactly a black screen after all. If I hold ctrl-alt-left-mouse-button and roll around, the cube rotates. While all four sides of the cube are complete black, the cube reflection shows up along the bottom of the screen. Also the freedesktop.org logo shows up on the top of the cube. The speed of the rotation is good, there doesn't appear to be a performance problem. Maybe this suggests a particular kind of breakage which points to a solution?
I can reproduce this issue on our G965 as well.
and with XAA, it's kind of working(wobbling, cube desktop, rotate). but the xterm window is blank.
Has there been any progress on this bug? I think bug #15577 might be a DUP.
*** Bug 15577 has been marked as a duplicate of this bug. ***
Does disabling the assignment pDRIInfo->texOffsetStart = I830TexOffsetStart; in xf86-video-intel/src/i830_dri.c fix the problem? If so, it seems that the corresponding code in the Mesa driver needs to be fixed or disabled for 965.
Wow, looks like that does it. The texture_from_pixmap demo in mesa seems to produce output when that line (and the if statement directly above it) is disabled. I haven't been able to test compiz yet due to visual issues, unfortunately. (In reply to comment #9) > Does disabling the assignment > > pDRIInfo->texOffsetStart = I830TexOffsetStart; > > in xf86-video-intel/src/i830_dri.c fix the problem? If so, it seems that the > corresponding code in the Mesa driver needs to be fixed or disabled for 965. >
Michel, Thanks for finding the source of the problem. Commenting out that line makes the tfp demo and Compiz work here.
You are presently running compiz with xserver/mesa git? Have you experienced any symptoms of bug #15641? I haven't been able to get compiz to even start. - Ben (In reply to comment #11) > Michel, > > Thanks for finding the source of the problem. Commenting out that line makes > the tfp demo and Compiz work here. >
(In reply to comment #12) There were a few FBConfig problems recently which i helped create, but they seem to be resolved now. FWIW, i'm running xserver/mesa/drm/xf86-video-intel from Git.
When was this? Any particular commits?
(In reply to comment #14) Sorry don't know particular commits. The issue was caused by some commits by Kristian in the last couple of weeks but appears fixed as Compiz with LIBGL_ALWAYS_INDIRECT=1 now works here. Probably it's not related to the problem you're seeing.
With latest git master, this issue still exists.
In the latest revision this particular bug seems fixed. Still some mess with a flat white cube on the desktop faces using direct rendering though. Life is difficult without wobbly windows.
(In reply to comment #17) > In the latest revision this particular bug seems fixed. Still some mess with a > flat white cube on the desktop faces using direct rendering though. Life is > difficult without wobbly windows. > Amen to the last statement. Are you running on a 64-bit environment? Are you experiencing #15641? Thanks.
Oh, I was following 15577 and didn't look at the title here... I am really on i915. Not sure what bug to post to now since there seem to be many open issues related to the one I was having. My machine is 32 bit. Also, right now I am using the default X (X.org 11.0) and drm with my distro. The driver is listed as "Mesa DRI Intel(R) 945GM 20061102 x86/MMX/SSE2". Mesa is current from git. Some change in the mesa git in the last 3 days got my compiz working so be I run with indirect rendering. In an earlier git I was seeing a black screen that didn't spin, I would sometimes also see a white screen with random garbage which eventually seemed to switch to solid black. My system would only lock up (go unresponsive) on a black screen when direct rendering was active in compiz with whichever mesa is packaged in the fedora 9 prerelease. Now with direct rendering I just get that empty cube with the fedora "f" graphics on the top and bottom. In unrelated news, interestingly, the drm git "died" on my system today. It was running compiz earlier for a few hours before the display froze and everything went unresponsive. Now on startup X with drm git kills my system after a few flickers. I'll wait a few days and post a bug if I still see this as I do not have time to check if there is already one open. (In reply to comment #18) > (In reply to comment #17) > > In the latest revision this particular bug seems fixed. Still some mess with a > > flat white cube on the desktop faces using direct rendering though. Life is > > difficult without wobbly windows. > > > > Amen to the last statement. Are you running on a 64-bit environment? Are you > experiencing #15641? Thanks. > (In reply to comment #18) > (In reply to comment #17) > > In the latest revision this particular bug seems fixed. Still some mess with a > > flat white cube on the desktop faces using direct rendering though. Life is > > difficult without wobbly windows. > > > > Amen to the last statement. Are you running on a 64-bit environment? Are you > experiencing #15641? Thanks. >
This bug definitely still exists in git. However, the fix mentioned in Comment #9 still fixes it. Something should be checked in soon if the change needs to be made in mesa. Release is pretty soon I think.
Does commenting pDRIInfo->texOffsetStart = I830TexOffsetStart; in i830_dri.c fix it for all others? For me it does not seem to help. Changed a machine, though, this one is a laptop with GMA X3100. And nowadays it's white screen, or like corrected afterwards white cube / desktop (I can turn it around). drm / libdrm git, mesa git ("7.1rc1"), intel git, ttm enabled. However, xserver 1.4.1 this time since I couldn't get my xserver 1.5-branch git to actually run (socket failures / problems, I'll try to get it running though again later). Other OpenGL stuff works more or less, like Flight Gear, if I just first replace compiz wm with metacity after logging in (compiz enabled by default).
Yep, it helps for me (I'm running compiz presently). Are you sure you're running with indirect rendering? Sounds like similar symptoms. Make sure that LIBGL_ALWAYS_INDIRECT is set (I've made that mistake more than a few times) and maybe also pass --indirect-rendering to compiz just for good measure. I'm also on a laptop with X3100. Should be similar silicon (right?) (In reply to comment #21) > Does commenting pDRIInfo->texOffsetStart = I830TexOffsetStart; in i830_dri.c > fix it for all others? For me it does not seem to help. Changed a machine, > though, this one is a laptop with GMA X3100. And nowadays it's white screen, or > like corrected afterwards white cube / desktop (I can turn it around). > > drm / libdrm git, mesa git ("7.1rc1"), intel git, ttm enabled. However, xserver > 1.4.1 this time since I couldn't get my xserver 1.5-branch git to actually run > (socket failures / problems, I'll try to get it running though again later). > Other OpenGL stuff works more or less, like Flight Gear, if I just first > replace compiz wm with metacity after logging in (compiz enabled by default). >
(In reply to comment #22) > Yep, it helps for me (I'm running compiz presently). Are you sure you're > running with indirect rendering? You're right. Now running compiz with mesa git trunk succesfully, and indeed with the mentioned line commented out in i830_dri.c. I also got my xserver 1.5 running, though the keyboard settings are a mystery to me.
Would anyone have information on whether the comment 9:s fix/workaround is "correct" and doesn't cause any side effects for any users? Distributions would probably want Intel + Compiz to work.
(In reply to comment #24) > Would anyone have information on whether the comment 9:s fix/workaround is > "correct" and doesn't cause any side effects for any users? The workaround disables zero-copy texture-from-pixmap with all 3D drivers. If the corresponding support in the i965 driver can't be fixed, it would be much better to just disable that instead. > Distributions would probably want Intel + Compiz to work. Sure, which is why I made this a blocker for Mesa 7.1. :) Not sure how much longer Brian is holding out though.
Created attachment 17877 [details] [review] patch on top of current mesa... please try this out.. I haven't tested it on real hw, its just guess work until I get to a 965 machine.
Created attachment 17878 [details] [review] try 2.. fail on the first attempt.
Created attachment 17885 [details] try 3 - now with 100% less fail okay lets go again.
patch checked into mesa master.
(In reply to comment #29) > patch checked into mesa master. > Thanks very much for working on this and committing a fix. Unfortunately with latest Git xserver/mesa/intel my system locks up hard when compiz starts. Perhaps it's unrelated to this fix. I hope to get a chance to look at it further in the next few days. Hopefully others will report back if this patch works for them too.
Sorry for the delay in testing, but it's working well now here. Thanks!
Mass version move, cvs -> git
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.