On Monday 27 May 2002 8:22 pm, Michael scribed numinously:" > On Sun, May 26, 2002 at 06:50:11PM +0100, Tim Smith wrote: > > The tcl-0-0-branch really doesn't like 2D menus being popped up over > > the 3D drawing area; it locks up after a few of these with or without > > RADEON_NO_TCL and with or without page flipping enabled. Following > > Michel's suggestion I've captured logs for three occurrences of this > > happening and put them at > > What 2d menus? From a window manager or in the app itself? I committed a > patch yesterday that fixed crashes with overlapping / moving / resizing > 3d windows. If you got the tree before then you might not have it.
I do have your patch (I've just doublechecked and it doesn't fix this particular problem). The 2d menus are in the app itself; It's a windows application running under WINE, so it's drawing its own rectangles in the "windows" style. Further digging indicates the lockup is easiest to produce by opening a context menu over an object in the 3d view, moving the mouse pointer down the menu until a submenu appears and then moving the mouse pointer away so the submenu should be removed. It is the removal that generates the lockup. I've done some more digging and it would appear to send an enormous amount of commands via radeon_cp_cmdbuf, all ending up going via radeon_emit_packet3_cliprect. Actually I don't think it's such a huge number compared to other calls (32 commands), except that this time the loop gets called with nbox=4 so it emits everything 4 times, and runs out of FIFO. Inserting a call to radeon_do_wait_for_idle() right at the top of the do loop in radeon_emit_packet3_cliprect() prevents the lockup. The application leaves a blank rectangle behind when the submenu goes away, which doesn't get redrawn until the original context menu goes away, but that's probably the application's (or WINE's) fault. This is almost certainly the wrong solution to the problem, however, given my limited understanding of the code at this time. According to the traces I've looked at, this is the first time in the life of the app that anything got called with nbox > 1 though. If I'm correct about the problem it could appear in other cases. Now I appear to be running foul of the assert() in radeonVtxfmtUnbindContext() in xc/xc/lib/GL/mesa/src/drv/radeon/radeon_vtxfmt.c. That only occurs when I open a genuinely new window (e.g. by selecting "properties" off the aforementioned context menu). I don't recall ever trying to do that before with this driver because the context menus always locked the machine before, so I'm not sure if I've introduced it myself or not. Seems unlikely though. I'll have a trawl through after that one tomorrow. -- Tim Smith ([EMAIL PROTECTED]) "A fray!!!!" -- Groo the Wanderer _______________________________________________________________ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
