Hello Justin, > > But I have a question concerning the so-called > > "compatibility layer": can this piece > > of code, that does not run with most v4l1-specific > > code anyway, be simply removed? > > Well, it's not a "so-called" compatibility layer. It is a correct V4L > API implementation. Unfortunately, most apps out there aren't v4l apps, > but bttv apps pretending to be v4l apps. These apps rely on some driver > specifics that are not guaranteed by the v4l API. Sure. I have not seen any v4l application, that did not rely on some bttv specific stuff. Of course this is due to the very thin v4l documentation, too. That's why I abandoned my v4l driver and switched over to vl42 instead. For bttv users there is no reason to switch over to v4l2, but for all other drivers, "compatibility" with bttv is a "must have". > I'm not going to dig that far back in the archives, but I think the > origin of the compatibility layer (and later vdeodevX), was the > requirement for software compatibility when v4l2 made it into the > kernel. I'm pretty sure (Alan: correct me if I'm wrong) that these > requirements initially came from Alan Cox. Perhaps he could put in a > word or two here on his ideas? As far as I know: because Bill Dirks designed v4l2 as a replacement for v4l, Alan Cox said that before it can go into the kernel, a backward compatibilty layer is necessary. But now v4l and v4l2 can co-exist with videodevX, so the compatibilty layer (cl) is not necessary any more in my eyes -- even more, sometimes it is dangerous. Because of the fact, that for example the capturing process cannot be completely emulated, problems can arise. I can remember hard-locking my machine with "bttvgrab" using the cl.. I cannot proof it in general, but I suspect that an app that is not 100% v4l, won't get it by using the compatibility layer either ... ;-) > -justin CU, Michael.
