> > > I think it might be an idea to simply wrap the v4l2 parts of 0.8.x up in > > > some #ifdefs, and put it in the kernel. > > > > That would still require some videodev.[ch] patching (add fops to > > video_device + the userspace copying ioctl wrapper). > > Oops - didn't think of that... Is it possible to at least get the fops > in (that shouldn't break anything), and add the ioctl wrapper to bttv > 0.8.x? (Or do you think it is not ready for prime-time yet?) [ announce / call for testers ] Uploaded bttv 0.8.18 and a updated v4l2 kernel patch (the patch is also in the tarball): http://bytesex.org/bttv/bttv-0.8.18.tar.gz http://bytesex.org/bttv/patch-v4l2-2.4.6-pre5.diff.gz Changes in bttv: - made bttv's v4l2 support a compile time option. - radio fix. Was broken in older releases, this one might work. Untested as I don't have a card with radio currently. Changes in v4l2 patch: - moved all the v4l2 stuff to another header file (makes testing easier as you don't have to fiddle with patch all the time to enable/disable v4l2), it's also trivial to build a patch without v4l2 now. - resynced videodev.h with the kernel. - moved the ioctl wrapper to videodev.c, removed all v4l2 stuff from it. v4l1-compat is broken right now due to that (wrapper hooks are gone). Needs fixing later ... - renamed fill_ctrl_category to v4l2_fill_ctrl_category. It's exported now, and it is the job of the driver to call it. The ioctl wrapper doesn't. Comments? Test results? I'm especially intrested in: - Stability (0.8.x wouldn't fix buggy hardware of course, but it must not crash on any hardware where 0.7.x or bttv2 stays up). When comparing with 0.7.x, please use 0.7.61 or newer (0.7.69 for bigendian machines), older versions have known bugs which can hang your box). - Compatibility problems. If some app doesn't work, try sloppy=1 first. Note that most bttv-specific ioctls are gone. I'm not going to reimplement them unless someone comes up with a very good reason for it. Gerd -- Damn lot people confuse usability and eye-candy.
