Created attachment 15865 [details] xorg log file Platform: G945 I updated all components to tip: Drm - db61f02bd7e4b9d5ac416f1ef98bac1bd4d984bc Mesa - 32134b5508495fbb1d9fc2f844e22fbb082dcda6 Xserver - b1f3f42840ec01db417345a0740b59ad5e4471cb intel driver - 21783ec9dfad9aae0837fd2d8eb313a77f031046 xf86-video-intel-2.3-branch Then I start up "Xorg" by typing "startx &", the full screen is white, only mouse can be seen and I can move the mouse. If I kill Xorg by pressing "ALT-CTRL-BACKSPACE", I can see the normal desktop flashed away. I uses Ubuntu7.10 which use compiz by default. If I used metacity as window manager, everything is OK. I used compiz that Ubuntu 7.10 provided at first, then I update compiz to tip (6122474bf51a62ea392f7f49ddc8b8e4252652a5), but the bug still exist.
Hey, if you start compiz in a terminal, you may see "failed to create drawable" messages. If this is the case, you are experiencing the same issue I am, which I described in "CreateDrawable failing with old DRI" on the xorg mailing list. I have been unable to isolate the underlying cause of this and have yet to hear back from Kristian or the list. Superficially, it looked like mesa commit 23635510e3333ea8056311afa741c5e6d7c9ec15 might fix the issue, but no such luck.
(In reply to comment #1) > Hey, if you start compiz in a terminal, you may see "failed to create drawable" I can see this message too and the screen is black. > messages. If this is the case, you are experiencing the same issue I am, which > I described in "CreateDrawable failing with old DRI" on the xorg mailing list. > I have been unable to isolate the underlying cause of this and have yet to hear > back from Kristian or the list. Superficially, it looked like mesa commit > 23635510e3333ea8056311afa741c5e6d7c9ec15 might fix the issue, but no such luck. Yes, The commit does not work for me.
Are you using the intel-batchbuffer branch? I seem to recall getting a black screen and similar (but not identical) messages when DRI2 was in use. (In reply to comment #2) > (In reply to comment #1) > > Hey, if you start compiz in a terminal, you may see "failed to create drawable" > > I can see this message too and the screen is black. > > > messages. If this is the case, you are experiencing the same issue I am, which > > I described in "CreateDrawable failing with old DRI" on the xorg mailing list. > > I have been unable to isolate the underlying cause of this and have yet to hear > > back from Kristian or the list. Superficially, it looked like mesa commit > > 23635510e3333ea8056311afa741c5e6d7c9ec15 might fix the issue, but no such luck. > Yes, The commit does not work for me. >
This message appears in mesa's glx_pbuffer.c and was introduced by Kristian's commit e82dd8c6e1fa2fff5b960de26961080ba5e9651d (DRI interface changes and DRI2 direct rendering support). It appears to be thrown because drawable != req->glxwindow (glx_pbuffer.c:366) when that comparison in driCreateDrawable (dri_glx.c:1088) failed. The comparison is apparently checking for "GLX 1.3+ drawable constructors," which the old DRI can't handle. Unfortunately, the glxwindow and drawable somehow aren't being initialized with similar values, hence the failing check. Hope this saves someone a little work.
Is compiz trying to use direct rendering? That has never worked with the 'old' DRI. Does it work if you set LIBGL_ALWAYS_INDIRECT=1?
You're absolutely right, that was the issue (at least why the screen was white). I had set that in my .bashrc which I recently deleted. Setting LIBGL_ALWAYS_INDIRECT gives a black screen and more or less freezes X (Ctrl+C doesn't kill compiz, switching to a VT and killing locks up the machine, expectedly). More details in an hour when I get out of class and find a machine to remote in from.
I am thoroughly confused. It seems that over indirect rendering compiz runs fine but fails to map any windows (they are black). Strangely, it gives no errors, however. The cube plugin works as expected (end-caps, background and all) so it seems the issue is probably in texture-from-pixmap or the related machinery. I'm honestly at a loss as to how to approach this problem. As I said before, compiz produces nothing evenly slightly resembling an error. After initializing, gdb verified that compiz is sitting in its event loop which is further supported by the fact that compiz behaves as it should, albeit with a black desktop. I have no problem looking into this problem deeper, but I need some input as to where the bug could be occurring or how to localize it further. Any ideas?
(In reply to comment #5) > Is compiz trying to use direct rendering? That has never worked with the 'old' > DRI. Does it work if you set LIBGL_ALWAYS_INDIRECT=1? I set LIBGL_ALWAYS_INDIRECT=1, then startx, desktop is up and display is correct, but the windows has no window manager(no title bar, no border), although the compiz is running: root@nian-dev:~# ps -ef |grep compiz root 6303 6241 0 09:42 pts/0 00:00:00 /usr/bin/compiz --sm-client-id default0 root 6455 6205 0 09:43 pts/0 00:00:00 grep compiz I use the master branch of xf86-video-intel.
(In reply to comment #7) > It seems that over indirect rendering compiz runs fine So, I suspect that GLX_EXT_texture_from_pixmap is incorrectly being advertised with DRI1. > but fails to map any windows (they are black). Is AIGLX fully initialized? (In reply to comment #8) > I set LIBGL_ALWAYS_INDIRECT=1, then startx, desktop is up and display is > correct, but the windows has no window manager(no title bar, no border), > although the compiz is running: You probably aren't loading the decoration plugin and/or a decoration manager.
Created attachment 15926 [details] X log from non-working configuration
I (In reply to comment #9) > (In reply to comment #7) > > It seems that over indirect rendering compiz runs fine > > So, I suspect that GLX_EXT_texture_from_pixmap is incorrectly being advertised > with DRI1. Interesting. glxinfo lists it, server glx extensions: GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_copy_sub_buffer, Perhaps this is one of the issues. > > > but fails to map any windows (they are black). > > Is AIGLX fully initialized? > I just attached a log. Quote: (II) AIGLX: Screen 0 is not DRI2 capable drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 10, (OK) drmOpenByBusid: Searching for BusID pci:0000:00:02.0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 10, (OK) drmOpenByBusid: drmOpenMinor returns 10 drmOpenByBusid: drmGetBusid reports pci:0000:00:02.0 (II) AIGLX: enabled GLX_MESA_copy_sub_buffer (II) AIGLX: enabled GLX_SGI_swap_control and GLX_MESA_swap_control (II) AIGLX: enabled GLX_texture_from_pixmap with driver support (II) AIGLX: Loaded and initialized /usr/lib/dri/i965_dri.so Am I correct in assuming that is AIGLX not supposed to be enabling texture_from_pixmap? > (In reply to comment #8) > > I set LIBGL_ALWAYS_INDIRECT=1, then startx, desktop is up and display is > > correct, but the windows has no window manager(no title bar, no border), > > although the compiz is running: > > You probably aren't loading the decoration plugin and/or a decoration manager. >
(In reply to comment #11) > > So, I suspect that GLX_EXT_texture_from_pixmap is incorrectly being advertised > > with DRI1. > > Interesting. glxinfo lists it, > server glx extensions: > GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_texture_from_pixmap, It's expected to be listed in the server and client extensions. What matters is the 'GLX extensions:' string. > (II) AIGLX: enabled GLX_texture_from_pixmap with driver support > (II) AIGLX: Loaded and initialized /usr/lib/dri/i965_dri.so > > Am I correct in assuming that is AIGLX not supposed to be enabling > texture_from_pixmap? No, it's supported with indirect rendering.
Created attachment 15927 [details] glxinfo output
(In reply to comment #12) > It's expected to be listed in the server and client extensions. What matters is > the 'GLX extensions:' string. Just attached the output of glxinfo and it appears to be listed in the GLX extensions string as well. Interesting. > > No, it's supported with indirect rendering. > Alright.
That log looks good to me, at least my one looks pretty similar. And at the moment I do not expect that behaviour.
(In reply to comment #15) > That log looks good to me, at least my one looks pretty similar. And at the > moment I do not expect that behaviour. > Well, this is most unfortunate. Kristian, any suggestions as how to approach isolating this issue? Do you know of any likely failure points that wouldn't throw an error?
It seems as though the only issue here was that indirect rendering wasn't being used. Marking NOTABUG. There is another bug concerning actual breakage of texture_from_pixmap (which was the problem I was referring to) at #14441.
GLX_EXT_texture_from_pixmap being advertised without LIBGL_ALWAYS_INDIRECT=1 with DRI1 is definitely a bug and a regression.
Oh, uhhhh, ooops. Really sorry about that, I apparently am talking out of my a**. My bad.
*** Bug 16444 has been marked as a duplicate of this bug. ***
Still a bug with mesa master. Ubuntu Intrepid will soon be updated to the latest packages, so hopefully this bug gets some attention.
(In reply to comment #21) > Still a bug with mesa master. Ubuntu Intrepid will soon be updated to the > latest packages, so hopefully this bug gets some attention. Now updated. People are seeing white (this bug), corruption (bug 14441) and black (bug 14441 for advanced users who have additionally self-compiled TTM support).
Created attachment 17597 [details] [review] proposed patch.. please test this.
Created attachment 17600 [details] [review] alternate patch fixing this from the other side I'll let krh pick which one is more correct.
At least the first patch works, thanks!
(In reply to comment #23) > Created an attachment (id=17597) [details] > proposed patch.. please test this. Yeah, this one cool - in fact, I think we should apply both, they both make sense.
I've pushed the second fix to glx/dri code.
Thanks, we've confirmed and pulled this fix into Ubuntu.
*** Bug 16821 has been marked as a duplicate of this bug. ***
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.