TM5600 USB video grabber
This page explains how the Trident TM5600 chipset works in Linux, in particular with the following product that embeds it: KÖNIG CMP-USBVG6 (bought here 30€).
First of all, Trident seems to be well known for refusing to help coding free drivers and even disclosing information about the chipsets, so that's a good reason not to buy it in the first place.
The driver supporting this chipset is tm6000. The kernel doesn't know the device in particular, but recognizes the chipset: tm6000: Found Generic tm5600 board.
Warnings from the kernel "xc2028 2-0061: Error: firmware xc3028-v24.fw not found" must not be fixed as explained on the XC2028 page, because it crashes the driver, or at least it makes the device not work, I don't know why.
The image is not completely stable (it moves up and down a bit), but I don't know how stable is the source being tested in the first place and it is probably acceptable for guiding. There is a green line at the bottom of the image. Supported video standards are NTSC (720x480) and PAL (720x576), supported image formats are YUYV and UYVY. Care has to be taken in programs to select the correct standard with the correct definition.
Grabbing video works fine, but not always. You plug the USB, you run "mplayer tv://" and you have the video feed, it's as simple as that if your kernel was compiled with CONFIG_VIDEO_TM6000 (distribution's kernels are). With mplayer displaying the feed, it takes 20% of user space CPU on an AMD64 2GHz.
Grabbing problems and solutions
However, in some cases, it doesn't works fine, one frame on two is not obtained right from the driver. The SVV V4L2 application, Mplayer and Unicap generally get a correct image. GoQat's V4L2 mode (<= 1.0.0), Qastrocam-g2 (not always?) and open-phd-guiding seem to have a buffer problem in V4L2 mmap mode grabbing, and the image flickers.
This issue has been tracked down to a driver's issue AND to misbehaving V4L2 software. The driver issue is that polling the device always indicates that there is a frame ready in the buffer while when asking for buffer dequeue, the request fails with a not-ready image error. In that case, looping on the DQBUF ioctl while it returns a not-ready state crashes the driver. What has to be done is wait for a frame to be actually ready, by sleeping before retry, or doing something else. SVV has been fixed for this particular issue, making it working fine all the time: File:svv.c.
On the userland side, the issue was that some software take too long to process the image and when they query the buffer, another frame has been partially written over the ready-frame. This is clearly a driver bug too, but V4L2 programs should not do it anyway. MPlayer for example has a thread dedicated to reading the frames as they become available, storing them for future processing by another thread when required (frame rate enforcement) or when the CPU will be able to do so. Images have to be captured and dropped if they can't be used, instead of being captured at a rate which is slower than the device's rate. If the driver or device were not buggy, this issue would probably not be noticed, as it's the case with other V4L2 devices.