On Thu, 3 Nov 2011 13:55:50 -0500 Rob Clark rob.clark@linaro.org wrote:
On Thu, Nov 3, 2011 at 12:36 PM, Jesse Barnes jbarnes@virtuousgeek.org wrote:
On Thu, 3 Nov 2011 18:29:14 +0100 Daniel Vetter daniel@ffwll.ch wrote:
Hi all,
I've discussed this a bit on irc and consensus seems to be "some ugliness due to interface impendance mistmatches in the kernel? who cares ...". I agree that there's not a fundamental problem with fourcc and planar yuv that can't be fixed with a bunch of boilerplate code with the assorted set of inconsistencies between drivers. So if this is the general consensus I'll just look the other way, shut down my shields an recall my battle ship out of LEO ... ;-)
Rob, Joonyoung, Inkie, any comment on using fourcc vs rolling our own surface definitions?
I tend to think that, even if fourcc's aren't perfect, that it is better than the alternatives..
I *think* the main issue is really about single vs multiple buffer objects? Although I've mostly not been having too much time to follow email this week.
I've punted on multi-buffer object fbs anyway. I think those would be better suited to an addfb_multi ioctl. Muxing it into addfb2 seemed unnatural, but I'm not opposed to someone adding one. I just think userspace will have to use one or the other depending on whether all the data is packed into a single bo or not.