Le 2014-10-08 06:24, Kamil Debski a écrit :
Hi,
This patch seems complicated and I do not understand your motives.
Could you explain what is the problem with the current aligning of the
values?
Is this a hardware problem? Which MFC version does it affect?
Is it a software problem? If so, maybe the user space application should
take extra care on what value it passes/receives to try_fmt?
This looks like something I wanted to bring here as an RFC but never
manage to get the time. In an Odroid Integration we have started using
the following simple patch to work around this:
https://github.com/dsd/linux-odroid/commit/c76b38c1d682b9870ea3b00093ad6500a9c5f5f6
The context is that right now we have decided that alignment in s_fmt
shall be done with a closest rounding. So the format returned may be
bigger, or smaller, that's basically random. I've been digging through a
lot, and so far I have found no rational that explains this choice other
that this felt right.
In real life, whenever the resulting format is smaller then request,
there is little we can do other then fail or try again blindly other
sizes. But with bigger raw buffers, we can use zero-copy cropping
techniques to keep going. Here's a example:
image_generator -> hw_converter -> display
As hw_converter is a V4L2 M2M, an ideal use case here would be for
image_generator to use buffers from the hw_converter. For the scenario,
it is likely that a fixed video size is wanted, but this size is also
likely not to match HW requirement. If hw_converter decide to give back
something smaller, there is nothing image_generator can do. It would
have to try again with random size to find out that best match. It's a
bit silly to force that on application, as the hw_converter know the
closest best match, which is simply the next valid bigger size if that
exist.
hope that helps,
Nicolas
--
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
