[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-video
Subject:    Re: Questions on small webcam support under v4l2
From:       Taupter <taupter () gmail ! com>
Date:       2007-05-11 19:18:35
Message-ID: 200705111618.35423.taupter () gmail ! com
[Download RAW message or body]

Em Qui 10 Mai 2007, Mathieu Bouchard escreveu:

> LD_PRELOAD can redefine ioctl() in a way that keeps track of the model of
> the camera of each filehandle. But you don't even need that because what
> you really have to do is hijack SPICT and SYNC to get them to convert
> colourspaces that the app wants and that the driver won't handle, and if
> it's limited to that then there will be no need to check for any info
> other than colourspace, except if some colourspace IDs are ambiguous (e.g.
> if a device apparently YUV is really YVU and that the palette ID doesn't
> mention it).

If it's done in a library in the molds of libasound (so every interaction from 
an application developer's perspective would be done calling the library 
instead of calling those ioclts directly as we currently do) it would be a 
very valid and nice option. Doing it on a per-application basis will be a 
pita. 
The idea of adding a new FOURCC code and the specification of the format would 
be a sane way for now, but applications could be slow in adopting it. A 
non-standard format _can_ be supported, but lots of poor applications would 
scream in anguish when confronting an unknown-non-standard format for the 
first time.
I'm thinking about the application developers. Where's the best place to fix 
it, according to the current API structure?
- Inside the driver (fix once and work everywhere) or
- Chaning the spec to add a non-standard format, and propagate the handling of 
the non-standard format to a myriad of applications / multimedia backends?

> The problem I see with LD_PRELOAD is if several libraries hijack ioctl()
> (presumably because they all need to make the same ioctl fix but on
> different APIs), then one of them has priority and can't delegate to lower
> priority ioctl() that are not the libc one, unless there are mechanisms
> that I don't know about (I'm thinking that I could be using dlsym to call
> the original ioctl() from libc, but I haven't tried).

We seem to agree it's cumbersome. :)

> > The least computationally expensive one. Linus and other fellows may
> > scream and even refuse to add such "non-compliant" code, but lot of
> > device drivers aren't included in the kernel anyway (gspca, biopod, pwc,
> > vmnet, you name it), but these kernel drivers thrive just fine in the
> > wild and are even included in some distros for the end-user's sake.
>
> I believe that those distros are important in moderating the Linux team's
> opinions. I believe that the Linux team's influence in freeing driver
> source could go a much longer way if they made concessions, because the
> influence increases with popularity, and popularity increases with
> hardware compatibility. Hardware compatibility increases with several
> factors such as including the proper decompressors and decoders within the
> driver, and providing interfaces (and legal provisions) for drivers that
> can't realistically be made free within a reasonable time frame.
> I have the impression that a lot of trouble occurred because of an
> insistence that the interface of the driver to the application has to
> coïncide with the interface from the kernel to the non-kernel. This is
> just supposing that the kernel/non-kernel distinction has to stay. Here
> are two changes that might help:

I agree with you. There are some overlapping sometimes, but trying to force a 
layered approach for a development is not aways good. In the case of the 
closed-source ATI drivers and their reimplementation of agpgart it's plainly 
wrong from both a developer and a community perspectives, but in the case of 
a simple and cheap image format conversion imho it's saner and easier to do a 
little exception to the rule and do what's better to the user and to the app 
developers. Alan Cox told us in an e-mail in this thread that those 
exceptions _may_be_ justifiable if well reasoned.
The plus is the fact that we'll not add more cruft to the v4l2 api. :)

> 1. don't provide APIs to the kernel, instead provide APIs to the driver.
> The driver as a whole, is whatever the application ought to be seeing: it
> doesn't have anything to do with what is considered to be safe or clean in
> kernel mode. A driver can be a kernel module and/or a (part of) a library.

It's the libasound-like approach that may arrive with v4l3. Time will tell.

> 2. provide more means for user space to behave like kernel modules. Make
> this mostly just a matter of performance rather than of functionality, as
> much as possible. The goal here is to get more advantages of microkernels.
> Microkernels might be slow (maybe not even anymore), but they do erase
> annoying kernel/non-kernel distinctions.

Another possibility, but afaics it would only work fine with a library model 
that would hide the gory details from the application developer.
Maybe a fuse-like approach could fit. But I have no idea about how to code it.

> > In my humble opinion, what V4L2 really lacks AFAIK is a standard,
> > project-supported, unit test
>
> Yes, unit-tests are quite worth it, especially because the same batch of
> tests can test many different drivers.

I'm willing and able to code it. I'm waiting for Mauro's green light. ;)


Best regards,


Cláudio da Silveira Pinheiro
Kopete developer
+55-85-8702-0060

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list
[prev in list] [next in list] [prev in thread] [next in thread]