Bug 15477 - full screen is white when use compiz
full screen is white when use compiz
Status: VERIFIED FIXED
Product: DRI
Classification: Unclassified
Component: General
DRI git
x86 (IA32) Linux (All)
: medium normal
Assigned To: Default DRI bug account
:
: 16444 16821 (view as bug list)
Depends on:
Blocks: mesa-7.1
  Show dependency treegraph
 
Reported: 2008-04-12 20:21 UTC by WuNian
Modified: 2008-10-12 19:15 UTC (History)
5 users (show)

See Also:
i915 platform:
i915 features:


Attachments
xorg log file (20.50 KB, text/plain)
2008-04-12 20:21 UTC, WuNian
no flags Details
X log from non-working configuration (31.64 KB, text/plain)
2008-04-15 07:23 UTC, Ben Gamari
no flags Details
glxinfo output (7.05 KB, text/plain)
2008-04-15 07:39 UTC, Ben Gamari
no flags Details
proposed patch.. please test this. (1.06 KB, patch)
2008-07-09 01:40 UTC, Dave Airlie
no flags Details | Splinter Review
alternate patch fixing this from the other side (2.55 KB, patch)
2008-07-09 02:30 UTC, Dave Airlie
no flags Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description WuNian 2008-04-12 20:21:04 UTC
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.
Comment 1 Ben Gamari 2008-04-12 21:26:02 UTC
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.
Comment 2 WuNian 2008-04-13 17:57:33 UTC
(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.

Comment 3 Ben Gamari 2008-04-14 08:27:08 UTC
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.
> 

Comment 4 Ben Gamari 2008-04-14 08:35:47 UTC
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.
Comment 5 Michel Dänzer 2008-04-14 09:34:19 UTC
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?
Comment 6 Ben Gamari 2008-04-14 11:40:49 UTC
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.
Comment 7 Ben Gamari 2008-04-14 13:39:00 UTC
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?
Comment 8 WuNian 2008-04-14 18:49:42 UTC
(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.

Comment 9 Michel Dänzer 2008-04-15 01:37:48 UTC
(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.
Comment 10 Ben Gamari 2008-04-15 07:23:08 UTC
Created attachment 15926 [details]
X log from non-working configuration
Comment 11 Ben Gamari 2008-04-15 07:27:31 UTC
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.
> 

Comment 12 Michel Dänzer 2008-04-15 07:32:38 UTC
(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.
Comment 13 Ben Gamari 2008-04-15 07:39:54 UTC
Created attachment 15927 [details]
glxinfo output
Comment 14 Ben Gamari 2008-04-15 07:41:11 UTC
(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.

Comment 15 Johannes Engel 2008-04-15 08:02:23 UTC
That log looks good to me, at least my one looks pretty similar. And at the moment I do not expect that behaviour.
Comment 16 Ben Gamari 2008-04-15 08:36:11 UTC
(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?
Comment 17 Ben Gamari 2008-04-22 08:50:12 UTC
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.
Comment 18 Michel Dänzer 2008-04-22 09:29:57 UTC
GLX_EXT_texture_from_pixmap being advertised without LIBGL_ALWAYS_INDIRECT=1 with DRI1 is definitely a bug and a regression.
Comment 19 Ben Gamari 2008-04-22 10:32:32 UTC
Oh, uhhhh, ooops. Really sorry about that, I apparently am talking out of my a**. My bad. 
Comment 20 Michel Dänzer 2008-06-27 03:06:13 UTC
*** Bug 16444 has been marked as a duplicate of this bug. ***
Comment 21 Timo Aaltonen 2008-07-02 02:38:52 UTC
Still a bug with mesa master. Ubuntu Intrepid will soon be updated to the latest packages, so hopefully this bug gets some attention.
Comment 22 Timo Jyrinki 2008-07-09 00:46:41 UTC
(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).
Comment 23 Dave Airlie 2008-07-09 01:40:16 UTC
Created attachment 17597 [details] [review]
proposed patch.. please test this.
Comment 24 Dave Airlie 2008-07-09 02:30:06 UTC
Created attachment 17600 [details] [review]
alternate patch fixing this from the other side

I'll let krh pick which one is more correct.
Comment 25 Timo Aaltonen 2008-07-09 03:05:06 UTC
At least the first patch works, thanks!
Comment 26 Kristian Høgsberg 2008-07-09 08:51:25 UTC
(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.
Comment 27 Dave Airlie 2008-07-13 02:01:48 UTC
I've pushed the second fix to glx/dri code. 
Comment 28 Bryce Harrington 2008-07-15 05:19:28 UTC
Thanks, we've confirmed and pulled this fix into Ubuntu.
Comment 29 Gordon Jin 2008-07-24 20:40:34 UTC
*** Bug 16821 has been marked as a duplicate of this bug. ***