On Mon, Oct 24, 2011 at 03:01:23PM -0700, Jakob Bornecrantz wrote:
----- Original Message -----
On Sat, Oct 22, 2011 at 10:29:33AM +0200, Thomas Hellstrom wrote:
From: Jakob Bornecrantz jakob@vmware.com
Signed-off-by: Jakob Bornecrantz jakob@vmware.com Signed-off-by: Thomas Hellstrom thellstrom@vmware.com
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 10 +++++++++- 1 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c index 39b99db..00ec619 100644 --- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c @@ -679,6 +679,7 @@ static int do_dmabuf_define_gmrfb(struct drm_file *file_priv, struct vmw_private *dev_priv, struct vmw_framebuffer *framebuffer) {
- int depth = framebuffer->base.depth; size_t fifo_size; int ret;
@@ -687,6 +688,13 @@ static int do_dmabuf_define_gmrfb(struct drm_file *file_priv, SVGAFifoCmdDefineGMRFB body; } *cmd;
- /* Emulate RGBA support, contrary to svga_reg.h this is not
* supported by hosts. This is only a problem if we are readingUh, what if it becomes supported at some point? Should there be some check against the host version?
(Thinking that some user might be running this older driver with a newer host that des support 32 - won't that cause issues?)
We can add a check then, from the point of view of userspace 32 bit framebuffers works fine. The problem is with the readback ioctl where the readback pixels alpha will be clobbered. We also don't support depths of 30 R10G10B10X2.
If we add support for depth 32 and/or depth 30 formats we can add params to tell userspace about that, right now there isn't really a point to them since they will always return not supported and we need to do any work around in userspace anyways.
<nods> sounds reasonable.
Cheers, Jakob.