> I think xawtv uses this to request 3 different color space encodings before > it gives up and agrees to RGB24, as this debug info from my driver shows: > > 3comhc.c(182868):homeconnect_ioctl(690):VIDIOCSPICT depth = 16, pal = 7 > 3comhc.c(182868):homeconnect_ioctl(616):VIDIOCGCAP > 3comhc.c(182868):homeconnect_ioctl(690):VIDIOCSPICT depth = 12, pal = 15 > 3comhc.c(182868):homeconnect_ioctl(616):VIDIOCGCAP > 3comhc.c(182868):homeconnect_ioctl(690):VIDIOCSPICT depth = 32, pal = 5 > 3comhc.c(182868):homeconnect_ioctl(616):VIDIOCGCAP > 3comhc.c(182868):homeconnect_ioctl(690):VIDIOCSPICT depth = 24, pal = 4 Depends on the X-Server configuration, xawtv tries to avoid conversions. With Xvideo being available it tries the yuv formats it can pass to XvShmPutImage first. Next is the native pixmap format if the X-Server (VIDEO_PALETTE_RGB32 if the X-Server runs at 32bpp, would be a different one if you run 16bpp). Then it starts walking the list of conversion functions it has ... > To all but the last one, my ioctl function returns -EINVAL. And the problem is? xawtv searches for a format it can use, and it finds one. Looks fine to me ... With v4l2 this works a bit more elegant as the xawtv can ask for a list of supported formats and thus no trial-and-error is needed to find a working one. Gerd -- #include </dev/tty>
