<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - Stuttering video playback in totem after update to 1.19-rc1" href="https://bugs.freedesktop.org/show_bug.cgi?id=98030#c3">Comment # 3</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - Stuttering video playback in totem after update to 1.19-rc1" href="https://bugs.freedesktop.org/show_bug.cgi?id=98030">bug 98030</a> from <a class="email" href="mailto:mario.kleiner@tuebingen.mpg.de" title="Mario Kleiner <mario.kleiner@tuebingen.mpg.de>"> Mario Kleiner</a> <pre>Ok, i think this is related: On 1.19-rc1 (current git master) under DRI2, windowed OpenGL apps like glxgears get stuck unless i press keys on the keyboard or move the mouse to create input events. KDE Plasma 5, being OpenGL driven afaik, has the same problem. If otoh i run applications which use fullscreen kms page-flipped windows, e.g., Gnome shell, or regular fullscreen GL apps, they work fine under DRI2. If i use DRI3/Present everything works fine. This both with a server built to use the new input-threads and also built without input-threads. This happens at least on nouveau-ddx and ati/amdgpu-ddx. I just retested glxgears, my own app and totem under gdb, and without me providing mouse/keyboard input, they all get stuck in the DRI2GetBuffersWithFormat request to the X-Server, waiting for a reply. That gets called when Mesa needs new renderbuffers for a new frame after a swapbuffers request, e.g., when glxgears or totem calls glClear(). So far so bad. So something gets stuck in the servers dispatch loop, but "external" input events from the kernel (evdev, kms-pageflip completion events?) gets it unstuck?</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>