Hi, > From: Nicolas Dufresne [mailto:nicolas.dufresne@xxxxxxxxxxxxx] > Sent: Wednesday, October 08, 2014 4:35 PM > > > 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 Nicolas, thank you for shedding light on this problem. I see that it is not MFC specific. It seems that the problem applies to all Video4Linux2 devices that use v4l_bound_align_image. I agree with you that this deservers an RFC and some discussion as this would change the behaviour of quite a few drivers. I think the documentation does not specify how TRY_FMT/S_FMT should adjust the parameters. Maybe it would a good idea to add some flagS that determine the behaviour? Best wishes, -- Kamil Debski Samsung R&D Institute Poland -- 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
