RFC: Drop V4L1 support in V4L2 drivers

RFC: Drop V4L1 support in V4L2 drivers

[Hans Verkuil]

Hi all,

V4L1 support has been marked as scheduled for removal for a long time. The
deadline for that in the feature-removal-schedule.txt file was July 2009.

I think it is time that we remove the V4L1 compatibility support from V4L2
drivers for 2.6.35.

It would help with the videobuf cleanup as well, but that's just a bonus.

If no one objects, then I can prepare a patch series for this.

Regards,

        Hans


-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom

Re: RFC: Drop V4L1 support in V4L2 drivers

[Laurent Pinchart]

On Friday 19 March 2010 08:59:08 Hans Verkuil wrote:
> Hi all,
> 
> V4L1 support has been marked as scheduled for removal for a long time. The
> deadline for that in the feature-removal-schedule.txt file was July 2009.
> 
> I think it is time that we remove the V4L1 compatibility support from V4L2
> drivers for 2.6.35.

Do you mean just removing V4L1-specific code from V4L2 drivers, or removing 
the V4L1 compatibility layer completely ?

> It would help with the videobuf cleanup as well, but that's just a bonus.

Do we still have V4L1-only drivers that use videobuf ?

> If no one objects, then I can prepare a patch series for this.

-- 
Regards,

Laurent Pinchart

Re: RFC: Drop V4L1 support in V4L2 drivers

[Hans Verkuil]

> On Friday 19 March 2010 08:59:08 Hans Verkuil wrote:
>> Hi all,
>>
>> V4L1 support has been marked as scheduled for removal for a long time.
>> The
>> deadline for that in the feature-removal-schedule.txt file was July
>> 2009.
>>
>> I think it is time that we remove the V4L1 compatibility support from
>> V4L2
>> drivers for 2.6.35.
>
> Do you mean just removing V4L1-specific code from V4L2 drivers, or
> removing
> the V4L1 compatibility layer completely ?

The compat layer as well. So the only V4L1 code left is that for V4L1-only
drivers.

This means that V4L2 drivers can only be used by V4L2-aware applications
and can no longer be accessed by V4L1-only applications.

>> It would help with the videobuf cleanup as well, but that's just a
>> bonus.
>
> Do we still have V4L1-only drivers that use videobuf ?

No V4L1-only drivers use videobuf, but videobuf has support for the V4L1
compat support in V4L2 drivers (the cgmbuf ioctl). So when we remove the
compat support, then that videobuf code can be removed as well.

Regards,

       Hans

>
>> If no one objects, then I can prepare a patch series for this.
>
> --
> Regards,
>
> Laurent Pinchart
>


-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom

Re: RFC: Drop V4L1 support in V4L2 drivers

[Laurent Pinchart]

On Friday 19 March 2010 09:46:02 Hans Verkuil wrote:
> > On Friday 19 March 2010 08:59:08 Hans Verkuil wrote:
> >> Hi all,
> >> 
> >> V4L1 support has been marked as scheduled for removal for a long time.
> >> The deadline for that in the feature-removal-schedule.txt file was July
> >> 2009.
> >> 
> >> I think it is time that we remove the V4L1 compatibility support from
> >> V4L2 drivers for 2.6.35.
> > 
> > Do you mean just removing V4L1-specific code from V4L2 drivers, or
> > removing the V4L1 compatibility layer completely ?
> 
> The compat layer as well. So the only V4L1 code left is that for V4L1-only
> drivers.
> 
> This means that V4L2 drivers can only be used by V4L2-aware applications
> and can no longer be accessed by V4L1-only applications.
> 
> >> It would help with the videobuf cleanup as well, but that's just a bonus.
> > 
> > Do we still have V4L1-only drivers that use videobuf ?
> 
> No V4L1-only drivers use videobuf, but videobuf has support for the V4L1
> compat support in V4L2 drivers (the cgmbuf ioctl). So when we remove the
> compat support, then that videobuf code can be removed as well.

In that case, please go for it :-)

-- 
Regards,

Laurent Pinchart

Re: RFC: Drop V4L1 support in V4L2 drivers

[Markus Rechberger]

