Mailing List Archive

> It seems my personal mail to Andy Walls didn reach him, so I repost it
> here:
>
> I would like to add support for cx18 devices in the pvrinput-plugin for
> vdr
> and have a few questions:
>
> Do all cx18-based cards have a Tuner that supports PAL ?

No. The HVR-1600 for example is NTSC only.

> I read that sliced VBI is now working. How can I detect if the installed
> cx18
> driver supports it? Should I quiry the capabilitys for
> V4L2_CAP_SLICED_VBI_CAPTURE

Yes, that's the right way to do it.

> , or is it better to determine support by
> looking
> for the driver version number?
>
> How do I switch from TV or external inputs to radio? The ivtv driver needs
> to
> switch to the "Tuner" input (which seems to be namend "Tuner 1" for cx18)
> and
> then open the radio device.

I never realized that, but this might be questionable behavior from ivtv.
I think that opening the radio device should always switch to the tuner
input automatically.

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.

> The pvrusb2 driver has its own input name for
> radio.

Hmm, dubious behavior as well.

> Is there anything special which is different from the ivtv driver? Any
> unsupported ioctl? (The pvrusb2 driver does not support
> V4L2_ENC_CMD_STOP/START for example)

It should be pretty similar to ivtv. When I wrote the initial version of
cx18 I leaned heavily on the ivtv code.

> Do all cx18-based cards have ATSC support? Or are there any devices that
> support DVB-C, DVB-T or DVB-S instead? Is there any analogue-only device
> with
> a cx23418 chip?

There are definitely analog-only versions around. I know of at least one
card that uses DVB-T. Currently the cx18 driver doesn't support any DVB-?
tuners, though. Just analog and ATSC.

>
> Greets from Germany,
> Martin

Greetings from Norway,

Hans

>
> _______________________________________________
> ivtv-devel mailing list
> ivtv-devel@ivtvdriver.org
> http://ivtvdriver.org/mailman/listinfo/ivtv-devel
>


--
Hans Verkuil - video4linux developer - sponsored by TANDBERG


_______________________________________________
ivtv-devel mailing list
ivtv-devel@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-devel

On Thu, 26 Mar 2009, Hans Verkuil 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

--

Mike Isely
isely @ pobox (dot) com
PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8

_______________________________________________
ivtv-devel mailing list
ivtv-devel@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-devel

On Thu, 2009-03-26 at 13:08 +0100, Martin Dauskardt wrote:
> It seems my personal mail to Andy Walls didn reach him, so I repost it here:

In this case you are correct, it did not reach me.

But please note, as a general rule, I don't respond to personal emails
related to cx18. I rely on the power of newsgroups and mailing lists to
help shoulder the load. :)


> I would like to add support for cx18 devices in the pvrinput-plugin for vdr
> and have a few questions:

Just to let you know, the cx18 driver works fine with an HVR-1600 and
MythTV, if one tells MythTV that the card is an PVR-x50, PVR-500 MPEG
encoder card (for analog TV) and a DVB card for ATSC.


> Do all cx18-based cards have a Tuner that supports PAL ?

No. There are really only 3 well supported cards:

HVR-1600 - NTSC-M analog tuner, MCE versions have an FM radio input

Compro H900 - XCeive 2028 silicon tuner for analog and FM radio AFAICT

Conexant Raptor PAL/SECAM - a PAL/SECAM tuner for analog, also FM Radio


All the other boards are poorly supported due to little information
available about the hardware on the boards or lack of testing feedback.

The Conexant Raptor board is an eval board which very few users will
have.



> I read that sliced VBI is now working. How can I detect if the installed cx18
> driver supports it? Should I quiry the capabilitys for
> V4L2_CAP_SLICED_VBI_CAPTURE , or is it better to determine support by looking
> for the driver version number?

Use the V4L2_CAP_SLICED_VBI_CAPTURE flag. The driver version only
really increments for fundamental internal changes. Maybe I should
change that policy.


> How do I switch from TV or external inputs to radio? The ivtv driver needs to
> switch to the "Tuner" input (which seems to be namend "Tuner 1" for cx18) and
> then open the radio device. The pvrusb2 driver has its own input name for
> radio.

I'd have to investigate the details. Given that most of the code is
derived from ivtv, it should behave very similarly to ivtv.

I do know that this following sequence works for an HVR-1600 (I just
tested it):

$ v4l2-ctl -i 0
Video input set to 0 (Tuner 1)
$ v4l2-ctl -i 2
Video input set to 2 (Composite 1)
$ ivtv-radio -v -f 88.1
set to freq 88.10
signal strength: 8192
Running: aplay -f dat < /dev/video24
Playing raw data 'stdin' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo
^CAborted by signal Interrupt...
Cleaning up

So I don't think you need to set to the Tuner 1 input first.


> Is there anything special which is different from the ivtv driver? Any
> unsupported ioctl? (The pvrusb2 driver does not support
> V4L2_ENC_CMD_STOP/START for example)

