RFC: Phase 2/3: Move the compat code into v4l1-compat. Convert apps.

RFC: Phase 2/3: Move the compat code into v4l1-compat. Convert apps.

[Hans Verkuil]

Hi all!

The second phase that needs to be done to remove the v4l1 support from the
kernel is that libv4l1 should replace the v4l1-compat code from the kernel.

I do not know how complete the libv4l1 code is right now. I would like to
know in particular whether the VIDIOCGMBUF/mmap behavior can be faked in
libv4l1 if drivers do not support the cgmbuf vidioc call.

In principle libv4l1 should allow V4L1 apps to run fine with V4L2 drivers.
That will also solve the problem of embedded device vendors running new
kernels with old V4L1 applications. They just need to use libv4l1.

The third phase that can be done in parallel is to convert V4L1-only apps.
I strongly suspect that any apps that are V4L1-only are also unmaintained.
We have discussed before that we should set up git repositories for such
tools (xawtv being one of the more prominent apps since it contains several
v4l1-only console apps). Once we have maintainership, then we can convert
these tools to v4l2 and distros and other interested parties have a place
to send patches to.

I'm afraid that it is unlikely that anyone will do that work for us, so it's
probably best just to bite the bullet and do it ourselves.

Regards,

	Hans

-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG

Re: RFC: Phase 2/3: Move the compat code into v4l1-compat. Convert apps.

[Chicken Shack]

Am Samstag, den 20.03.2010, 10:21 +0100 schrieb Hans Verkuil:
> Hi all!
> 
> The second phase that needs to be done to remove the v4l1 support from the
> kernel is that libv4l1 should replace the v4l1-compat code from the kernel.
> 
> I do not know how complete the libv4l1 code is right now. I would like to
> know in particular whether the VIDIOCGMBUF/mmap behavior can be faked in
> libv4l1 if drivers do not support the cgmbuf vidioc call.
> 
> In principle libv4l1 should allow V4L1 apps to run fine with V4L2 drivers.
> That will also solve the problem of embedded device vendors running new
> kernels with old V4L1 applications. They just need to use libv4l1.
> 
> The third phase that can be done in parallel is to convert V4L1-only apps.
> I strongly suspect that any apps that are V4L1-only are also unmaintained.
> We have discussed before that we should set up git repositories for such
> tools (xawtv being one of the more prominent apps since it contains several
> v4l1-only console apps). Once we have maintainership, then we can convert
> these tools to v4l2 and distros and other interested parties have a place
> to send patches to.
> 
> I'm afraid that it is unlikely that anyone will do that work for us, so it's
> probably best just to bite the bullet and do it ourselves.
> 
> Regards,
> 
> 	Hans
> 

Hello Hans,

I haven't followed your discussion so far (sorry!).
I got a trivial question:

I run a Miro PCTV pro (stereo) on one of my machines.
It needs "simple tuner transport" / "TDA 9885/6/7 analog IF
demodulator", Micronas msp3400 for Stereo tone PLUS v4l1 compat layer as
kernel options to run / to be usable at all.

Can you make sure that this card will still be usable after your v4l1
removal activities are finished?

In other words: What happens to this v4l1 compat code which is obviously
necessary for this (and other) card(s) to run?

That's it what I haven't understood right now, so could you please be
kind enough to explain that with a couple of words?

Thanks!

CS

P. S.: If you make your decision to host xawtv and other apps please do
not merge hybrid applications (i. e. apps made for DVB and analogue
devices) as you can find them in the xawtv 4.0 pre alpha code for
example in analogue trees.
Rather establish extra trees for hybrid applications please.

Re: RFC: Phase 2/3: Move the compat code into v4l1-compat. Convert apps.

[Hans Verkuil]

