On Fri, Feb 6, 2009 at 8:21 AM, Guennadi Liakhovetski <g.liakhovet...@gmx.de> wrote: > On Fri, 23 Jan 2009, Magnus Damm wrote: >> On Fri, Jan 23, 2009 at 9:28 AM, Kuninori Morimoto >> <morimoto.kunin...@renesas.com> wrote: >> > NV12/21/16/61 had been added every time >> > UYVY/VYUY/YUYV/YVYU appears on get_formats. >> > This patch modify this problem. >> >> That's one way to do it. Every similar driver has to do the same thing. Yuck. >> >> Or we could have a better translation framework that does OR for us, >> using for instance bitmaps. > > This has been on my list for a while now, but I'm quite busy these days, > but I think I now have an idea how to fix this problem in a less > destructive way, withoug undermining the soc-camera algorithms:-) Please, > have a look at the patch below. Does it fix the problem for you? If not - > how can we modify it to work for you? Notice - not even completely compile > tested:-)
Thanks for your effort on this. From a quick glance your solution is fine with me, from the "fixing the bug" perspective at least. In practice I don't think your solution is very different from Morimoto-sans patch though. Maybe it's a bit cleaner. But since the number of pixel formats are finite I still think a bitmap would be useful to represent which formats that are supported. Setting a bit in a bitmap is a much easier than walking lists to check for duplicate modes. OTOH, there are not that many drivers that need this format translation at this point so the best may be just closing this issue with and solve it in a more generic fashion later on if there are more users. Cheers, / magnus -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
