[Bug 98030] Stuttering video playback in totem after update to 1.19-rc1

[bugzilla-daemon-CC+yJ3UmIYqDUpFQwHEjaQ@public.gmane.org]

[-- Attachment #1.1: Type: text/plain, Size: 1375 bytes --]

https://bugs.freedesktop.org/show_bug.cgi?id=98030

--- Comment #3 from Mario Kleiner <mario.kleiner-TdbV1Z3I5XE0NhjG498hmQ@public.gmane.org> ---
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?

-- 
You are receiving this mail because:
You are the assignee for the bug.

[-- Attachment #1.2: Type: text/html, Size: 2175 bytes --]

[-- Attachment #2: Type: text/plain, Size: 154 bytes --]

_______________________________________________
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau