On Tue, 21 Feb 2012 11:08:52 -0500
Adam Jackson <ajax@xxxxxxxxxx> wrote:
> On Tue, 2012-02-21 at 15:34 +0000, Dave Airlie wrote:
>
> > Not sure what you mean there, those 3 APIs are just to create dumb
> > unaccelerated objects,
> > probably are fine for vgem's use. For scanout we create framebuffer
> > objects from a dumb object
> > then we do shove it back in from above.
> >
> > So if the ioctls are doing the same thing we should just use the
> > generic dumb ioctls for vgem.
>
> That's... not at all obvious from the comments or the ioctl argument.
>
> /* create a dumb scanout buffer */
> struct drm_mode_create_dumb {
> uint32_t height;
> uint32_t width;
> uint32_t bpp;
> uint32_t flags;
> /* handle, pitch, size will be returned */
> uint32_t handle;
> uint32_t pitch;
> uint64_t size;
> };
>
> This doesn't look like "here, kernel, I am handing you a pointer". It
> looks instead like "please, kernel, create this thing for me", and the
> comment above sure does imply the thing being created is explicitly for
> scanout purposes.
>
> If it's just creating unaccelerated objects and the "bind to
> framebuffer" part is somewhere else, then sure, vgem should probably
> just use that. I'm still going to need that to exist as its own device
> node not backed by a physical device, but I don't think that's
> contentious.
I'm on board with the dumb ioctls as well. I also need a device node,
and some test ioctls for the prime stuff, but mmap and create are no
issue to switch over at the moment.
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