On Saturday 20 March 2010 13:17:15 Chicken Shack wrote:
> Am Samstag, den 20.03.2010, 10:21 +0100 schrieb Hans Verkuil:
> > Hi all!
> > 
> > The second phase that needs to be done to remove the v4l1 support from the
> > kernel is that libv4l1 should replace the v4l1-compat code from the kernel.
> > 
> > I do not know how complete the libv4l1 code is right now. I would like to
> > know in particular whether the VIDIOCGMBUF/mmap behavior can be faked in
> > libv4l1 if drivers do not support the cgmbuf vidioc call.
> > 
> > In principle libv4l1 should allow V4L1 apps to run fine with V4L2 drivers.
> > That will also solve the problem of embedded device vendors running new
> > kernels with old V4L1 applications. They just need to use libv4l1.
> > 
> > The third phase that can be done in parallel is to convert V4L1-only apps.
> > I strongly suspect that any apps that are V4L1-only are also unmaintained.
> > We have discussed before that we should set up git repositories for such
> > tools (xawtv being one of the more prominent apps since it contains several
> > v4l1-only console apps). Once we have maintainership, then we can convert
> > these tools to v4l2 and distros and other interested parties have a place
> > to send patches to.
> > 
> > I'm afraid that it is unlikely that anyone will do that work for us, so it's
> > probably best just to bite the bullet and do it ourselves.
> > 
> > Regards,
> > 
> > 	Hans
> > 
> 
> Hello Hans,
> 
> I haven't followed your discussion so far (sorry!).
> I got a trivial question:
> 
> I run a Miro PCTV pro (stereo) on one of my machines.
> It needs "simple tuner transport" / "TDA 9885/6/7 analog IF
> demodulator", Micronas msp3400 for Stereo tone PLUS v4l1 compat layer as
> kernel options to run / to be usable at all.

That's the V4L2 bttv driver. What app are you using with this card?

> 
> Can you make sure that this card will still be usable after your v4l1
> removal activities are finished?

You can easily test this by turning off the compat layer in the kernel
config. You should still be able to use your v4l1 app by using LD_PRELOAD=/usr/lib/v4l1compat.so.

> 
> In other words: What happens to this v4l1 compat code which is obviously
> necessary for this (and other) card(s) to run?
> 
> That's it what I haven't understood right now, so could you please be
> kind enough to explain that with a couple of words?
> 
> Thanks!
> 
> CS
> 
> P. S.: If you make your decision to host xawtv and other apps please do
> not merge hybrid applications (i. e. apps made for DVB and analogue
> devices) as you can find them in the xawtv 4.0 pre alpha code for
> example in analogue trees.
> Rather establish extra trees for hybrid applications please.

These apps will each get their own tree.

Regards,

	Hans

> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG

Re: RFC: Phase 2/3: Move the compat code into v4l1-compat. Convert apps.

[Chicken Shack]

Am Samstag, den 20.03.2010, 13:37 +0100 schrieb Hans Verkuil:
> On Saturday 20 March 2010 13:17:15 Chicken Shack wrote:
> > Am Samstag, den 20.03.2010, 10:21 +0100 schrieb Hans Verkuil:
> > > Hi all!
> > > 
> > > The second phase that needs to be done to remove the v4l1 support from the
> > > kernel is that libv4l1 should replace the v4l1-compat code from the kernel.
> > > 
> > > I do not know how complete the libv4l1 code is right now. I would like to
> > > know in particular whether the VIDIOCGMBUF/mmap behavior can be faked in
> > > libv4l1 if drivers do not support the cgmbuf vidioc call.
> > > 
> > > In principle libv4l1 should allow V4L1 apps to run fine with V4L2 drivers.
> > > That will also solve the problem of embedded device vendors running new
> > > kernels with old V4L1 applications. They just need to use libv4l1.
> > > 
> > > The third phase that can be done in parallel is to convert V4L1-only apps.
> > > I strongly suspect that any apps that are V4L1-only are also unmaintained.
> > > We have discussed before that we should set up git repositories for such
> > > tools (xawtv being one of the more prominent apps since it contains several
> > > v4l1-only console apps). Once we have maintainership, then we can convert
> > > these tools to v4l2 and distros and other interested parties have a place
> > > to send patches to.
> > > 
> > > I'm afraid that it is unlikely that anyone will do that work for us, so it's
> > > probably best just to bite the bullet and do it ourselves.
> > > 
> > > Regards,
> > > 
> > > 	Hans
> > > 
> > 
> > Hello Hans,
> > 
> > I haven't followed your discussion so far (sorry!).
> > I got a trivial question:
> > 
> > I run a Miro PCTV pro (stereo) on one of my machines.
> > It needs "simple tuner transport" / "TDA 9885/6/7 analog IF
> > demodulator", Micronas msp3400 for Stereo tone PLUS v4l1 compat layer as
> > kernel options to run / to be usable at all.
> 
> That's the V4L2 bttv driver. What app are you using with this card?

