[PATCH 1/2] vmwgfx: Emulate depth 32 framebuffers

Konrad Rzeszutek Wilk konrad.wilk at oracle.com
Mon Oct 24 15:20:37 PDT 2011


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 at vmware.com>
> > > 
> > > Signed-off-by: Jakob Bornecrantz <jakob at vmware.com>
> > > Signed-off-by: Thomas Hellstrom <thellstrom at 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 reading
> > 
> > Uh, 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.


More information about the dri-devel mailing list