My TV Tuner is displaying some odd "glitches"; little bits of the screen that seem to be corrupt. Some form of memory corruption or other. Its not just tearing. The link below has some pictures, but I can make some more if you like. Also, (this is very weird), the problem will go away if I slam my CPUs with extra work to do. The easiest way to do this is run Handbrake and let it encode a video. Luckily this takes awhile on my slow CPU, but to watch TV, I have to keep restarting a handbrake job for the video output to be readable. I originally thought this was a tvtime bug, and then a v4l bug, but it goes away if I install the ATI/AMD binary (fglrx) drivers. However, that isn't a good option for me since getting those drivers to work with recent kernels and gnome 3.16 is nearly impossible. Since the fglrx drivers doesn't have the problem, I will assume its a driver issue. My older bug report to tvtime with the pictures is here: https://sourceforge.net/p/tvtime/bugs/747/ Any chance there is some magic configuration to fix it? I have a laptop with integrated APU AMD A8-4555M APU with Radeon(tm) HD Graphics which is 00:01.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Trinity [Radeon HD 7600G] TV Tuner is Hauppage ... Bus 001 Device 004: ID 2040:7217 Hauppauge Dual monitor set-up with laptop screen at ... eDP connected primary 1366x768+1920+535 and other monitor is HDMI-0 connected 1920x1080+0+0 Problem exists on either screen or with HDMI unplugged
One more thing. Look closely at the pictures (from two different applications, so its not an app issue), but the "glitch" is that a section of the output is a horizontal mirror of what it should be. I'm thinking some sort of race condition where the TV Tuner and something else are hitting memory at once? I don't know enough about how it all works. But the position of the glitch changes about once per second, sometimes goes away for 2-3 seconds, nothing consistent. Some sort of race/collision, and making the CPUs busy seems to hold it at bay.
It could be USB, I recently started using a DC fanless, headless, intel baytrail board as my home router/pvr/nas box and it has a similar issue. Of course you issue may be quite different given fglrx seems to help - but then it may just manage to keep the cpu out of lower power states while working. I don't know tvtime at all - I assume you are watching digital TV, if so it would be really handy if it does/could log continuity counter errors. If you see those then they would explain the issue. I use tvheadend - it does log cc errors so I know that for me xhci usb is loosing the odd packet at a low but enough to be annoying level. I do have a thread on linux-usb and eventually may find something useful, but I found a 99% workaround anyway = don't use xhci! On my box I turned off USB3 in bios, which makes the kernel use the ehci driver which fixes my normal use cases but I can still provoke with extreme testing (2x 40mbit DVB-T2 muxes). If you are into doing your own Kernels some h/w will get xhci for usb3 ports and ehci for USB2 ports if you build just xhci as a module. Saying all that I don't know your hardware and it may all be irrelevant. Perhaps you could try some ways to see if the glitches are data loss related - See if tvtime can be made verbose to log continuity counter errors or log the output of the mpeg decoder. Maybe install tvheadend, record something and look in eg. /var/log/daemon.log for errors. Install mplayer or mpv, run from an xterm/console/whatever and watch TV - both by default will print the mpeg errors (if any) that result from missing data.
Please attach your xorg log and dmesg output.
Created attachment 117096 [details] Xorg.log
Created attachment 117097 [details] dmesg
@Andy, I know USB3 controllers and Linux don't quite get along (in fact you'll see my name in the kernel as a tester on this issue). To mitigate this possibility, I plug the tuner into the USB2-only port on the other side of the laptop. So, both ehci and xhci are both used. I can't turn off USB3 support in this BIOS. tvtime is one of the few remaining "analog" TV apps that don't require recording to the hard drive just to watch TV, although I believe the project is abandoned at the moment. There is no DVB at work here and this no mpeg encoder (unless hauppage encodes it just to send it over the USB bus, and I doubt it). The screen shots show that the data is there, just reversed. And data loss would be expected on a busy system, and I get the problem at idle, under multitasking, with both performance and ondemand cpu governors. Its only a good hard thrashing by Handbrake that seems to stop the problem, and it stops it completely (without any dropped frames that I can see). Mplayer doesn't seem to want to play that device. And vlc has changed the interface and I can't seem to get the new one to play the device, but like I said, its all analog.
Created attachment 117100 [details] v4l-info output
What does tvtime use to render the frame? Xv? X11? VDPAU? something else? It could be differences in the APIs exposed by the different drivers.
Note that VLC showed the same problem, so it isn't tvtime specific. Here is what tvtime documentation states about output: tvtime outputs video into a video overlay surface, an area of video memory outside of the framebuffer, using the XVIDEO X extension. Applications which take screenshots such as ksnapshot, gimp or xwd only see the colourkeyed window, and not output of tvtime. So, it would seem "XV"
At least on the tvtime screenshot, the data is shifted horizontally, not reversed.
You may be correct. Which makes more sense as it just means a pointer somewhere got moved (either software or some register), but the fact that only part of the image is shifted is what's weird. You would think that the right edge would be part of the shifted pixels. I'm thinking that this is some sort of race condition, and perhaps an issue with someone not honoring a lock? It almost looks like something disrupts the address where it is reading or writing the data, and then it gets fixed mid-operation. I would say its a hardware problem, but moving to fglrx fixed for me for the longest time and now using those drivers is no longer an option.
-- 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/133.
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.