[REVIEW] DMX2 DIX merge

Keith Packard keithp at keithp.com
Wed Jan 6 17:26:12 PST 2010


On Wed, 06 Jan 2010 17:39:15 -0500, Adam Jackson <ajax at nwnk.net> wrote:

> I described this wrong.  It corrects the RANDR geometry to account for
> the Xin muxer's idea of the root window size, but XRRGetScreenResources
> still only gives you the RANDR objects on screen 0.  Not useful
> enough.

Right, RandR gets completely scrambled when the panoramix code is
running. Does anyone feel up to the task of trying to get it all patched
back together?

> Basically redirected windows get forced to host memory.  So you're
> always drawing to them in software, but on the plus side, you're only
> doing it once, where the normal rendering muxer would serialize that
> draw across every ScreenRec.
> 
> But that's still kind of gross, since your per-screen pixmaps are still
> going to end up in VRAM, and then read back out to get to the window
> pixmap, and then back into VRAM for the compositor.

I don't think I get this piece -- you shouldn't ever have to touch any
of the pixmaps with the CPU for compositing to work with Xinerama.

> Anyway, was planning to just ignore this part of the patch series for
> now, since I'm hoping to get lazy pixmap realization working instead.

Yeah, that's obviously what we want anyway. Not entirely sure how to
make that work well with Composite as the screen location of the window
may not reflect the only rendering target for the compositor (think
active icons).

-- 
keith.packard at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.x.org/archives/xorg-devel/attachments/20100106/3d71c5d6/attachment.pgp 


More information about the xorg-devel mailing list