Em Sat, 29 Dec 2012 12:39:11 -0500 Devin Heitmueller <dheitmueller@xxxxxxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
