Hello, On Wed, Aug 10, 2022 at 12:24:16PM +0200, Mauro Carvalho Chehab wrote: > Em Wed, 10 Aug 2022 10:18:56 +0200 Hans Verkuil escreveu: > > > We have the following drivers still using vb1: > > > > PCI: saa7146, bt8xx, cx18 > > USB: zr364xx, tm6000 > > platform: ti/davinci/vpfe_capture, nxp/fsl-viu > > staging: atomisp > > > > And these drivers rolls their own streaming I/O implementation: > > > > pci: meye > > usb: cpia2 > > staging: stkwebcam (deprecated, to be removed by the end of the year) > > > > I think we should bite the bullet and move all of these drivers to staging, > > mark them deprecated and delete them some time next year if nobody will > > convert them to vb2. > > > > That includes atomisp: is that going anywhere? Unless someone does the > > hard work of converting it to vb2 I think it should be removed as well. > > There have been improvements at atomisp driver. Hans de Goede has been > doing some work. As far as I understand, he's planning to get VB2 and > libcamera support for it. I'm also working on it when I have some spare > time available. That looks like a project that will take a few lifetimes, but as long as I don't have to work on it myself, that's fine with me :-) I don't think it's a blocker anyway, if we move vb1 drivers to staging, and hopefully the vb1 core too, then atomisp2 will just be with all its vb1 cousins. > > The two drivers most likely to still be in use somewhere are bt8xx and > > cx18. If it turns out that we can't remove them (yet), then I can probably > > justify the time to convert cx18 to vb2 myself. > > Yeah, bt8xx is probably still widely used, specially on analog camera > multi-port capture scenarios. Not sure about cx18 usage those days. > > IMO, once we get bt8xx, atomisp (and maybe cx18) converted to VB2, it > should be OK to remove the other drivers. > > For now, we can move them to staging, adding a TODO explaining that they > should be ported to VB2 or they'll be removed. Sounds good to me, staging is the right way out. > Scheduling removal to the end of the year is probably not doable, as > the patch moving them to staging would be merged only around Oct. > We should grant at least two Kernel cycles for people to convert the > drivers - assuming that someone would do that for some driver(s). > > > And for bt8xx I would probably be willing to convert it to vb2 as well, > > provided we can strip the overlay support from the driver (since, if memory > > serves, vb2 doesn't support that) and convert it to vb2. It's a big job, though. > > It sounds OK on my eyes to remove overlay support from bt8xx during VB2 > conversion. We should probably add a warning about such removal before > that (see below). > > > One other thing we can do is to deprecate/remove video capture overlay support > > (in the sense of video capture hardware writing directly to a framebuffer). > > > > It's supported by saa7146, bttv, saa7134 and fsl-viu. If we remove vb1 > > drivers, then that would leave only saa7134 that still supports it. > > > > Removing the API will simplify things. > > It probably makes sense to add an error-level printks, printed only once, > when someone uses VIDIOC_OVERLAY ioctl, warning that this is a deprecated > feature that will be removed soon, for the drivers that still supports it. > > For sure once we get rid of the VB1 drivers that use overlay, it makes > sense to also remove its support for saa7134. Maybe even before ;-) \o/ I'd be happy to see the V4L2 code base shrink for once. -- Regards, Laurent Pinchart