Should rather be:
What apps are you using (Plural mode)?

One big mess somehow.

1. The only one that runs is tvtime. But with tvtime I cannot record
streams.
2. Then I have tested zapping, which is a gnome app.
No matter if I start it without parameters or with parameter
LD_PRELOAD=/usr/lib/libv4l/v4l1compat.so (it's a Debian system), channel
switching is simply impossible. Version is 0.10cvs6.

Well, and the biggest pest are the radio apps:
1. Running gnomeradio the channel scanner does not find anything and I
cannot hear anything (independent from starting mode - with or without
parameters).

2. Maybe Gerd's "radio" solves it, but in that case recording is
unclear, as it is a rather primitive GUI without recording function
implied.

> > 
> > Can you make sure that this card will still be usable after your v4l1
> > removal activities are finished?
> 
> You can easily test this by turning off the compat layer in the kernel
> config. You should still be able to use your v4l1 app by using LD_PRELOAD=/usr/lib/v4l1compat.so.

Hmmm. See above. If I used the parametry in a wrong way please tell me.
 
> > In other words: What happens to this v4l1 compat code which is obviously
> > necessary for this (and other) card(s) to run?
> > 
> > That's it what I haven't understood right now, so could you please be
> > kind enough to explain that with a couple of words?
> > 
> > Thanks!
> > 
> > CS
> > 
> > P. S.: If you make your decision to host xawtv and other apps please do
> > not merge hybrid applications (i. e. apps made for DVB and analogue
> > devices) as you can find them in the xawtv 4.0 pre alpha code for
> > example in analogue trees.
> > Rather establish extra trees for hybrid applications please.
> 
> These apps will each get their own tree.
> 
> Regards,
> 
> 	Hans

This sounds excellent :)

Best Regards

Uwe

P. S.: So if I take you right the kernel compat module function does not
hit or point to the driver itself, but rather to the application layer?
Not easy to anticipate this as a picture in my head......

Re: RFC: Phase 2/3: Move the compat code into v4l1-compat. Convert apps.

[Hans Verkuil]

