[qubes-devel] Re: Does Xorg server pin composition buffer's MFNs?

[Adam Jackson]

On Sun, 2010-04-18 at 10:30 +0200, Rafal Wojtczuk wrote:
> On Fri, Apr 16, 2010 at 11:41:51AM -0400, Adam Jackson wrote:
> > Window pixmaps are like any other pixmap.  Where they live is entirely
> > up to the driver.  Unaccelerated drivers keep them in host memory with
> > malloc().
>
> While we are at it: assuming nonaccelerated driver (in fact, in the actual
> setup, dummy_drv.so is used), is the pixmap->devPrivate.ptr field guaranteed
> to hold the pointer to actual pixels, or is it purely implementation (X server 
> version) dependent and may change in future ? 

Strictly, it's just a convention.  In practice, it points to the pixels,
except when it doesn't.  See xf86EnableDisableFBAccess() for the
details.

> > That's not going to do anything useful without some synchronization
> > work.  Window pixmaps aren't created afresh for each frame.  They're
> > long-lived.  If you manage to get a pixmap shared between VMs A and B,
> > there's nothing to stop A from rendering into it while B is reading from
> > it.
>
> Currently synchronization is done by damage extension events. It seems to
> work: a video player running in A in full screen is correctly displayed in
> B, all other apps work fine as well.

You appear to be using DamageReportRawRectangles, so you'll eventually
be consistent.  It looks like, due to how the X server implements it,
you'll  end up getting a report for the whole pixmap all the time, as we
never empty the internal damage tracking.  Which isn't the most
efficient thing ever, but might not actually matter given how most apps
end up double-buffering updates.

> BTW, it is possible that in case of accelerated driver, XShmPutImage uses
> DMA from the MIT SHM region directly to VGA memory ?

Yes, very possible.  The intel and radeon drivers do this, probably
others too.

- ajax
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.x.org/archives/xorg/attachments/20100419/8159c9f1/attachment.pgp>