On Fri, Mar 19, 2010 at 9:46 AM, Hans Verkuil <hverkuil@xs4all.nl> wrote:
>
>> On Friday 19 March 2010 08:59:08 Hans Verkuil wrote:
>>> Hi all,
>>>
>>> V4L1 support has been marked as scheduled for removal for a long time.
>>> The
>>> deadline for that in the feature-removal-schedule.txt file was July
>>> 2009.
>>>
>>> I think it is time that we remove the V4L1 compatibility support from
>>> V4L2
>>> drivers for 2.6.35.
>>
>> Do you mean just removing V4L1-specific code from V4L2 drivers, or
>> removing
>> the V4L1 compatibility layer completely ?
>
> The compat layer as well. So the only V4L1 code left is that for V4L1-only
> drivers.
>

I'm against this we have customers using the compat layer.
Aside of that the compat layer doesn't hurt anyone, newer more serious
applications
are written with v4l2 only actually.

> This means that V4L2 drivers can only be used by V4L2-aware applications
> and can no longer be accessed by V4L1-only applications.
>
>>> It would help with the videobuf cleanup as well, but that's just a
>>> bonus.
>>
>> Do we still have V4L1-only drivers that use videobuf ?
>
> No V4L1-only drivers use videobuf, but videobuf has support for the V4L1
> compat support in V4L2 drivers (the cgmbuf ioctl). So when we remove the
> compat support, then that videobuf code can be removed as well.
>

that's just a bad implementation then and just should be fixed up the compat
layer can handle this quite elegant.

-Markus

Re: RFC: Drop V4L1 support in V4L2 drivers

[Mauro Carvalho Chehab]

Hans Verkuil wrote:
> Hi all,
> 
> V4L1 support has been marked as scheduled for removal for a long time. The
> deadline for that in the feature-removal-schedule.txt file was July 2009.

As reference, this is what's written there:

What:   Video4Linux API 1 ioctls and from Video devices.
When:   July 2009
Files:  include/linux/videodev.h
Check:  include/linux/videodev.h
Why:    V4L1 AP1 was replaced by V4L2 API during migration from 2.4 to 2.6
        series. The old API have lots of drawbacks and don't provide enough
        means to work with all video and audio standards. The newer API is
        already available on the main drivers and should be used instead.
        Newer drivers should use v4l_compat_translate_ioctl function to handle
        old calls, replacing to newer ones.
        Decoder iocts are using internally to allow video drivers to
        communicate with video decoders. This should also be improved to allow
        V4L2 calls being translated into compatible internal ioctls.
        Compatibility ioctls will be provided, for a while, via 
        v4l1-compat module. 
Who:    Mauro Carvalho Chehab <mchehab@infradead.org>


> 
> I think it is time that we remove the V4L1 compatibility support from V4L2
> drivers for 2.6.35.
> 
> It would help with the videobuf cleanup as well, but that's just a bonus.
> 
> If no one objects, then I can prepare a patch series for this.

With respect to V4L1, there are some aspects to consider:

1) The removal (or conversion to V4L2) of the existing V4L1 drivers. I think this
is a good thing. Hans already said he wants to convert a few more drivers to V4L2.
So, we need to check with him if 2.6.35 is feasible. This means that he has something
like 5-6 weeks to convert, in order to get the next window.

2) The removal of V4L1 compatibility layer. If you take a look at the
feature-removal-schedule.txt annoncement, it talks about removing the V4L1 drivers,
not about removing the V4L1 compat layer: it mentions only videodev.h removal from
userspace API, and says that V4L1 compat will exist "for a while". What I'm meant
to do with that announcement text is that, once removed all V4L1 drivers, we'll replace
the V4L1 removal announcement with a V4L1 compat layer announcement, giving app developers
some time to fix their userspace apps. So, assuming that we'll remove V4L1 drivers on
2.6.35, we should wait at least to 2.6.36 before removing V4L1 compat.

3) The removal of V4L1 means that the existing applications should not try to include 
videodev.h with newer kernels or their compilations will break (easy to fix, but better
to remind application developers that may be reading this thread). Also, the removal of 
V4L1 compat means that all V4L1 only applications will stop working. What's the current
status of webcam/TV/stream/radio/videotext/vbi applications? Just yesterday, somebody
reported me a problem with radio crashing at the V4L1 compat layer. It seemed that maybe
not all radio apps got converted. So, before dropping compat layer support, we should
double check what apps will break.

-- 

Cheers,
Mauro

Re: RFC: Drop V4L1 support in V4L2 drivers

