On Tue, Feb 21, 2012 at 3:03 PM, Adam Jackson <ajax@xxxxxxxxxx> wrote:
> On Mon, 2012-02-20 at 18:10 +0100, Ben Widawsky wrote:
>> On Thu, 16 Feb 2012 05:52:12 -0800 (PST)
>> Jakob Bornecrantz <jakob@xxxxxxxxxx> wrote:
>> > Any reason why you are not using the dumb_bo interface? I at least
>> > would like to be able to offer vgem on the vmwgfx device when the
>> > host has disabled 3D.
>>
>> I thought dumb bo interface was an extension for an existing DRM GEM driver. In my
>> case, for prototyping dma_buf support, this is non-ideal. I'm not sure what Adam
>> thinks of this though (I imagine he wants a device independent driver though).
>>
>> I may be completely off.
>
> Assuming by this you mean DRM_IOCTL_MODE_{CREATE,MAP,DESTROY}_DUMB, I
> wasn't considering that because I wasn't expecting this device to expose
> a scanout buffer. It's hard to imagine how it would, given that API,
> since you'd need userspace to jam the framebuffer info in from above.
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.
Dave.
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
