Hi, > > iGVT-g_Setup_Guide.txt mentions a "Indirect Display Mode", but doesn't > > explain how the guest framebuffer can be accessed then. > > You can check "fb_decoder.h". One thing to clarify. Its format is > actually based on drm definition, instead of OpenGL. Sorry for > that.
drm is fine. That header explains the format, but not how it can be accessed. Is the guest fb exported as dma-buf? > > So, for non-opengl rendering qemu needs the guest framebuffer data so it > > can feed it into the vnc server. The vfio framebuffer region is meant > > to support this use case. > > what's the format requirement on that framebuffer? If you are familiar > with Intel Graphics, there's a so-called tiling feature applied on frame > buffer so it can't be used as a raw input to vnc server. w/o opengl you > need do some conversion on CPU first. Yes, that conversion needs to happen, qemu can't deal with tiled graphics. Anything which pixman can handle will work. Prefered would be PIXMAN_x8r8g8b8 (aka DRM_FORMAT_XRGB8888 on little endian host) which is the format used by the vnc server (and other places in qemu) internally. qemu can also use the opengl texture for the guest fb, then fetch the data with glReadPixels(). Which will probably do exactly the same conversion. But it'll add a opengl dependency to the non-opengl rendering path in qemu, would be nice if we can avoid that. While being at it: When importing a dma-buf with a tiled framebuffer into opengl (via eglCreateImageKHR + EGL_LINUX_DMA_BUF_EXT) I suspect we have to pass in the tile size as attribute to make it work. Is that correct? cheers, Gerd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
