On Mon, Apr 16, 2001 at 12:25:52PM -0700, Bill Dirks wrote:
> I've made a first swing at separating out the compatibility layer in
> videodevX.
> ftp://ftp.thedirks.org/pub/v4l2/kernel2.4/videodevX/
> videodevX-20010416.tgz
I´ll have a look.
> > Why register? The driver can simply call the functions in the helper
> > module.
>
> More flexible, cleaner, I guess. It can be loaded and unloaded; doesn't
> have to be made a compile-time option in to the drivers. It can be
> called from videodevX transparent to the driver.
I'd like to avoid passing everything throuth videodevX. And I don't think
it is that good to try to hide v4l1 completely from the driver, it doesn't
work completely anyway. Look for example at the mmap issue: The driver
has to handle v4l1 and v4l2 mappings in different ways (by looking at
the V4L2_BUF_REQ_CONTIG flag).
IMHO a driver should be able to handle some or all v4l1 compatibility
issues itself.
> Overlay (preview) support needs
> much expansion for the set-top box market too. I started working on it
> here: http://www.thedirks.org/v4l2/proposed/overlay.htm
> (I've got to tweak the terminology, where you see "plane" think
> "overlay" or "visual".)
why a v4l2 interface for that? Setting up a overlay IMHO does belong
into the X-Server (useable throuth the Xvideo Extention) or into the
framebuffer driver.
> > v4l has been _the_ interface for years. And it probably takes
> > at least one more year until v4l2 shows up in a stable kernel
> > (2.6). I don't think we can phase out v4l1 ...
>
> Well, I meant phase it out three years later, or somesuch.
Maybe, we will see.
Gerd
_______________________________________________
Video4linux-list mailing list
[EMAIL PROTECTED]
https://listman.redhat.com/mailman/listinfo/video4linux-list
