Summary: | [RADEON:KMS:R600C:DDX] screen not refreshed after full-screen mplayer playback. | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | xorg | Reporter: | Pawel Sikora <pawel_sikora> | ||||||||||
Component: | Driver/Radeon | Assignee: | xf86-video-ati maintainers <xorg-driver-ati> | ||||||||||
Status: | RESOLVED FIXED | QA Contact: | Xorg Project Team <xorg-team> | ||||||||||
Severity: | normal | ||||||||||||
Priority: | medium | CC: | bugs.xorg, oldium.pro | ||||||||||
Version: | unspecified | ||||||||||||
Hardware: | x86-64 (AMD64) | ||||||||||||
OS: | Linux (All) | ||||||||||||
Whiteboard: | |||||||||||||
i915 platform: | i915 features: | ||||||||||||
Attachments: |
|
Description
Pawel Sikora
2011-01-23 04:20:04 UTC
Created attachment 42330 [details]
desktop after mplayer window->fullscreen->window cycle.
Created attachment 42331 [details]
desktop after additional mplayer window moves.
I don't know if it is related, but I have simillar problem with fullscreen updating. Everything works with desktop effects switched off. When I enable desktop effects (using KDE 4.6 RC2), I can see fullscreen updating problem (see below). I have two screens (LVDS, HDMI), ATI Mobility Radeon HD 3470, Gentoo linux, xorg-server-1.9.3.901-r1, mesa Git master, libdrm Git master, xf86-video-ati Git master, kernel branch drm-radeon-testing. I'm using Gallium driver. When I move fullscreened mplayer to second screen (it just fully changes the screen where it is rendered, not that it is partly shown on both screens), the second screen doesn't show the video, it just freezes updating. Alt-Tab forward and back helps. When returning back from fullscreen, the window gets to the first screen (where it was originally windowed) and the second screen gets black - only the freshly updated components (clock for example) shows-up. Now the effect is the same as the bug described. This used to work better when I last tried it (long time ago) - the fullscreened mplayer content was correctly visible when moved across screens, but the bug after changing from fullscreen to windowed mode was there too. Note: I'm moving the windows with Alt+right mouse button as a customized shortcut to move windows. (In reply to comment #3) > I have two screens (LVDS, HDMI), ATI Mobility Radeon HD 3470, Gentoo linux, > xorg-server-1.9.3.901-r1, mesa Git master, libdrm Git master, xf86-video-ati > Git master, kernel branch drm-radeon-testing. I'm using Gallium driver. hmmm, i can't reproduce desktop refresh problems on single screen configuration with aiglx kde effects enabled. it looks like a dual screen setup is required to expose problem. How big is your dualscreen setup? Mesa had a limits of 4096 pixels for textures until recently. Do you still have problems if you disable vblank? run your compositor with vblank_mode=0? If you start the GL app on one head, then migrate to another, it's likely still waiting for vblanks on the other head. (In reply to comment #5) > How big is your dualscreen setup? Mesa had a limits of 4096 pixels for > textures until recently. at this moment i have a 1600x1050 lcd connected via analog dsub and 1920x1080 tv connected via dvi<->hdmi cable. i've a plan to connect 1600x1050 lcd with digital cable in few days... > Do you still have problems if you disable vblank? > run your compositor with vblank_mode=0? could you please translate this to the average-kde-user language? :) in kde 'desktop effects' i have a 'compositing type' set to opengl, 'opengl mode' set to 'texture from pixmap, 'enable direct rendering' set to yes and 'use vsync' turned off. (In reply to comment #6) > (In reply to comment #5) > > Do you still have problems if you disable vblank? > > run your compositor with vblank_mode=0? > > could you please translate this to the average-kde-user language? :) This means to start mplayer from command line with `vlank_mode=0 mplayer test.avi`. Or there is an option vblank_mode in .drirc, but the driver should be set to "dri2" for KMS. Just use the command line option. I've tried to run fullscreen mplayer with vblank_mode=0, but it didn't make any difference. I'm suffering from the same problem, also using a dualscreen setup here. Disabling vsync doesn't make any difference. Is there anything else we could try out? I'm curious, is nobody else using dualscreen experiencing this? Any news? Btw., this also affects gallium/r600g (using mesa/ddx/libdrm from git). I can also reproduce this with fullscreen in digikam. Please see attachment. Btw., could this be a problem with kwin? Created attachment 50207 [details]
desktop after returning from fullscreen in digikam
If page flipping is enabled and kwin configured to unredirect fullscreen windows, this might be fixed with current xf86-video-ati Git. If not, please attach Xorg.0.log. Created attachment 50211 [details]
Xorg.0.log
Looks like it didn't work for me :[
So if I understand correctly, this only happens if * More than one monitor is enabled * Compositing is enabled in kwin Correct? If so, does it also happen with kwin compositing set to use XRender instead of OpenGL? (In reply to comment #14) > So if I understand correctly, this only happens if > > * More than one monitor is enabled > * Compositing is enabled in kwin > Correct? If 3D effects are disabled, screen is refreshed correctly after fullscreen. > > If so, does it also happen with kwin compositing set to use XRender instead of > OpenGL? Xrender makes no difference. (In reply to comment #15) > > If so, does it also happen with kwin compositing set to use XRender instead of > > OpenGL? > Xrender makes no difference. Then it seems more likely that the problem is with kwin or maybe the core X server than with the radeon driver. FYI i tested fullscreen video in XFCE-4.8.1 and wasn't able to reproduce the issue with compositing enabled. So to me it looks like a kwin+dualhead problem. Closing, please open a bug against kwin in proper bugzilla. But i guess you can also first check if newer kwin,ddx,mesa helps |
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.