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

[Hans de Goede <hdegoede@redhat.com>]

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