At higher resolutions greater than 1280x1024 TvTime only shows the top left, it seems to 1280x1024, the rest is blue. If I see Tvtime in small window in the upper left is well, if I put the window in the lower right corner is all blue. The gdm starts with a resolution of 1280x1024, with nv boots to the maximum resolution of monitor, 2048x1536. The screen displayed a line of vertical pixel roses on the right side and a more thin at the bottom. Tvtime does not show any error.
Created attachment 12070 [details] log tvtime -v
Created attachment 12071 [details] log Xorg
Created attachment 12072 [details] dmesg
Created attachment 12073 [details] xorg.conf
Is this still an issue?
Created attachment 13801 [details] log xorg
Tvtime has not changed. The pink lines has disappeared.
Does this happen with mplayer also?
This also does happen with mplayer, output xv.
I think something related got fixed, is this still an issue?
Still the same thing happening with tvtime and mplayer. Also still booting gdm to 1280x1024 Is this normal?
Created attachment 14124 [details] xorg log
It's not the driver's choice what resolution to run, gdm has been known to prefer different resolutions, don't ask me why. You are able to increase to maximum resolution?
Does the blitter adapter work? (check xvinfo for the adapter number) Does this also occur without randr12 enabled?
I can put maximum resolution of 2048x1536 with and without RandR12. I made the following testing with "mplayer -vo xv:port=XXX" "NV Video Overlay" without RandR12 OK "NV Video Blitter" without RandR12 OK "NV Video Overlay" RandR12 only upper left corner. "NV Video Blitter" RandR12 OK Xvinfo with and without RandR12 only change port 105,106 to 134,135.
If you remove the TV capture card from the computer does it work?
I removed the TV card from the computer and continues as before.
I've tracked this down, and found two(ish) fixes. The problem is that currently the video overlay gets clipped to the screen viewport in xf86XVClipVideoHelper(), the viewport having been determined (as "clipBoxes" in DDX parlance) by xf86XVPutStill in the xserver before calling back into NVPutImage and then NV_set_dimensions where xf86XVClipVideoHelper is called. This would all be fine except that xf86XVPutStill uses pScrn->frameX1 and pScrn->frameY1 which are wrong (they don't map well to the randr12 world-view). I'd argue therefore for this being an xserver issue. Unfortunately fixes to the xserver take time, so a driver work-around is required: 1a) do something like pScrn->frameX1 = xf86_config->crtc[pPriv->overlayCRTC]->x + xf86_config->crtc[pPriv->overlayCRTC]->mode.HDisplay - 1; (and similarly for frameY1) when the overlay CRTC is known, to provide a sensible value for clipping 1b) do something like pScrn->frameX1 = pScrn->virtualX - 1; (and similarly for frameY1) to provide a sensible (if large) value for clipping 2) remove the flag VIDEO_CLIP_TO_VIEWPORT from nv_video.c to remove the clipping altogether. Depending how the rest of the code works, this could be a bad move due to excessive bandwidth usage and very-very-large frames being larger than the overlay can handle (an xserver bug ought to be filed once a suitable resolution is found)
Created attachment 16218 [details] [review] A possible fix This replaces the clipping done in the xserver by doing it in the driver. Obviously, dropping VIDEO_CLIP_TO_VIEWPORT altogether (it's already not used in the blitter or texture adapters) would be even simpler...
The patch works correctly in my case. I have other problems that I have to see if they are reported or not yet, but I have noticed that are not caused by this patch. Thank you.
Patch applied
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.