From LinuxTVWiki
Revision as of 00:53, 23 November 2008 by CityK (talk | contribs) (setup for move to dissusion page)
Jump to navigation Jump to search

I have a feeling the vivi driver is not as perfect as it claims to be, so this is going to be annoying.

This is true. However, the issues you would notice on vivi will likely happen on real drivers. You're welcome to feed us with the noticed problems and/or fixes for the driver code.

juser@vaio:~/vga2usb/tc$ v4l-info >/dev/null
ioctl VIDIOCGTUNER: Invalid argument

This is one missing feature on vivi: It emulates a V4L camera. So, the driver currently doesn't support changing channels. So, the tuner ioctls weren't implemented. It would be nice to implement tuner change there.

There's a capability field returned by VIDIOC_QUERYCAP to indicate if this is supported or not (V4L2_CAP_TUNER).

ioctl VIDIOCGAUDIO: Invalid argument

This is also missing. There's no audio generation inside vivi driver. I'm not sure if this would be valuable. If so, we would need to create a "vivi-alsa" to output some audio. Without generating audio, it makes no sense to control audio at vivi.

ioctl VIDIOCGFBUF: Invalid argument

Vivi also doesn't implement direct output to a video frame. Modern drivers aren't implementing those ioctls also. The issue here, with a real PCI driver, is that the driver should setup a PCI2PCI data transfer, to allow to move a captured stream from video capture board memory directly to the video adapter's memory. This is useful for slow machines, since it will free CPU from the data move process. All data move will happen inside the motherboard chipset. However, this is known to be unsafe on several chipsets (including VIA and ATI/AMD ones). If you do a PCI2PCI data transfer, the chipset should avoid conflicting this with a PCI2MEM one. Some chipsets don't avoid the conflicts. This may result on massive data loss at the harddisks, or at the swap memory.

Also, most modern TV applications want to do run some de-interlacing algorithm at the data, before sending to the video adapter. For transcode, this shouldn't be an issue.

At the end, this is something legacy.

Btw, those ioctls are V4L1, not V4L2.

v4l-info is about as simple as you can get, so I would think a perfect driver should not error.

Not true. The above API calls are optional. They make no sense for Webcams, while some of them are important for TV capture devices. It is expected that some ioctls may fail.