It's a Chromium bug.
https://bugs.chromium.org/p/chromium/is ... ?id=616007
https://bugs.chromium.org/p/chromium/is ... ?id=249953
Chromium doesn't support devices that advertise their resolutions as being V4L2_FRMSIZE_TYPE_STEPWISE (as Pi does) or V4L2_FRMSIZE_TYPE_CONTINUOUS, only V4L2_FRMSIZE_TYPE_DISCRETE.
That means Chromium ends up asking V4L2 for a 0x0 frame. The V4L2 API requires the driver to select the nearest supported mode, so we end up at 32x32, and things look rather blurry.
The correct solution is to support things properly in Chromium, but they seem to be ignoring the issue.
Amending the V4L2 driver to have a kernel parameter to say it should support a limited list of discrete resolutions would be possible, but is a nasty hack, and reduces the capability set of the driver massively. If someone did it cleanly and submitted a PR to the kernel tree then I would accept it. We do already have a nasty hack parameter in there due to a failure in older versions of GStreamer. Actually that is on the same ioctl.
Comments at https://github.com/raspberrypi/linux/bl ... mera.c#L69
/* Gstreamer bug https://bugzilla.gnome.org/show_bug.cgi?id=726521
* v4l2src does bad (and actually wrong) things when the vidioc_enum_framesizes
* function says type V4L2_FRMSIZE_TYPE_STEPWISE, which we do by default.
* It's happier if we just don't say anything at all, when it then
* sets up a load of defaults that it thinks might work.
* If gst_v4l2src_is_broken is non-zero, then we remove the function from
* our function table list (actually switch to an alternate set, but same
I just wonder what Chromium would do in that case. You can try it with "sudo modprobe bcm2835-v4l2 gst_v4l2src_is_broken=1" when loading the driver.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.