Created attachment 37194 [details] backtrace from wine app After this commit was introduced, all 3D apps running through Wine hangs on start. This happens with both r300c and r300g, softpipe doesn't seem to be affected, but maybe it doesn't use dri2? commit 3750ebd540510324ef5ada769537ae05309adadb Author: Kristian Høgsberg <krh@bitplanet.net> Date: Mon Jul 19 09:37:07 2010 -0400 glx: Fix drawable lookup in DRI2 event handler DRI2 events are sent to the X drawable ID used to create the DRI2 drawable, not the GLX drawable ID. So when an event comes in, we need to look up the __GLXDRIdrawable by its X drawable ID, which needs a new hash table. I'm also attaching a backtrace frome one such app hanging. System environment: -- system architecture: 32-bit -- Linux distribution: Debian unstable -- GPU: RV570 -- Model: Asus EAX1950Pro 256MB -- Display connector: DVI -- xf86-video-ati: cdeb1949c820242f05a8897d3ddd0718f204dacf -- xserver: 1.8.99.904 (1.9.0 RC 4) -- mesa: 3750ebd540510324ef5ada769537ae05309adadb -- drm: 6ea2bda5f5ec8f27359760ce580fdad3df0464df -- kernel: 2.6.35-rc5
A related regression is this one, the game Far Cry (running through Wine) starts but hangs at level start if the below commit isn't reverted. f8d81c31cee30821da3aab331a57f484f6a07a5d is the first bad commit commit f8d81c31cee30821da3aab331a57f484f6a07a5d Author: Nick Bowler <nbowler@draconx.ca> Date: Wed Jul 14 12:01:49 2010 -0400 dri2: Track event mask in client code. When direct rendering is being used, DRI2 BufferSwapComplete events are sent unconditionally to clients, even if they haven't been requested. This causes error messages to be printed by every freeglut application of the form freeglut (./gears): Unknown X event type: 104 and might confuse other clients. This is a fixed up version of the patch by Jesse Barnes, which drops BufferSwapComplete events if they are not requested by clients. Fixes fdo bug 27962. Signed-off-by: Nick Bowler <nbowler@draconx.ca> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> :040000 040000 43b22479000d40e4034e467746bda73544d1ef4f a7c81f4433d420249b67bee1a16bc047a45141a0 M src
The first issue should be fixed by commit 037755122e9011c768e5caa4d4cb83aba783d3e9 Author: Kristian Høgsberg <krh@bitplanet.net> Date: Mon Jul 19 21:00:09 2010 -0400 glx: Don't use __glXInitialize() when we might be holding __glXLock() in mesa master. If the second issue is still present in master, please file another bug report.
Thanks! The first issue is indeed fixed now. I filed bug 29170 for the other one.
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.