Re: [PATCH 1/5] drm/vgem: virtual GEM provider

[Ben Widawsky <benjamin.widawsky@intel.com>]

On Tue, 21 Feb 2012 11:08:52 -0500
Adam Jackson <ajax@redhat.com> 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.