On Saturday 20 March 2010 14:51:44 Chicken Shack wrote:
> Am Samstag, den 20.03.2010, 13:37 +0100 schrieb Hans Verkuil:
> > On Saturday 20 March 2010 13:17:15 Chicken Shack wrote:
> > > Am Samstag, den 20.03.2010, 10:21 +0100 schrieb Hans Verkuil:
> > > > Hi all!
> > > > 
> > > > The second phase that needs to be done to remove the v4l1 support from the
> > > > kernel is that libv4l1 should replace the v4l1-compat code from the kernel.
> > > > 
> > > > I do not know how complete the libv4l1 code is right now. I would like to
> > > > know in particular whether the VIDIOCGMBUF/mmap behavior can be faked in
> > > > libv4l1 if drivers do not support the cgmbuf vidioc call.
> > > > 
> > > > In principle libv4l1 should allow V4L1 apps to run fine with V4L2 drivers.
> > > > That will also solve the problem of embedded device vendors running new
> > > > kernels with old V4L1 applications. They just need to use libv4l1.
> > > > 
> > > > The third phase that can be done in parallel is to convert V4L1-only apps.
> > > > I strongly suspect that any apps that are V4L1-only are also unmaintained.
> > > > We have discussed before that we should set up git repositories for such
> > > > tools (xawtv being one of the more prominent apps since it contains several
> > > > v4l1-only console apps). Once we have maintainership, then we can convert
> > > > these tools to v4l2 and distros and other interested parties have a place
> > > > to send patches to.
> > > > 
> > > > I'm afraid that it is unlikely that anyone will do that work for us, so it's
> > > > probably best just to bite the bullet and do it ourselves.
> > > > 
> > > > Regards,
> > > > 
> > > > 	Hans
> > > > 
> > > 
> > > Hello Hans,
> > > 
> > > I haven't followed your discussion so far (sorry!).
> > > I got a trivial question:
> > > 
> > > I run a Miro PCTV pro (stereo) on one of my machines.
> > > It needs "simple tuner transport" / "TDA 9885/6/7 analog IF
> > > demodulator", Micronas msp3400 for Stereo tone PLUS v4l1 compat layer as
> > > kernel options to run / to be usable at all.
> > 
> > That's the V4L2 bttv driver. What app are you using with this card?
> 
> Should rather be:
> What apps are you using (Plural mode)?
> 
> One big mess somehow.
> 
> 1. The only one that runs is tvtime. But with tvtime I cannot record
> streams.
> 2. Then I have tested zapping, which is a gnome app.
> No matter if I start it without parameters or with parameter
> LD_PRELOAD=/usr/lib/libv4l/v4l1compat.so (it's a Debian system), channel
> switching is simply impossible. Version is 0.10cvs6.

zapping is definitely V4L2 aware. Make sure it is not trying to use V4L1.

> 
> Well, and the biggest pest are the radio apps:
> 1. Running gnomeradio the channel scanner does not find anything and I
> cannot hear anything (independent from starting mode - with or without
> parameters).

Which gnomeradio version are you using? 1.8 seems to support V4L2.
Again, make sure it isn't selecting V4L1 instead of V4L2.

> 2. Maybe Gerd's "radio" solves it, but in that case recording is
> unclear, as it is a rather primitive GUI without recording function
> implied.
> 
> > > 
> > > Can you make sure that this card will still be usable after your v4l1
> > > removal activities are finished?
> > 
> > You can easily test this by turning off the compat layer in the kernel
> > config. You should still be able to use your v4l1 app by using LD_PRELOAD=/usr/lib/v4l1compat.so.
> 
> Hmmm. See above. If I used the parametry in a wrong way please tell me.
>  
> > > In other words: What happens to this v4l1 compat code which is obviously
> > > necessary for this (and other) card(s) to run?
> > > 
> > > That's it what I haven't understood right now, so could you please be
> > > kind enough to explain that with a couple of words?
> > > 
> > > Thanks!
> > > 
> > > CS
> > > 
> > > P. S.: If you make your decision to host xawtv and other apps please do
> > > not merge hybrid applications (i. e. apps made for DVB and analogue
> > > devices) as you can find them in the xawtv 4.0 pre alpha code for
> > > example in analogue trees.
> > > Rather establish extra trees for hybrid applications please.
> > 
> > These apps will each get their own tree.
> > 
> > Regards,
> > 
> > 	Hans
> 
> This sounds excellent :)
> 
> Best Regards
> 
> Uwe
> 
> P. S.: So if I take you right the kernel compat module function does not
> hit or point to the driver itself, but rather to the application layer?
> Not easy to anticipate this as a picture in my head......

The driver is V4L2, but the kernel compat layer can translate V4L1 calls
to V4L2 calls. The libv4l1compat can do the same, but now in userspace
instead of kernelspace. What I don't really know is whether libv4l1compat
can completely replace the kernel compat layer.

Of course, the best solution is to convert the V4L1 apps to using V4L2.

Note that it would be useful if you can try to debug these apps a bit. I
would not at all be surprised if you are looking at application bugs rather
than kernel bugs.

Regards,

	Hans

-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG

Re: RFC: Phase 2/3: Move the compat code into v4l1-compat. Convert apps.

[Devin Heitmueller]

On Sat, Mar 20, 2010 at 10:14 AM, Hans Verkuil <hverkuil@xs4all.nl> wrote:
> Of course, the best solution is to convert the V4L1 apps to using V4L2.

On that topic, if I wanted to ensure that an application was not using
any V4L1 functionality, is there any easy way to do that?  For
example, can I just remove the #include "videodev.h" and fix whatever
breaks?

