Re: Proposal: removal of old vb1 or custom streaming I/O drivers

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Em Wed, 10 Aug 2022 10:18:56 +0200
Hans Verkuil <hverkuil@xxxxxxxxx> 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.

> 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.

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 ;-)

Thanks,
Mauro



[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]

  Powered by Linux