Bug 29156

Summary: [regression] 3D apps in Wine hangs on start
Product: Mesa Reporter: Sven Arvidsson <sa>
Component: Drivers/DRI/r300Assignee: Default DRI bug account <dri-devel>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: medium CC: nbowler
Version: git   
Hardware: Other   
OS: All   
Whiteboard:
i915 platform: i915 features:
Attachments: backtrace from wine app

Description Sven Arvidsson 2010-07-19 16:25:54 UTC
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
Comment 1 Sven Arvidsson 2010-07-19 16:51:04 UTC
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
Comment 2 Nick Bowler 2010-07-19 20:47:48 UTC
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.
Comment 3 Sven Arvidsson 2010-07-20 06:05:40 UTC
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.