Proposal for per-CRTC pixmaps in RandR
keithp at keithp.com
Fri Mar 12 16:51:37 PST 2010
On Fri, 12 Mar 2010 16:03:56 -0800 (PST), Andy Ritger <aritger at nvidia.com> wrote:
> Don't you have the rendering engine size limits regardless of whether
> a composite manager has created scanout pixmaps and is compositing into
> them, or if the X server does so implicitly?
Yes, the rendering limits are still here, but because we aren't creating
a giant screen pixmap, we don't need to deal with them. Of course, if
the application creates a window which spans both monitors, the back
buffer will be larger than the rendering engine can deal with and we'll
be in software fallback land (and loving it).
The goal is to make multiple monitors work reasonably, not to make large
applications work reasonably.
Frankly, large applications are a DRI issue, not an X issue anyway, once
DRI has a way to split drawing across buffers, getting that added to X
is trivial. The nice thing here is that we don't have to use that for
the multiple monitor case, we can just use different scanout buffers.
> I'd think that per-head information (list of modes, available rotations,
> etc) could be queried separately like today, and then the client would
> construct a description of the desired multi-mode configuration.
> The client could either just request that the multi-mode config be set
> (and the implementation would fail if the config was invalid), or the
> client could optionally ask if the multi-mode config is valid.
I'm willing to let you guys figure out what you want for this; my
hardware doesn't have any issues with conflicting configurations that I
know of (now that I can eliminate the whole scanout size thing).
keith.packard at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the xorg-devel