Duncan Webb wrote: > Lars Hanisch wrote: >> Hi, >> >> I'm playing a bit around with detecting installed video output >> devices. I'm having a PVR350, which has various devices: >> >> /dev/video0 >> /dev/video16 >> /dev/video24 >> /dev/video32 >> /dev/video48 >> >> If I'm querying the capabilities of these devices with >> VIDIOC_QUERYCAP, I get the same result for every device: 10702f3. >> >> How can a program choose the right device, if it needs to write to the >> YUV-decoder without knowing that ivtv puts that at /dev/video48? >> >> VIDIOC_ENUMOUTPUT and VIDIOC_ENUM_FMT also return the same for every >> device: >> >> output 0, type 2: S-Video + Composite >> output 1, type 2: Composite >> output 2, type 2: S-Video >> output 3, type 2: RGB >> output 4, type 2: YUV C >> output 5, type 2: YUV V >> format 0:32314d48: HM12 (YUV 4:2:0) >> format 1:4745504d: MPEG >> >> >> What am I missing? > > > AFAIK you're not missing anything, the only way I've found is to look in > /sys/class/video4linux/*/name to find out what a specific device is. > As this is a string, it's not useful for applications. > > My guess is that this is an oversight in the V4L2 API, that there is > doesn't seem to be a way to determine what a specific device is. In the > early days V4L only supported YUV formats. > > Actually, I would like to be able to determine what a specific device > can really do. It would be nice to have an ALSA driver for audio instead > of a video device.
I'm working on a better method for detecting the PVR350-output in the ivtv-vidix part of mplayer, so this limitation is not too bad. It's ivtv specific, so the code can presume some things. I'll need to study the v4l2-spec a bit more before I can provide a good proposal for the api. Are there any discussions which regard this kind of limitation? Lars. _______________________________________________ ivtv-devel mailing list [email protected] http://ivtvdriver.org/mailman/listinfo/ivtv-devel
