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.