[Mauro Carvalho Chehab]

Hans Verkuil wrote:

>> Do we still have V4L1-only drivers that use videobuf ?
> 
> No V4L1-only drivers use videobuf, but videobuf has support for the V4L1
> compat support in V4L2 drivers (the cgmbuf ioctl). So when we remove the
> compat support, then that videobuf code can be removed as well.

We shouldn't justify the removal of an userspace API due to an internal
code cleanup.

The original reason for the V4L1 API removal is that its design were never
extended to support all world video standards (yet, its non-RDS radio
support is just as fine as V4L2 API).

The fact is that V4L1 API stopped in the time, while V4L2 is live. So, 
V4L1 didn't followed 10 years of evolution that happened on media devices.

It would be probably simpler to just extend V4L1 API than to replace it to
a new one, but now we have to deal with both API's.

Due to the lack of features, the V4L1 drivers were gradually converted to V4L2.
This makes sense, since they can provide more features to userspace, like
the support for read/mmap/user mmap streaming, the fine-grained video format
support, the video format and fps enumeration and more userspace controls.

The V4L1 drivers that lasts are the ones without maintainers and probably without
a large users base. So, basically legacy hardware. So, their removals make sense.

After the driver removal, the last V4L1 vestige is the V4L1 compat layer removal.
So, what are the reasons to remove this layer?

I can think on a few technical reasons:
- V4L1 API emulation in kernel is not perfect. There are some known bugs, basically due to
the lack of a stateful layer emulation. So, it is possible, for example, that userspace
selects one video standard on a set and receive another on a get. For example, if userspace
tries to set VIDEO_PALETTE_YUV422, a subsequent get will return VIDEO_PALETTE_YUYV.
- V4L1 API lacks functionality. So, userspace applications using it would have a limited
control of the driver;
- Code cleanup;
- Lack of developers interested on maintaining V4L1 compat layer.

On the other hand, removing it may break applications that works fine with V4L1 emulation.
IMO, none of the above reasons are strong enough to justify prevent users to properly
use the hardware.

So, in order to remove this feature, we should be sure that the existing open-source 
V4L2 applications will cover all usage cases: teletext, radio, vbi, tv, webcam, stream
capture, text UI, graphical UI's (qt/gtk), .... If something is not covered, someone
has to port an existing application to V4L2 or to write/maintain a replacement application.

So, the main issue to remove V4L1 compat is: are all cases properly covered?

Comments?

-- 

Cheers,
Mauro

Re: RFC: Drop V4L1 support in V4L2 drivers

[Andy Walls]

On Fri, 2010-03-19 at 09:46 +0100, Hans Verkuil wrote:
> > On Friday 19 March 2010 08:59:08 Hans Verkuil wrote:
> >> Hi all,
> >>
> >> V4L1 support has been marked as scheduled for removal for a long time.
> >> The
> >> deadline for that in the feature-removal-schedule.txt file was July
> >> 2009.
> >>
> >> I think it is time that we remove the V4L1 compatibility support from
> >> V4L2
> >> drivers for 2.6.35.
> >

> This means that V4L2 drivers can only be used by V4L2-aware applications
> and can no longer be accessed by V4L1-only applications.

>From user reports I've seen lately, it looks like Debian (or some Debian
derivative) is not packaging v4l2-ctl, etc. but only the older v4lctl
and related utilities.  Can anyone verify this?

If that is so, I anticipate end user complaints coming in.  I wouldn't
cut the V4L1 inetrface out until we've got v4l2-ctl and friends in a
repository that is easily packaged as stand alone utils - separate from
the v4l-dvb driver tree.  And perhaps a link on the webpage for
packagers and end users to find the v4l2 utils would head off some
complaints.

Regards,
Andy

Re: RFC: Drop V4L1 support in V4L2 drivers

[David Ellingsworth]

On Fri, Mar 19, 2010 at 9:47 AM, Mauro Carvalho Chehab
<mchehab@redhat.com> wrote:
> The V4L1 drivers that lasts are the ones without maintainers and probably without
> a large users base. So, basically legacy hardware. So, their removals make sense.
>

