Version: unspecified (using KDE 4.6.0) OS: Linux starting mplayer and switching to fullscreen and switching back to window mode freezes X for a few seconds and the mplayer window forever until it's killed (the mplayer window ) but only when its started the first time - starting a second mplayer session and doing the same doesnt reproduce the error until X is restarted - then it happens again when mplayer is started - this bug also happend in kde 4.5 but it was gone in the beta versions of kde 4.6 it is for shure related to kwin and kde as the bug doesnt happen in fluxbox... i also have this message in xorg.0.log [ 6837.589] nvLock: client timed out, taking the lock btw - i use the bin nvidia drivers Reproducible: Always Steps to Reproduce: 1.) start X11 2.) start mplayer 3.) switch to fullscreen mode 4.) switch back to window mode 6.) X freezes a few seconds & the mplayer window forever Expected Results: no freeze at all
> i also have this message in xorg.0.log > [ 6837.589] nvLock: client timed out, taking the lock > btw - i use the bin nvidia drivers I would not be so sure about it being KWin's fault. Looks more like related to NVIDIA...
- i assume you do unredirect fullscreen windows? - does it happen with the XRender backend? - what are your settings for the GL backend - does it happen with all effects turned off - is it limited to mplayer of is xine/vlc affected as well? - what mplayer "-vo"? does it happen with others as well? - if it's the xv backend (and esp. "and only"): what are your xvideo settings in nvidia-settings? - nvidia driver version? (it obviously does not happen here)
- i assume you do unredirect fullscreen windows? what does this mean? - what are your settings for the GL backend - i use opengl it doesnt happen with all effects turned off i dont have vlc or any other video player installed i use x11-drivers/nvidia-drivers-260.19.29 but it also happens with x11-drivers/nvidia-drivers-270.18 - what mplayer "-vo"? -vo vdpau - it happens with every codec - not only with the hw accelerated codecs but only when vdpau enabled ...
(In reply to comment #3) > - i assume you do unredirect fullscreen windows? > what does this mean? there's a a little checkbox that says "suspend compositing for fullscreen windows" - is it checked? > - i use opengl errr.. i meant whether diret or indirect rendering, vsync, scale method, texture from pixmap or shm - such things, but: > it doesnt happen with all effects turned off so there's culprit. try to figure which effect causes this in particular. (just to be sure: "all effects off" != "no compositing at all"!) -vo vdpau - it happens with every codec - not only with > the hw accelerated codecs but only when vdpau enabled ... well, and finally it's probably nvidias fault then ;-) i guess there's a issue on re-assigning the shaders when switching between vdpau & gl contexts - nevertheless you should figure which effect in particular is involved (lilkely one of the shader users, like blur or so)
there's a a little checkbox that says "suspend compositing for fullscreen windows" - is it checked? - yes it was - after i unchecked it, it seems the freeze is gone :) thanks
this does NOT mean the issue is somehow "fixed". redirecting has a significant performance impact, therefore it's avoided for fullscreen windows by default. you should report the bug to nvidia (there's probably an issue with switching contexts while VDPAU is in use)