Right now a problem is that there could easily be situations where an
app uses V4L1 functionality without my knowledge, and it would be good
if there were an easy way to audit the app and make sure it is doing
V4L2 entirely (in fact, I had this issue in a few places with tvtime).

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com

Re: RFC: Phase 2/3: Move the compat code into v4l1-compat. Convert apps.

[Hans Verkuil]

On Saturday 20 March 2010 17:14:12 Devin Heitmueller wrote:
> On Sat, Mar 20, 2010 at 10:14 AM, Hans Verkuil <hverkuil@xs4all.nl> wrote:
> > Of course, the best solution is to convert the V4L1 apps to using V4L2.
> 
> On that topic, if I wanted to ensure that an application was not using
> any V4L1 functionality, is there any easy way to do that?  For
> example, can I just remove the #include "videodev.h" and fix whatever
> breaks?

That should do the trick, yes.

Regards,

	Hans

> Right now a problem is that there could easily be situations where an
> app uses V4L1 functionality without my knowledge, and it would be good
> if there were an easy way to audit the app and make sure it is doing
> V4L2 entirely (in fact, I had this issue in a few places with tvtime).
> 
> Devin
> 
> 

-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG

Re: RFC: Phase 2/3: Move the compat code into v4l1-compat. Convert apps.

[Hans de Goede]

Hi,

On 03/20/2010 10:21 AM, Hans Verkuil wrote:
> Hi all!
>
> The second phase that needs to be done to remove the v4l1 support from the
> kernel is that libv4l1 should replace the v4l1-compat code from the kernel.
>
> I do not know how complete the libv4l1 code is right now. I would like to
> know in particular whether the VIDIOCGMBUF/mmap behavior can be faked in
> libv4l1 if drivers do not support the cgmbuf vidioc call.
>

Yes it can, this for example already happens when using v4l1 apps with
uvcvideo (which is not possible without libv4l1).

> The third phase that can be done in parallel is to convert V4L1-only apps.
> I strongly suspect that any apps that are V4L1-only are also unmaintained.
> We have discussed before that we should set up git repositories for such
> tools (xawtv being one of the more prominent apps since it contains several
> v4l1-only console apps). Once we have maintainership, then we can convert
> these tools to v4l2 and distros and other interested parties have a place
> to send patches to.
>

As said before I wouldn't mind maintaining an xawtv git tree @ linuxtv,
assuming this tree were to be based on the 3.95 release.

Regards,

Hans

Re: RFC: Phase 2/3: Move the compat code into v4l1-compat. Convert apps.

[Hans Verkuil]

On Sunday 21 March 2010 00:14:25 Hans de Goede wrote:
> Hi,
> 
> On 03/20/2010 10:21 AM, Hans Verkuil wrote:
> > Hi all!
> >
> > The second phase that needs to be done to remove the v4l1 support from the
> > kernel is that libv4l1 should replace the v4l1-compat code from the kernel.
> >
> > I do not know how complete the libv4l1 code is right now. I would like to
> > know in particular whether the VIDIOCGMBUF/mmap behavior can be faked in
> > libv4l1 if drivers do not support the cgmbuf vidioc call.
> >
> 
> Yes it can, this for example already happens when using v4l1 apps with
> uvcvideo (which is not possible without libv4l1).

In what way does libv4l1 still depend on the kernel's v4l1 compat layer? And
what is needed to remove that dependency?

Because I think that that is the best approach.
 
> > The third phase that can be done in parallel is to convert V4L1-only apps.
> > I strongly suspect that any apps that are V4L1-only are also unmaintained.
> > We have discussed before that we should set up git repositories for such
> > tools (xawtv being one of the more prominent apps since it contains several
> > v4l1-only console apps). Once we have maintainership, then we can convert
> > these tools to v4l2 and distros and other interested parties have a place
> > to send patches to.
> >
> 
> As said before I wouldn't mind maintaining an xawtv git tree @ linuxtv,
> assuming this tree were to be based on the 3.95 release.

Mauro, do you have any objection to hosting xawtv on linuxtv? We may need
another tree later as well if we decide to split off the xawtv console tools
into a separate tree. But perhaps they would fit under v4l-utils as well,
we'll have to see.

