Steps to reproduce this bug: Boot a system with two monitors connected using HDMI & DVI on an HD6770 card. Run a dual head setup in xorg without using composition (xrandr output below). At this point vsync in xv works on both monitors. Disable the HDMI monitor by xrandr --output HDMI-0 --off. Xvideos on the DVI monitor are now not vsynced. Reenable the HDMI with xrandr --output HDMI-0 --auto --output DVI-1 --auto --right-of HDMI-0. After that xv vsync doesn't work on any of the monitors. xvattr show XV_VSYNC is 1. After an unknown amount of time vsync will start working again. It takes a few hours like leaving it over night. I usually disable the HDMI monitor because I'm unplugging it. After unplugging it an error message will show up in syslog: [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder is 216 Raw EDID: 00 ff ff ff ff ff ff 00 1e 6d 57 56 59 a6 00 00 01 12 01 03 80 34 20 78 ea 5a d5 a7 56 4b 9b 24 13 50 54 a5 4b 00 a9 40 81 8f b3 00 81 4f 81 80 01 01 01 01 01 01 28 3c 80 a0 70 b0 23 40 30 20 36 00 b0 44 11 00 00 1a 48 3f 40 30 62 b0 32 40 40 c1 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [drm:radeon_dvi_detect] *ERROR* HDMI-A-1: probed a monitor but no|invalid EDID I don't know if this error is related to the vsync problem but they started at about the same time. Unplugging the monitor is not required for the vsync problem. Looking at timestamps in syslog I upgraded xf86-video-ati from 7.0.0 to 7.1.0 and the kernel from 3.7.5 to 3.8.0 a few days before the first EDID checksum is invalid message. I should bisect but bisecting the DDX is a pita. xorg.conf only got a section with Identifier "ATI" Driver "radeon" Option "ColorTiling" "true" Option "ColorTiling2D" "true" Option "SwapbuffersWait" "false" Option "EnablePageFlip" "true" Screen 0: minimum 320 x 200, current 3600 x 1200, maximum 8192 x 8192 DisplayPort-0 disconnected (normal left inverted right x axis y axis) HDMI-0 connected 1920x1200+0+0 (normal left inverted right x axis y axis) 432mm x 324mm 1920x1200 60.0*+ 1920x1080 50.0 60.0 50.0 1920x1080i 25.0 30.0 1600x1200 60.0 1680x1050 59.9 1280x1024 75.0 60.0 1280x960 75.0 1280x720 50.0 60.0 1024x768 75.1 60.0 800x600 75.0 60.3 720x576 50.0 720x480 59.9 59.9 640x480 75.0 60.0 59.9 720x400 70.1 DVI-0 disconnected (normal left inverted right x axis y axis) DVI-1 connected 1680x1050+1920+0 (normal left inverted right x axis y axis) 434mm x 270mm 1680x1050 60.0*+ 1280x1024 75.0 60.0 1280x960 60.0 1152x864 75.0 1024x768 75.1 60.0 832x624 74.6 800x600 75.0 60.3 56.2 640x480 75.0 60.0 720x400 70.1
Please attach your xorg log and dmesg output.
Are you using a compositing manager? If yes, does it use OpenGL?
Created attachment 79313 [details] dmesg, Xorg.log I'm using kwin but compositing is off.
> xvattr show XV_VSYNC is 1. How about XV_CRTC?
XV_CRTC is set to -1 before and after disabling. Turns out this might be a problem with the player. Mplayer and Xine show tearing after disabling monitors but vlc does not. Using vlc even fix the problem in the other players without having to wait a few hours. All players are set to use the xv extension of course. I tried downgrading various components without any success. Even with kernel-3.6.0 libdrm-2.4.40 mesa-9.0.1 xorg-server-1.12.4 xf86-video-ati-6.14.6 the problem still occurred. Whatever cause this problem to appear a few months ago probably wasn't a change in the graphics code. I also tried to login to fluxbox instead of kde but the problem existed there to.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/driver/xf86-video-ati/issues/65.
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.