In many ways the above statement is a catch 22. Most, if not all the
v4l1 drivers are currently broken or unmaintained. However, this does
not mean there are users who would not be using these drivers if they
actually worked or had been properly maintained. I know this to be a
fact of the ibmcam driver. It is both broken and unmaintained. Because
of this I'm sure no one is currently using it. I happen to have a USB
camera which is supposedly supported by the ibmcam driver.
Unfortunately, I have not the time nor expertise needed to
update/fix/replace this driver, though I have previously tried. If
someone on this list is willing to collaborate with me to make a
functional v4l2 driver to replace the existing ibmcam driver, I'd be
more than willing to expend more time and energy in doing so.
Hopefully someday I'll actually be able to use the camera that I own,
considering as is it barely works under Windows.

Regards,

David Ellingsworth

Re: RFC: Drop V4L1 support in V4L2 drivers

[Mauro Carvalho Chehab]

David Ellingsworth wrote:
> On Fri, Mar 19, 2010 at 9:47 AM, Mauro Carvalho Chehab
> <mchehab@redhat.com> wrote:
>> The V4L1 drivers that lasts are the ones without maintainers and probably without
>> a large users base. So, basically legacy hardware. So, their removals make sense.
>>
> 
> In many ways the above statement is a catch 22. Most, if not all the
> v4l1 drivers are currently broken or unmaintained. However, this does
> not mean there are users who would not be using these drivers if they
> actually worked or had been properly maintained. I know this to be a
> fact of the ibmcam driver. It is both broken and unmaintained. Because
> of this I'm sure no one is currently using it.

It makes sense. However, considering that no new V4L1 driver is committed
since 2006, this means that those are old drivers for old hardware.

> I happen to have a USB
> camera which is supposedly supported by the ibmcam driver.

In the specific case of ibmcam, we had only 10 commits on -hg since its
addition, back in 2006.

Just using it as an example about the remaining drivers, for today's hardware,
an ibmusb model 3 webcam has 640x480x3fps, according to his driver. Other models
have QCIF or QVGA as their maximum resolution. I can easily buy a 640x480x30fps
camera (or even something better than that) for US$12,00 on a close shopping.

So, even if the driver would be 100% functional, I doubt that you would find too
many users of this webcam, simply because people would need a faster frame rate
or wanted a higher resolution.

> Unfortunately, I have not the time nor expertise needed to
> update/fix/replace this driver, though I have previously tried. If
> someone on this list is willing to collaborate with me to make a
> functional v4l2 driver to replace the existing ibmcam driver, I'd be
> more than willing to expend more time and energy in doing so.
> Hopefully someday I'll actually be able to use the camera that I own,
> considering as is it barely works under Windows.

I agree that it would be interesting to port it to V4L2, instead of just
dropping it. Maybe Hans Geode or someone else with some spare time
could help you on this task.

-- 

Cheers,
Mauro

Re: RFC: Drop V4L1 support in V4L2 drivers

[David Ellingsworth]

On Fri, Mar 19, 2010 at 1:43 PM, Mauro Carvalho Chehab
<mchehab@redhat.com> wrote:
> David Ellingsworth wrote:
>> On Fri, Mar 19, 2010 at 9:47 AM, Mauro Carvalho Chehab
>> <mchehab@redhat.com> wrote:
>>> The V4L1 drivers that lasts are the ones without maintainers and probably without
>>> a large users base. So, basically legacy hardware. So, their removals make sense.
>>>
>>
>> In many ways the above statement is a catch 22. Most, if not all the
>> v4l1 drivers are currently broken or unmaintained. However, this does
>> not mean there are users who would not be using these drivers if they
>> actually worked or had been properly maintained. I know this to be a
>> fact of the ibmcam driver. It is both broken and unmaintained. Because
>> of this I'm sure no one is currently using it.
>
> It makes sense. However, considering that no new V4L1 driver is committed
> since 2006, this means that those are old drivers for old hardware.
>
>> I happen to have a USB
>> camera which is supposedly supported by the ibmcam driver.
>
> In the specific case of ibmcam, we had only 10 commits on -hg since its
> addition, back in 2006.
>
> Just using it as an example about the remaining drivers, for today's hardware,
> an ibmusb model 3 webcam has 640x480x3fps, according to his driver. Other models
> have QCIF or QVGA as their maximum resolution. I can easily buy a 640x480x30fps
> camera (or even something better than that) for US$12,00 on a close shopping.

