While working on the vb2 conversion of the saa7146 driver I dug a bit deeper into the video capture overlay support of that driver. For more info of that feature see: https://linuxtv.org/downloads/v4l-dvb-apis-new/userspace-api/v4l/dev-overlay.html Specifically, video overlay support relies on userspace passing the address of the framebuffer to the driver with VIDIOC_S_FBUF. The PCI driver can then DMA the captured frame straight into the framebuffer. This was useful 20 years ago, but today not so much. Typically userspace would get the address from the /dev/fbX device using the FBIOGET_FSCREENINFO ioctl. But drm_fb_helper.c sets the smem_start field explicitly to 0 unless: 1) CONFIG_DRM_FBDEV_LEAK_PHYS_SMEM is set, and 2) CONFIG_EXPERT is set, and 3) set the drm_kms_helper module parameter drm_leak_fbdev_smem to 1. Actually, even with all that set, I *still* get a 0 value. I probably missed something. In any case, I think destructive overlay support is effectively dead and it should be removed from the v4l2 drivers. This would affect saa7146, bttv, saa7134 and vivid. Output overlay support is still around (ivtv, omap_vout). There is also a single driver with a non-destructive capture overlay: drivers/staging/vc04_services/bcm2835-camera/bcm2835-camera.c No idea what that's doing exactly in the bcm2835 driver. Removing support for this has some nice related benefits: the overlay window supports clipping (either a list of rectangles or a bitmap), and that would also disappear. That makes the compat32 code quite a bit easier. A fair amount of code is dedicated to that. So, I propose to drop destructive overlay support from saa7146, bttv and saa7134 and vivid for the 6.4 kernel. In addition, support for V4L2_FBUF_CAP_LIST_CLIPPING and V4L2_FBUF_CAP_BITMAP_CLIPPING is also dropped. This only affects the vivid driver which is the only driver that supports this for output overlays. Any objections? Regards, Hans