Regards,

	Hans

-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG

Re: RFC: Phase 2/3: Move the compat code into v4l1-compat. Convert apps.

[Hans de Goede]

Hi,

On 03/22/2010 09:11 AM, Hans Verkuil wrote:
> On Sunday 21 March 2010 00:14:25 Hans de Goede wrote:
>> Hi,
>>
>> On 03/20/2010 10:21 AM, Hans Verkuil wrote:
>>> Hi all!
>>>
>>> The second phase that needs to be done to remove the v4l1 support from the
>>> kernel is that libv4l1 should replace the v4l1-compat code from the kernel.
>>>
>>> I do not know how complete the libv4l1 code is right now. I would like to
>>> know in particular whether the VIDIOCGMBUF/mmap behavior can be faked in
>>> libv4l1 if drivers do not support the cgmbuf vidioc call.
>>>
>>
>> Yes it can, this for example already happens when using v4l1 apps with
>> uvcvideo (which is not possible without libv4l1).
>
> In what way does libv4l1 still depend on the kernel's v4l1 compat layer?

It depends on some of the ioctl compatibility stuff, which lives in
drivers/media/video/v4l1-compat.c

Basically it depends on:

v4l_compat_translate_ioctl()

 From that file and on what that depends on in turn. Note that it does not
depend on v4l_compat_translate_ioctl() for all ioctl's. It handles
some of them in its own, see:
lib/libv4l1/libv4l1.c

In v4l-utils git, specifically the v4l1_ioctl() function. Note that simply
checking which one are listed in the switch case is not enough to determine
which ones are already handled by libv4l, some still call
v4l_compat_translate_ioctl() (by doing the v4l1 ioctl) and then munge the
results.

Currently it is mainly targeted and tested with webcam using apps, so no
overlay, input switching, vbi or tuning support.

Adding input switching, vbi and tuning support, should be easy I think.
Overlay has me worried as the v4l1 API does not clearly separate between
overlay and capture. Since overlay does not really work out of the box
on any distro's anyways (in my experience), I think the best thing to
do would be to just hide the overlay capability for v4l1 apps.

Note that the default: case which passes the ioctl through to libv4l2,
will end up passing v4l1 ioctl's to the kernel, as libv4l2 will pass
unknown ioctl's to the kernel unmodified.

 > And
> what is needed to remove that dependency?
>

