| Summary: | xf86-video-intel-2.99.912 with dri3 enabled breaks gnome-shell | ||
|---|---|---|---|
| Product: | Mesa | Reporter: | Hans de Goede <jwrdegoede> |
| Component: | Drivers/DRI/i965 | Assignee: | Ian Romanick <idr> |
| Status: | RESOLVED FIXED | QA Contact: | Intel 3D Bugs Mailing List <intel-3d-bugs> |
| Severity: | normal | ||
| Priority: | medium | CC: | arik.kfir, frederic.romagne, jana, pochu27, vladimir.didenko |
| Version: | 10.1 | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: | Xorg.1.log | ||
Confirm problem on Alt Linux. That log file seems to be garbage (some binary data?). (In reply to comment #2) > That log file seems to be garbage (some binary data?). Log is archived by gzip. You can download it to your machine and unzip. OK seems like mannerov has found the cause: --- (#xorg-devel) --- <mannerov> Jasper: Is it possible to launch gnome-shell in a Window ? <Jasper> mannerov, no <mannerov> Jasper: is there some other programs using cogl, that I could test ? <mannerov> I found that cogl has code to handle GLX_INTEL_swap_event, so perhaps the problem is raised there <drago01> mannerov: tests shipped with clutter, cogl and gnome-shell or one of the clutter-gst apps (like totem) <mannerov> drago01: thanks. totem has the bug <mannerov> keithp, Jasper: I can have the bug with totem under dri2 with LIBGL_ALWAYS_INDIRECT <mannerov> keithp: So I suppose the complete event (sent by the server for dri2 indirect, or dri3) is not received correctly by cogl <mannerov> whereas it is received correctly when Mesa sends the event <mannerov> (dri2 direct) <drago01> mannerov: which bug btw? <Jasper> mannerov, if no event will be sent, the server shouldn't advertise the extension <mannerov> the event is sent <mannerov> but looks like the client doesn't receive/handle it <mannerov> drago01: no refresh <mannerov> blocked after the first frame <mannerov> Jasper: there's a piglit test on the extension, and it passes correctly with both dri2 and dri3 <mannerov> but the events are handled differently in the piglit test <drago01> mannerov: so (sorry no scrollback) the screen "hangs" when using dri3 or dri2 indirect but works with dri2 direct? <mannerov> yes <mannerov> the application does one swap, and then nothing <mannerov> but works if GLX_INTEL_swap_event is not advertised <drago01> ok so maybe that's what hansg hit https://bugs.freedesktop.org/show_bug.cgi?id=79985 <mannerov> yes, this is this bug ---- Basically GLX_INTEL_swap_event is broken on DRI3 (and DRI2 indirect) which causes mutter to wait for the event which never arrives for some reason and thus it hangs. But apparently it works for piglit ... FYI: I just enabled DRI3 again with the latest snapshot, xorg-server-1.16 final and Mesa 10.2.4 and tadaa... it's now working for me. Now, if this is accidental, on purpose or why... I don't know. (In reply to comment #5) > FYI: I just enabled DRI3 again with the latest snapshot, xorg-server-1.16 > final and Mesa 10.2.4 and tadaa... it's now working for me. > > Now, if this is accidental, on purpose or why... I don't know. Ah, I had all forgotten about this bug sorry. This turned out to be an issue in mesa, and this has been fied in mesa upstream, closing. |
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.
Created attachment 100980 [details] Xorg.1.log While preparing 1.15.99.903 server + 2.99.912 intel drv packages for Fedora 21, I noticed that both gdm and gnome-shell (tested with startx) hang, they show the initial background screen and then just sit there. Building the server with --disable-dri3, or building the intel drv with a hacked configure.ac to make it not build with dri3 support fixes this. I'm using mesa 10.2.1, which has been build with xgl-dri3 support, I've double checked this. Chris Wilson thinks this is a mesa bug, hence this bug. I'm attaching an Xorg.log from a run with xf86-video-intel build with --debug=full. Note I switched away from the vt and killed Xorg (and thus the hanging startx session) before saving the log, so that is part of the log too.