Xv not work with ColorDepth 16
Created attachment 13519 [details] xorg.conf config file
Created attachment 13520 [details] Xorg.0.log depth 16 log file ColorDepth = 16
Created attachment 13521 [details] Xorg.0.log depth 24 log file ColorDepth = 24
Define "doesn't work" - what happens when you try to use it?
got blue/green screen instead of picture when playing video with xine/gstreamer over Xv with colordepth 16. all seems ok with colordepth 24
Bugzilla Upgrade Mass Bug Change NEEDSINFO state was removed in Bugzilla 3.x, reopening any bugs previously listed as NEEDSINFO. - benjsc fd.o Wrangler
I can't reproduce this with an RV350. Maybe your card needs different treatment for the colour key in depth 16. Just in case though, could you attach (uncompressed please) the output of xrandr when the problem occurs?
Created attachment 13792 [details] xrandr output xf86-video-ati GIT snapshot 2008-01-19 (7238258c12def8ef273e5362f716d165f720c5a5)
I can confirm that 6.7.197-alt11 build would do blue area (mplayer via xv in 16bpp on Radeon Mobility 7000/M6), while 6.6.3-alt5 would work just fine. What info can I provide to help get this regression fixed?
(In reply to comment #9) > I can confirm that 6.7.197-alt11 build would do blue area (mplayer via xv in > 16bpp on Radeon Mobility 7000/M6), while 6.6.3-alt5 would work just fine. > > What info can I provide to help get this regression fixed? > Are you sure this isn't an issue of the overlay ending up on the wrong crtc? Do you have the same problem at both depth 16 and depth 24? Do any of the following commands help? xvattr -a XV_CRTC -v 1 xvattr -a XV_CRTC -v 0
(In reply to comment #10) > > Are you sure this isn't an issue of the overlay ending up on the wrong crtc? That's what I thought, but the attached xrandr output shows only one CRTC enabled. > Do you have the same problem at both depth 16 and depth 24? Depth 24 is fine according to comment #5. Would be great if somebody who can reproduce the problem would try and bisect where it was introduced.
*** Bug 15039 has been marked as a duplicate of this bug. ***
(In reply to comment #11) > Would be great if somebody who can reproduce the problem would try and > bisect where it was introduced. reproduce on cc8e1d95f1b90a259beea4e8cc4d7e29af660919 work on 1de52d91ff3a04b9b587b858e1e5be40d3a7fd0a
xvattr doesn't help at all
My git master from a couple days ago, Radeon Mobility 7500, I tried textured video, and it works at depth16. regular Xv doesn't work at depth 16, i get the blue overlay background. I tried both xvattr commands, both while vlc player stopped, and while video (failed) playing, no change. enabling s-video output, initially sets clone mode, no help. doing xrandr --output S-video --right-of LVDS makes video appear.
(In reply to comment #15) > enabling s-video output, initially sets clone mode, no help. doing xrandr > --output S-video --right-of LVDS makes video appear. > Does that make the video appear initially on S-video or LVDS?
I am running VLC, it's window is on LVDS display, and that's where the video appears.
Does disabling AIGLX or setting Option "VideoKey" "0x01" help? Looks similar to this bug: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/150519
doesn't help
Mass closure: This bug has been untouched for more than six years, and is not obviously still valid. Please reopen this bug or file a new report if you continue to experience issues with current releases.
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.