On Friday 27 March 2009 20:19:29 Martin Dauskardt wrote:
> Hans Verkuil wrote:
> > 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.
>
> I think an application should make things as much easy as possible for
> the user. Let's suppose a user wants to record from his VHS-machine and
> plugs the cable into the S-Video connector. Now he wants to switch to the
> appropriate input. Do you suggest that he should first detect the number
> of the right input by using v4l2-ctl ? Or testing different input
> numbers by try-and-error? It is not the job of the user to know the input
> number of each connector.
> Using the pvrinput plugin, the user simply chooses "S-Video", and the
> plugin sets the input to the appropriate input number - no matter if it
> is a PVR350 (input 1) or PVRUSB2 (input 2)
> But things would be easier if we had a standard for naming the inputs.
???
An application should call ENUMINPUT to enumerate all possible inputs and
let the user choose between them. You present the name of each input as
returned by ENUMINPUT to the user, and that maps to the input number (the
index passed to ENUMINPUT). An application should not attempt to interpret
these names since these names are entirely dependent on the hardware.
If the pvrinput plugin has a hardcoded list of inputs (tuner, S-Video,
Composite), then that's wrong. The simplest example would be ivtv where you
can have multiple S-Video and Composite inputs if the user bought a add-on
cable. Newer hardware may have HDMI or Component inputs. Webcams only have
a camera input, but a stereo webcam might have two camera inputs. Or the
input names might correspond to connector labels on a backplate, etc. etc.
Don't interpret the input names, just pass them on to the user and let the
user choose which input he wants.
Regards,
Hans
> > 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?
>
> You are right, simply opening the radio device works fine with ivtv.
> I tried this also with pvrusb2 and discovered a problem:
>
> Mike Isely wrote:
> >Remember that opening /dev/radioX still produces the correct result.
> >That is enough for any V4L radio application to use the driver without
> >change.
>
> Yes, opening the radio device works. The driver switches automatically to
> input 3 (radio) and the tuner uses 62,5 Hz steps:
>
> linvdr:~# v4l2-ctl -T -d 0
> Tuner:
> Capabilities : 62.5 Hz stereo
> Frequency range : 65.0 MHz - 108.0 MHz
> Signal strength : 25%
> Current audio mode : bilingual
> Available subchannels: stereo
> linvdr:~# v4l2-ctl --get-input -d 0
> Video input : 3 (radio)
>
> But after closing the radio device, these settings still exist. The
> result is, that tuning to a TV station does not work. I also checked this
> with v4l2-ctl: v4l2-ctl -f 280.25 -d 0 gives no error (but also reports
> no success).
>
> To be able to tune to a TV frequency I must first set the input to 0:
>
> linvdr:~# v4l2-ctl -T -d 0
> Tuner:
> Capabilities : 62.5 Hz stereo
> Frequency range : 65.0 MHz - 108.0 MHz
> Signal strength : 25%
> Current audio mode : bilingual
> Available subchannels: mono
> linvdr:~# v4l2-ctl --set-input 0 -d 0
> Video input set to 0 (television)
> linvdr:~# v4l2-ctl -f 280.25 -d 0
> Frequency set to 4484 (280.250000 MHz)
> linvdr:~# v4l2-ctl -T -d 0
> Tuner:
> Capabilities : 62.5 kHz multi-standard stereo lang1 lang2
> Frequency range : 44.0 MHz - 958.0 MHz
> Signal strength : 99%
> Current audio mode : bilingual
> Available subchannels: stereo
>
> Is this a problem of the application (both v4l2-ctl and pvrinput-plugin),
> or should the driver switch to the previous input (as it was before
> opening the radio) after closing the radio device ?
>
> 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