Obviously MPEG *decoder* ioctls() aren't supported by the cx18 driver,
as the CX23418 only performs MPEG encoding.

Simultaneous digital TV capture and analog capture is supported. The
HVR-1600 has tuners to support both at once. Cards that have a single
silicon tuner for digital TV and analog obviously could never support
both at once.



Some things on my TODO list:

MPEG Index file generation isn't implemented yet. Nor the "dualwatch"
for secondary audio programs.

Volume control of I2S audio (line in audio and FM Radio on the HVR-1600
and Conexant Raptor) doesn't work. You can still mute it however.
(Mute is done by the encoder vs. the baseband audio processing in the
digitizer.)

Due to the conversion to the new v4l2 framework and some latent bugs
inhereted from ivtv, the switch to or from FM radio that relies on GPIO
lines (like on the Conexant Raptor card) may not work right,



> Do all cx18-based cards have ATSC support?

No. Only one unit that I know of:

HVR1600: has a digital tuner and demodulator for ATSC and North
American cable (ITU-T J.83 Annex B) QAM



> Or are there any devices that
> support DVB-C, DVB-T or DVB-S instead?

Toshiba Qosmio internal: DVB-T but not enough info about the laptop card
to make the driver work.

Leadtek WinFast PVR2100: DVB-T but not enough info about the card to
make the driver work.

Leadtek WinFast DVR3100 H: DVB-T but not enough info about the card to
make the driver work.