The limitation on the frame rate within the driver is not an issue
with the camera itself per-say. The camera I have supports
640x480x30fps but the ibmcam driver lacks support for the video mode
used to achieve that rate. Specifically speaking, the camera uses a
proprietary compressed image format that the current v4l1 ibmcam
driver does not support for several reasons. First and foremost, the
original author stated that he did not have time to reverse engineer
the compressed format. Second even if he had, the code to do so
doesn't belong in the driver itself.

Yes it is an old camera, but that does not mean there aren't people
out there who still own cameras which would otherwise be usable if the
driver worked. And sure people could just buy another camera.. but why
replace hardware that's obviously not broken?

>
> So, even if the driver would be 100% functional, I doubt that you would find too
> many users of this webcam, simply because people would need a faster frame rate
> or wanted a higher resolution.
>
>> Unfortunately, I have not the time nor expertise needed to
>> update/fix/replace this driver, though I have previously tried. If
>> someone on this list is willing to collaborate with me to make a
>> functional v4l2 driver to replace the existing ibmcam driver, I'd be
>> more than willing to expend more time and energy in doing so.
>> Hopefully someday I'll actually be able to use the camera that I own,
>> considering as is it barely works under Windows.
>
> I agree that it would be interesting to port it to V4L2, instead of just
> dropping it. Maybe Hans Geode or someone else with some spare time
> could help you on this task.
>
> --
>
> Cheers,
> Mauro
>

Re: RFC: Drop V4L1 support in V4L2 drivers

[Devin Heitmueller]

On Fri, Mar 19, 2010 at 2:00 PM, David Ellingsworth
<david@identd.dyndns.org> wrote:
> Yes it is an old camera, but that does not mean there aren't people
> out there who still own cameras which would otherwise be usable if the
> driver worked. And sure people could just buy another camera.. but why
> replace hardware that's obviously not broken?

Because of the cost of keeping a driver in the tree for an old piece
of hardware that almost nobody has, where there is no developer
willing to maintain it, at the cost of preventing removal of a bunch
of old common infrastructure which increases the maintenance cost of
all the drivers that people do care about.

In a perfect world, it would be great to support every piece of
hardware under the sun until the end of time.  In reality though, with
limited developer resources, we sometimes have to decided that
supporting certain archaic hardware that isn't popular "just isn't
worth it".

Removing all the old V4L1 cruft will make currently maintained drivers
cleaner, faster and simpler to understand and implement, and less
likely to have bugs.

Devin

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

Re: RFC: Drop V4L1 support in V4L2 drivers

[Hans de Goede]

Hi,

On 03/19/2010 09:46 AM, Hans Verkuil wrote:
>
>> On Friday 19 March 2010 08:59:08 Hans Verkuil wrote:
>>> Hi all,
>>>
>>> V4L1 support has been marked as scheduled for removal for a long time.
>>> The
>>> deadline for that in the feature-removal-schedule.txt file was July
>>> 2009.
>>>
>>> I think it is time that we remove the V4L1 compatibility support from
>>> V4L2
>>> drivers for 2.6.35.
>>
>> Do you mean just removing V4L1-specific code from V4L2 drivers, or
>> removing
>> the V4L1 compatibility layer completely ?
>
> The compat layer as well. So the only V4L1 code left is that for V4L1-only
> drivers.
>
> This means that V4L2 drivers can only be used by V4L2-aware applications
> and can no longer be accessed by V4L1-only applications.
>

I'm fine with removing the v4l1 compat code inside the drivers, but please
let the compat code live for a while, there are apps out there depending
on it.

Now most of those apps should be using libv4l1, but libv4l depends on
the compat layer! (but not on the driver specific v4l1 compat bits, only
on the generic compat layer).

>>> It would help with the videobuf cleanup as well, but that's just a
>>> bonus.
>>
>> Do we still have V4L1-only drivers that use videobuf ?
>
> No V4L1-only drivers use videobuf, but videobuf has support for the V4L1
> compat support in V4L2 drivers (the cgmbuf ioctl). So when we remove the
> compat support, then that videobuf code can be removed as well.

Removing that bit is fine (from a libv4l1 pov). libv4l1 is written to
work with v4l2 drivers which offer no assistance what so ever (such as
uvcvideo), but it does depend on the generic ioctl compatibility stuff.

Fixing this in libv4l1 is not hard but:
1) Requires me to have some time for it
2) Takes a while to get picked up by distros

So may I suggest that:

1) If not done already v4l1 compat gets turned into a clearly marked
    kernel config option
