On Thu, 3 Nov 2011 13:55:50 -0500 Rob Clark <rob.clark@xxxxxxxxxx> wrote: > On Thu, Nov 3, 2011 at 12:36 PM, Jesse Barnes <jbarnes@xxxxxxxxxxxxxxxx> wrote: > > On Thu, 3 Nov 2011 18:29:14 +0100 > > Daniel Vetter <daniel@xxxxxxxx> 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. -- Jesse Barnes, Intel Open Source Technology Center
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel