Re: [PATCH] DRM planes

[Jesse Barnes <jbarnes@virtuousgeek.org>]

[-- Attachment #1.1: Type: text/plain, Size: 1539 bytes --]

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.

-- 
Jesse Barnes, Intel Open Source Technology Center

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel