Re: ABI breakage due to "Unsupported formats in TRY_FMT/S_FMT" recommendation

[Mauro Carvalho Chehab <mchehab@redhat.com>]

Em Sat, 29 Dec 2012 12:39:11 -0500
Devin Heitmueller <dheitmueller@kernellabs.com> escreveu:

> > I suspect that the behavior of returning an error if a pixelformat is not
> > supported is a leftover from the V4L1 API (VIDIOCSPICT). When drivers were
> > converted to S/TRY_FMT this method of handling unsupported pixelformats was
> > probably never changed. And quite a few newer drivers copy-and-pasted that
> > method. Drivers like cx18/ivtv that didn't copy-and-paste code looked at the
> > API and followed what the API said.
> >
> > At the moment most TV drivers seem to return an error, whereas for webcams
> > it is hit and miss: uvc returned an error (until it was fixed recently),
> > gspca didn't. So webcam applications probably do the right thing given the
> > behavior of gspca.
> 
> What if we returned an error but still changed the struct to specify
> the supported format?  That's not what the spec says, but it seems
> like that's what is implemented in many drivers today and what many
> applications expect to happen.

That sounds a very bad idea: when an error rises, applications should
not trust on any returned value, except for the returned error code
itself. All the other values can be on some random state.

This is perhaps the only behavior that are consistent on all ioctls of the
media subsystem (and likely on the other ioctl's of the Kernel).

> No doubt, this is a mess, and if we had tighter enforcement and better
> specs before this stuff went upstream years ago, we wouldn't be in
> this situation.  But that's not the world we live in, and we have to
> deal with where we stand today.

Well, something needs to be done at Kernel level, in order to make this ioctl
consistent among all drivers. I'm open to proposals.

In any case, applications aren't implementing the same logic to handle
this ioctl. This should be fixed there, in order to avoid unexpected
troubles with different hardware.

Cheers,
Mauro