2) This option gets marked as deprecated
3) It gets scheduled for removal (so added to the feature removal schedule
    txt file.

Regards,

Hans

Re: RFC: Drop V4L1 support in V4L2 drivers

[VDR User]

Keeping v4l1 because some guys are still using some ancient setup is
not a good reason.  Keeping v4l1 because some app devs still haven't
bothered to update their apps is not a good reason, especially given
the amount of time they've had to complete this task.  Keeping v4l1
because package maintainers haven't bothered to update their packages
is not a good reason.

To put it simply, v4l1 is just dragging along dead weight.  It has
been replaced by something better and there's no reasonable excuse to
keep dragging it along.  There will always be someone complaining
because there will always be someone neglecting to make the transition
until the last possible second or resisting change even when it's for
the better.

App devs that haven't bothered to update -- you've had plenty of time
to get it done.  If you app breaks, it's not v4l's fault at this
point.

Users still on ancient hardware -- consider updating to cheap newer
alternatives but don't expect v4l to be held back because you refuse
to move forward.  Or politely request old drivers be converted.

Package maintainers -- if it's too much of a hassle to keep your
package(s) updated, consider giving that responsibility to someone
else.

The points made in this thread make it pretty obvious that dumping
v4l1 altogether is easily for the best and has only very minimal
negative impact.  And the negatives aren't anything that can't be
resolved completely with a little commitment to do so.

Best regards,
Derek

Re: RFC: Drop V4L1 support in V4L2 drivers

[Hans de Goede]

Hi,

On 03/19/2010 04:49 PM, David Ellingsworth wrote:
> On Fri, Mar 19, 2010 at 9:47 AM, Mauro Carvalho Chehab
> <mchehab@redhat.com>  wrote:
>> The V4L1 drivers that lasts are the ones without maintainers and probably without
>> a large users base. So, basically legacy hardware. So, their removals make sense.
>>
>
> In many ways the above statement is a catch 22. Most, if not all the
> v4l1 drivers are currently broken or unmaintained.

Ack, which is why I've been working actively on moving them all over to
gspca, but I need hardware access for that, see below.

However this thread is about removing support for v4l1 applications, and
there are actually still quite a few v4l1 apps out there, so we should
not do that!

 > However, this does
> not mean there are users who would not be using these drivers if they
> actually worked or had been properly maintained. I know this to be a
> fact of the ibmcam driver. It is both broken and unmaintained. Because
> of this I'm sure no one is currently using it. I happen to have a USB
> camera which is supposedly supported by the ibmcam driver.
> Unfortunately, I have not the time nor expertise needed to
> update/fix/replace this driver, though I have previously tried. If
> someone on this list is willing to collaborate with me to make a
> functional v4l2 driver to replace the existing ibmcam driver, I'd be
> more than willing to expend more time and energy in doing so.

Great! I've bene looking for someone with such a cam. As you may know
I've been slowly porting over all the remaining v4l1 usb webcam drivers
to gspca (removing a lot of code duplication and making them v4l2 drivers).

By far the easiest way to get the driver for this camera converted to
a gspca using v4l2 driver is to send it to me, would you be willing to
do that ?

Regards,

Hans

Re: RFC: Drop V4L1 support in V4L2 drivers

[Hans de Goede]

Hi,

On 03/19/2010 02:01 PM, Mauro Carvalho Chehab wrote:
> Hans Verkuil wrote:
>> Hi all,
>>
>> V4L1 support has been marked as scheduled for removal for a long time. The
>> deadline for that in the feature-removal-schedule.txt file was July 2009.
>
> As reference, this is what's written there:
>
> What:   Video4Linux API 1 ioctls and from Video devices.
> When:   July 2009
> Files:  include/linux/videodev.h
> Check:  include/linux/videodev.h
> Why:    V4L1 AP1 was replaced by V4L2 API during migration from 2.4 to 2.6
>          series. The old API have lots of drawbacks and don't provide enough
>          means to work with all video and audio standards. The newer API is
>          already available on the main drivers and should be used instead.
>          Newer drivers should use v4l_compat_translate_ioctl function to handle
>          old calls, replacing to newer ones.
>          Decoder iocts are using internally to allow video drivers to
>          communicate with video decoders. This should also be improved to allow
>          V4L2 calls being translated into compatible internal ioctls.
>          Compatibility ioctls will be provided, for a while, via
>          v4l1-compat module.
> Who:    Mauro Carvalho Chehab<mchehab@infradead.org>
>
>
>>
>> I think it is time that we remove the V4L1 compatibility support from V4L2
>> drivers for 2.6.35.
>>
>> It would help with the videobuf cleanup as well, but that's just a bonus.
>>
>> If no one objects, then I can prepare a patch series for this.
>
> With respect to V4L1, there are some aspects to consider:
>
> 1) The removal (or conversion to V4L2) of the existing V4L1 drivers. I think this
> is a good thing. Hans already said he wants to convert a few more drivers to V4L2.
> So, we need to check with him if 2.6.35 is feasible. This means that he has something
> like 5-6 weeks to convert, in order to get the next window.
>

