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.
- ajax
Attachment:
signature.asc
Description: This is a digitally signed message part
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
