On Monday 08 August 2011, Mauro Carvalho Chehab wrote: > > > > > > Well, in practice the "fork" would presumably be carried out by yours > > truly. Presumably with the advice and help of concerned parties. too. > > Since I am involved on both the kernel side and the libgphoto2 side of > > the support for the same cameras, it would certainly shorten the lines > > of communication at the very least. Therefore this is not infeasible. > > Forking the code just because we have something "special" is the wrong > thing to do (TM). I would not like to fork V4L core code due to some > special need, but instead to add some glue there to cover the extra case. > Maintaining a fork is bad in long term, as the same fixes/changes will > likely be needed on both copies. Unfortunately there is some difficulty with libusb in that respect. libgphoto relies upon libusb-0.1 becuase it is cross platform and Win32 support in libusb-1.0 is only just being integrated. The libusb developers consider the libusb-0.1 API frozen and are not willing to extend it to address our problem. libusb doesn't expose the file descriptor it uses to talk to the underlying device so it is hard to extend the interface without forking libusb (The best hope I can think of at the moment is to get the distros to accept a patch for it to add the extra required API call(s) and for libgphoto to use the extra features in that patch if it detects it is supported at compile time). Adam Baker -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