Heh, I might be able to get around to port over se401 to gspca before then, for
the other ones: -ENEEDHARDWARE.

> 2) The removal of V4L1 compatibility layer. If you take a look at the
> feature-removal-schedule.txt annoncement, it talks about removing the V4L1 drivers,
> not about removing the V4L1 compat layer: it mentions only videodev.h removal from
> userspace API, and says that V4L1 compat will exist "for a while". What I'm meant
> to do with that announcement text is that, once removed all V4L1 drivers, we'll replace
> the V4L1 removal announcement with a V4L1 compat layer announcement, giving app developers
> some time to fix their userspace apps. So, assuming that we'll remove V4L1 drivers on
> 2.6.35, we should wait at least to 2.6.36 before removing V4L1 compat.
>
> 3) The removal of V4L1 means that the existing applications should not try to include
> videodev.h with newer kernels or their compilations will break (easy to fix, but better
> to remind application developers that may be reading this thread). Also, the removal of
> V4L1 compat means that all V4L1 only applications will stop working. What's the current
> status of webcam/TV/stream/radio/videotext/vbi applications? Just yesterday, somebody
> reported me a problem with radio crashing at the V4L1 compat layer. It seemed that maybe
> not all radio apps got converted. So, before dropping compat layer support, we should
> double check what apps will break.
>

I think the best way forward here is making libv4l1 completely independ of the kernel
v4l1 compat layer. This isn't to hard to do, I could even copy over the necessary bits
to compile v4l1 apps from linux/videodev.h to libv4l1.h, then the kernel can completely
drop v4l1 compat for v4l2 drivers, but this will need some time...

Regards,

Hans

Re: RFC: Drop V4L1 support in V4L2 drivers

[Mauro Carvalho Chehab]

Hans de Goede wrote:

>> 3) The removal of V4L1 means that the existing applications should not
>> try to include
>> videodev.h with newer kernels or their compilations will break (easy
>> to fix, but better
>> to remind application developers that may be reading this thread).
>> Also, the removal of
>> V4L1 compat means that all V4L1 only applications will stop working.
>> What's the current
>> status of webcam/TV/stream/radio/videotext/vbi applications? Just
>> yesterday, somebody
>> reported me a problem with radio crashing at the V4L1 compat layer. It
>> seemed that maybe
>> not all radio apps got converted. So, before dropping compat layer
>> support, we should
>> double check what apps will break.
>>
> 
> I think the best way forward here is making libv4l1 completely independ
> of the kernel
> v4l1 compat layer. This isn't to hard to do, I could even copy over the
> necessary bits
> to compile v4l1 apps from linux/videodev.h to libv4l1.h, then the kernel
> can completely
> drop v4l1 compat for v4l2 drivers, but this will need some time...

You should notice that it is not just video stream here: you need to consider
also radio, vbi/teletext and tuning. The easiest way seems to start migrating
the v4l1 compat to userspace.

On the other hand, what applications are we talking about? Maybe it is just easier
to write a document pointing to an alternative application for each case.

-- 

Cheers,
Mauro

Re: RFC: Drop V4L1 support in V4L2 drivers

[Mauro Carvalho Chehab]