Someone to:
- add emulation of the not yet emulated ioctl's; and
- remove the limits of not working on complex devices,
   see libv4l1.c line 295 (in v4l1_open, marked IMPROVEME */; and
- remove the dependency of some already emulated ioctl's on the
   the kernels v4l_compat_translate_ioctl(), for example
   the VIDIOCGCAP emulation calls the kernel, then overrides some
   results.


Note that all emulation needs to be re-implemented, not copied from
the kernel as the kernel is GPLv2 and libv4l1 LGPLv2+, an alternative
approach would be to find out who holds the copyrights and ask them
for permission.

> Because I think that that is the best approach.
>

Ack.

Regards,

Hans

Re: RFC: Phase 2/3: Move the compat code into v4l1-compat. Convert apps.

[Mauro Carvalho Chehab]

Hans de Goede wrote:
> Hi,
> 
> On 03/22/2010 09:11 AM, Hans Verkuil wrote:
>> On Sunday 21 March 2010 00:14:25 Hans de Goede wrote:
>>> Hi,
>>>
>>> On 03/20/2010 10:21 AM, Hans Verkuil wrote:
>>>> Hi all!
>>>>
>>>> The second phase that needs to be done to remove the v4l1 support
>>>> from the
>>>> kernel is that libv4l1 should replace the v4l1-compat code from the
>>>> kernel.
>>>>
>>>> I do not know how complete the libv4l1 code is right now. I would
>>>> like to
>>>> know in particular whether the VIDIOCGMBUF/mmap behavior can be
>>>> faked in
>>>> libv4l1 if drivers do not support the cgmbuf vidioc call.
>>>>
>>>
>>> Yes it can, this for example already happens when using v4l1 apps with
>>> uvcvideo (which is not possible without libv4l1).
>>
>> In what way does libv4l1 still depend on the kernel's v4l1 compat layer?
> 
> It depends on some of the ioctl compatibility stuff, which lives in
> drivers/media/video/v4l1-compat.c
> 
> Basically it depends on:
> 
> v4l_compat_translate_ioctl()
> 
> From that file and on what that depends on in turn. Note that it does not
> depend on v4l_compat_translate_ioctl() for all ioctl's. It handles
> some of them in its own, see:
> lib/libv4l1/libv4l1.c
> 
> In v4l-utils git, specifically the v4l1_ioctl() function. Note that simply
> checking which one are listed in the switch case is not enough to determine
> which ones are already handled by libv4l, some still call
> v4l_compat_translate_ioctl() (by doing the v4l1 ioctl) and then munge the
> results.
> 
> Currently it is mainly targeted and tested with webcam using apps, so no
> overlay, input switching, vbi or tuning support.

Probably no radio. Radio is not that different from tuning, but, as radio uses
tuning on a different way (it needs only a subset of ioctl's), you may see 
troubles on radio applications with V4L1 even when the driver works with TV with V4L1.
We had this issue when ported the radio drivers from V4L1 to V4L2: we had to
implement some dummy V4L2 ioctls, for the V4L1 compat logic to work.

> Adding input switching, vbi and tuning support, should be easy I think.
> Overlay has me worried as the v4l1 API does not clearly separate between
> overlay and capture. Since overlay does not really work out of the box
> on any distro's anyways (in my experience), I think the best thing to
> do would be to just hide the overlay capability for v4l1 apps.

The last time I tested overlay, it worked perfectly. You need to be sure
that you're not running it on a machine with Via or Sys chipsets, as those
chips have bugs with pci2pci data transfers, so the PCI quirk code disables
overlay with broken north bridge chipsets.

Cheers,
Mauro

Re: RFC: Phase 2/3: Move the compat code into v4l1-compat. Convert apps.

[Mauro Carvalho Chehab]

Hans Verkuil wrote:
> On Sunday 21 March 2010 00:14:25 Hans de Goede wrote:

>> Yes it can, this for example already happens when using v4l1 apps with
>> uvcvideo (which is not possible without libv4l1).
> 
> In what way does libv4l1 still depend on the kernel's v4l1 compat layer? And
> what is needed to remove that dependency?
> 
> Because I think that that is the best approach.

Agreed. After being sure that it will properly work with all types of app
(e. g. radio/vbi/tv/stream/record/..), we can add a features removal patch
announcing that the backport got moved to userspace and it will be removed
from kernel.
>  
>>> The third phase that can be done in parallel is to convert V4L1-only apps.
>>> I strongly suspect that any apps that are V4L1-only are also unmaintained.
>>> We have discussed before that we should set up git repositories for such
>>> tools (xawtv being one of the more prominent apps since it contains several
>>> v4l1-only console apps). Once we have maintainership, then we can convert
>>> these tools to v4l2 and distros and other interested parties have a place
>>> to send patches to.
>>>
>> As said before I wouldn't mind maintaining an xawtv git tree @ linuxtv,
>> assuming this tree were to be based on the 3.95 release.
> 
> Mauro, do you have any objection to hosting xawtv on linuxtv? We may need
> another tree later as well if we decide to split off the xawtv console tools
> into a separate tree. But perhaps they would fit under v4l-utils as well,
> we'll have to see.

Not at all. Feel free to add a git tree to all applications you want. If you have
problems, please ping me. After creating the tree(s), just send me an email with
the name of the maintainer(s) and I'll move them to the right place, enabling the
announcement hooks if needed. If possible, please get the old maintainer's ack.

With respect to the announcements, we're currently using the same mailing list
(linuxtv-commits@linuxtv.org) for all sorts of announcement: dvb-apps, v4l-utils, 
v4l-dvb.git, fixes.git v4l-dvb(hg).

If we're starting to populate the server with other trees, it may be a good idea to
split the ML into groups, or eventually into per-tree list.

Comments?


-- 

Cheers,
Mauro