> Hi,
>
> thanks for all replys
>
> Hans wrote:
>> > Do all cx18-based cards have a Tuner that supports PAL ?
>>
>> No. The HVR-1600 for example is NTSC only.
> that' s strange. We had a user with a HVR 1600 recently in the german vdr
> portal forum. According to his log, the driver returned success when
> pvrinput
> was setting VIDIOC_S_STD with V4L2_STD_PAL. Maybe this was a bug in
> earlier
> drivers versions?
Don't think so. This info is retrieved from the eeprom. And the HVR-1600
is not for sale in Europe (not much point if it only supports ATSC).
>> Anyway, the cx18 behavior is similar to ivtv. And use ENUMINPUT to
>> determine which input has the tuner. Don't rely on the name of the
>> input.
>
> It seems we can detect the tuner by looking for type
> V4L2_INPUT_TYPE_TUNER.
> But for the external inputs there is only V4L2_INPUT_TYPE_CAMERA which is
> described as "Analog baseband input, for example CVBS / Composite Video,
> S-Video, RGB" in the v4l2 specs. This is not sufficient to let the
> application switch to a certain input. Our solution for the plugin was to
> look for all input names and internally assign them to the different types
> of
> inputs. Example: If a user wants to switch to the first S-Video input, the
> application has to know that the right input is the one named as "s-video"
> (pvrusb2) or "S-Video 1" (ivtv/cx18). Other drivers like saa7134 start
> numbering with 0. Maybe the v4l2 specs should be extended ?
I'm not sure what the problem is. An application shouldn't have to care
about whether an input is a S-Video, Composite or something else. The only
exception is if it is a Tuner input, since that means that tuner related
ioctls are available. Other than that, these names are just for the user.
If you really need to switch to a tuner input to get the radio to work on
ivtv, then that's an ivtv bug. Although according to Andy it works with
cx18, so I'm surprised that it doesn't work with ivtv since cx18 is
derived from ivtv. Can you double-check this?
>
> Mike wrote:
>
>> > > The pvrusb2 driver has its own input name for
>> > > radio.
>> >
>> > Hmm, dubious behavior as well.
>>
>> The pvrusb2 driver treats the radio internally as "just another input",
>> it is after all effectively another input. However if you open the
>> radio device node, the driver also switches to that input. I don't see
>> anything dubious about that.
>>
>> -Mike
> I like this behaviour. Input switching is easier to use in applications
> compared to opening and closing devices.
Well, I think it is not according to the v4l2 spec. However, the way radio
works in v4l2 sucks, so this might be time to change the spec. I agree
that having a separate input for radio is cleaner.
Regards,
Hans
>
> Greets,
>
> Martin
>
> _______________________________________________
> ivtv-devel mailing list
> [email protected]
> http://ivtvdriver.org/mailman/listinfo/ivtv-devel
>
>
--
Hans Verkuil - video4linux developer - sponsored by TANDBERG
_______________________________________________
ivtv-devel mailing list
[email protected]
http://ivtvdriver.org/mailman/listinfo/ivtv-devel