David Ellingsworth wrote:
> On Fri, Mar 19, 2010 at 1:43 PM, Mauro Carvalho Chehab
> <mchehab@redhat.com> wrote:
>> David Ellingsworth wrote:
>>> On Fri, Mar 19, 2010 at 9:47 AM, Mauro Carvalho Chehab
>>> <mchehab@redhat.com> wrote:
>>>> The V4L1 drivers that lasts are the ones without maintainers and probably without
>>>> a large users base. So, basically legacy hardware. So, their removals make sense.
>>>>
>>> In many ways the above statement is a catch 22. Most, if not all the
>>> v4l1 drivers are currently broken or unmaintained. However, this does
>>> not mean there are users who would not be using these drivers if they
>>> actually worked or had been properly maintained. I know this to be a
>>> fact of the ibmcam driver. It is both broken and unmaintained. Because
>>> of this I'm sure no one is currently using it.
>> It makes sense. However, considering that no new V4L1 driver is committed
>> since 2006, this means that those are old drivers for old hardware.
>>
>>> I happen to have a USB
>>> camera which is supposedly supported by the ibmcam driver.
>> In the specific case of ibmcam, we had only 10 commits on -hg since its
>> addition, back in 2006.
>>
>> Just using it as an example about the remaining drivers, for today's hardware,
>> an ibmusb model 3 webcam has 640x480x3fps, according to his driver. Other models
>> have QCIF or QVGA as their maximum resolution. I can easily buy a 640x480x30fps
>> camera (or even something better than that) for US$12,00 on a close shopping.
> 
> The limitation on the frame rate within the driver is not an issue
> with the camera itself per-say. The camera I have supports
> 640x480x30fps but the ibmcam driver lacks support for the video mode
> used to achieve that rate. Specifically speaking, the camera uses a
> proprietary compressed image format that the current v4l1 ibmcam
> driver does not support for several reasons.

Ah, ok.

> First and foremost, the
> original author stated that he did not have time to reverse engineer
> the compressed format. Second even if he had, the code to do so
> doesn't belong in the driver itself.

As we're just talking about V4L1->V4L2 conversion, even if someone convert
or fix the driver, this issue will remain. Only finding someone to maintain
it, this issue will be fixed.
> 
> Yes it is an old camera, but that does not mean there aren't people
> out there who still own cameras which would otherwise be usable if the
> driver worked. And sure people could just buy another camera.. but why
> replace hardware that's obviously not broken?

If you want/need a webcam in Linux, have a broken driver, an old hardware
and a new hardware costs less than 15 bucks, why not just buy a new camera?
Many users likely did it already with the remaining V4L1 drivers. With less
users/developers running Linux with this hardware, less chances that someone
would take the maintainership of the driver and fix/convert it.

We're talking about removal of those drivers for about two years, and nobody,
except for the existing developers that found some way to buy legacy used
hardware sent patches.

Anyway, I see your point. 

The better alternative would be if someone could borrow or donate hardware 
to Hans de Goede and/or another developers that may be interested and let 
them convert the driver and hopefully break the proprietary protocols, 
implementing them at libv4l.

Cheers,
Mauro

Re: RFC: Drop V4L1 support in V4L2 drivers

[hermann pitton]

Am Freitag, den 19.03.2010, 12:04 -0700 schrieb VDR User:
> Keeping v4l1 because some guys are still using some ancient setup is
> not a good reason.  Keeping v4l1 because some app devs still haven't
> bothered to update their apps is not a good reason, especially given
> the amount of time they've had to complete this task.  Keeping v4l1
> because package maintainers haven't bothered to update their packages
> is not a good reason.
> 
> To put it simply, v4l1 is just dragging along dead weight.  It has
> been replaced by something better and there's no reasonable excuse to
> keep dragging it along.  There will always be someone complaining
> because there will always be someone neglecting to make the transition
> until the last possible second or resisting change even when it's for
> the better.
> 
> App devs that haven't bothered to update -- you've had plenty of time
> to get it done.  If you app breaks, it's not v4l's fault at this
> point.
> 
> Users still on ancient hardware -- consider updating to cheap newer
> alternatives but don't expect v4l to be held back because you refuse
> to move forward.  Or politely request old drivers be converted.
> 
> Package maintainers -- if it's too much of a hassle to keep your
> package(s) updated, consider giving that responsibility to someone
> else.
> 
> The points made in this thread make it pretty obvious that dumping
> v4l1 altogether is easily for the best and has only very minimal
> negative impact.  And the negatives aren't anything that can't be
> resolved completely with a little commitment to do so.
> 
> Best regards,
> Derek

If you are so clear and up to date on all,

please share your knowledge with us and tell at least, which vbi/cc and
radio app would still work after your proposal?