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
