On Mon, 2012-02-20 at 18:10 +0100, Ben Widawsky wrote: > On Thu, 16 Feb 2012 05:52:12 -0800 (PST) > Jakob Bornecrantz <ja...@vmware.com> 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.
If the vmwgfx ddx wants to do this kind of fallback, great, but that's
just ddx logic, open the right drm device and change the dri driver
name. If you don't want to rely on a vgem device node existing... well,
tough, I guess, since the ioctl numbers will collide. It needs to exist
for the vesa-like case regardless.
- ajax
signature.asc
Description: This is a digitally signed message part
_______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