Yuan MPC718: Either DVB-T or DVB-C (I'm not sure which), but not enough
info about the card to make the driver work.



> Is there any analogue-only device with
> a cx23418 chip?

Compro H900: no digital tuner(?) nor demod

Conexant Raptor: no digital tuner nor demod



> Greets from Germany,
> Martin

Regards,
Andy


_______________________________________________
ivtv-devel mailing list
ivtv-devel@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-devel

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?

> 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 ?

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.

Greets,

Martin

_______________________________________________
ivtv-devel mailing list
ivtv-devel@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-devel

> 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
> ivtv-devel@ivtvdriver.org
> http://ivtvdriver.org/mailman/listinfo/ivtv-devel
>
>


--
Hans Verkuil - video4linux developer - sponsored by TANDBERG


_______________________________________________
ivtv-devel mailing list
ivtv-devel@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-devel

On Fri, 27 Mar 2009, Hans Verkuil wrote:

> >
> > 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.

Remember that opening /dev/radioX still produces the correct result.
That is enough for any V4L radio application to use the driver without
change.

Of course, there's that little issue of streaming the audio which is
unfortunately not very standard, but that's a whole different problem.
But with the pvrusb2 driver, the radio app can open /dev/radio0 and then
mplayer (or any mpeg streamer) can be used to open either /dev/video0 or
/dev/radio0 (again) to stream out the audio - with the radio app still
having full control over the radio.

It seems that the only "out of spec" aspect for selecting the radio here
is the mere existance of the radio as an additional input choice when
/dev/videoX is opened. That seems hardly a problem, and I also seem to
remember that it's up to the driver to define its inputs, not the spec.

As for changing the spec, well obviously I like the idea of treating the
radio as just another input, since after all that's what it is...

-Mike

--

Mike Isely
isely @ pobox (dot) com
PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8

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.

>
> 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
ivtv-devel@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-devel

On Fri, 27 Mar 2009, Martin Dauskardt wrote:

[...]

> 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:

[...]

Martin:

Since this is an ivtv list, we should take this off the list. FWIW, the
radio support in the pvrusb2 driver was thoroughly debugged quite a long
while ago - including switching modes back and forth. So something new
must have been broken. I'll need to know exactly which driver version
you are using (i.e. v4l-dvb revision # off of master) and kernel you
tried it under. This should be pretty easy to debug.

-Mike


--

Mike Isely
isely @ pobox (dot) com
PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8

_______________________________________________
ivtv-devel mailing list
ivtv-devel@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-devel

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
> ivtv-devel@ivtvdriver.org
> http://ivtvdriver.org/mailman/listinfo/ivtv-devel



--
Hans Verkuil - video4linux developer - sponsored by TANDBERG

_______________________________________________
ivtv-devel mailing list
ivtv-devel@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-devel

On Fri, 27 Mar 2009, Martin Dauskardt wrote:

[...]

>
> 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 ?

Well that will teach me to reply too quickly. Reading further I think I
understand the issue. This I believe is not a bug.

When I first read this description, I thought you were saying that the
tuning was messed up after running in radio mode and then switching back
to TV mode. The real issue if I understand this correctly is that it
didn't magically switch back to TV mode when you expected it to.

Is there a place in the V4L spec that requires the "current input" to be
analog television when /dev/videoX is open? Because if not, then it
really is up to the app to first select the input it wants before
implicitly assuming it can stream from it. If the app fails to select
an input, then why should it expect the driver to magically know what
the input should have been? After all, it will also fail to tune a TV
channel if the previous usage of the driver was to stream from the
s-video input.

If for example one were to force TV mode every time /dev/video0 were
opened, this could break other apps which happen to on-the-fly open
/dev/video0 multiple times as they run. I believe xawtv (yes I know
it's unmaintained) works this way.

I could alternatively cause the "previous" input to be selected when
/dev/radioX is closed. I actually had it that way until about a year
ago. However I don't think that's right either, because it's a magical
change that might be confusing if/when other opens take place while
/dev/radioX is open. The definition of the concept of "previous" input
becomes fuzzy then. You might convince me otherwise, but since any app
really should select its desired input before streaming anyway, I think
this is in the end a non-issue.

-Mike


--

Mike Isely
isely @ pobox (dot) com
PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8

_______________________________________________
ivtv-devel mailing list
ivtv-devel@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-devel

On Fri, 2009-03-27 at 21:30 +0100, Hans Verkuil wrote:
> 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.

Right. The HVR-1600(MCE?) supports the same cable as the PVR-150MCE
used for additional S-Video, CVBS and Audio inputs - I happen to have
one of those cables. :)

Here's what the cx18 driver blurts out for inputs. Note, the "Name"
originates in the driver. (I suppose i8n is a problem.)

$ v4l2-ctl --list-inputs | grep -B1 Name
Input : 0
Name : Tuner 1
--
Input : 1
Name : S-Video 1
--
Input : 2
Name : Composite 1
--
Input : 3
Name : S-Video 2
--
Input : 4
Name : Composite 2

Regards,
Andy

> 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
> > ivtv-devel@ivtvdriver.org
> > http://ivtvdriver.org/mailman/listinfo/ivtv-devel
>
>
>


_______________________________________________
ivtv-devel mailing list
ivtv-devel@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-devel

On Fri, 2009-03-27 at 15:36 -0500, Mike Isely wrote:
> On Fri, 27 Mar 2009, Martin Dauskardt wrote:
>
> [...]
>
> >
> > 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 ?
>
> Well that will teach me to reply too quickly. Reading further I think I
> understand the issue. This I believe is not a bug.
>
> When I first read this description, I thought you were saying that the
> tuning was messed up after running in radio mode and then switching back
> to TV mode. The real issue if I understand this correctly is that it
> didn't magically switch back to TV mode when you expected it to.
>
> Is there a place in the V4L spec that requires the "current input" to be
> analog television when /dev/videoX is open? Because if not, then it
> really is up to the app to first select the input it wants before
> implicitly assuming it can stream from it. If the app fails to select
> an input, then why should it expect the driver to magically know what
> the input should have been? After all, it will also fail to tune a TV
> channel if the previous usage of the driver was to stream from the
> s-video input.
>
> If for example one were to force TV mode every time /dev/video0 were
> opened, this could break other apps which happen to on-the-fly open
> /dev/video0 multiple times as they run. I believe xawtv (yes I know
> it's unmaintained) works this way.
>
> I could alternatively cause the "previous" input to be selected when
> /dev/radioX is closed. I actually had it that way until about a year
> ago. However I don't think that's right either, because it's a magical
> change that might be confusing if/when other opens take place while
> /dev/radioX is open.

According to section 1.5 of the v4l2-spec:

"Radio devices have no audio inputs or outputs. They have exactly one
tuner which in fact is an audio source, but this API associates tuners
with video inputs or outputs only, and radio devices have none of
these."

So the abstraction is that the radio device is a control and tuning
device (like an FM receiver in a home stereo system), but the audio from
the tuner is obtained via a soundcard or video device node (like the
power amp and speakers in a home stereo system).



The /dev/radioX device node has all sorts of "magical" dependencies. In
cx18 and ivtv, it's a control only device node that passes no data (no
RDS). PCM data comes from /dev/video24 (IIRC). Already at least one
app or coordinated set of applications has /dev/radio0 and /dev/video24
open if you're working with the radio. If that app or application set
then tries to capture MPEG from /dev/video0, app gets an EBUSY errno.
/dev/video0 can still be opened and some ioctl()'s exercised though.


So this is where Hans' plan for a "media controller" device may be able
to clean things up nicely. Right now, for FM radio, apps are required
to know about interdependencies to some degree. The constsituent parts
(FM receiver and power amp in my analogy) are presented to userspace as
pieces of a working system and apps have to put together their own FM
stereo playback system. I believe the intent of the "media controller"
device to be presented by drivers was to eliminate this burden of
implicit knowledge from applications.

Regards,
Andy

> The definition of the concept of "previous" input
> becomes fuzzy then. You might convince me otherwise, but since any app
> really should select its desired input before streaming anyway, I think
> this is in the end a non-issue.
>
> -Mike



_______________________________________________
ivtv-devel mailing list
ivtv-devel@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-devel