Proposal for per-CRTC pixmaps in RandR

[Andy Ritger]

On Fri, 12 Mar 2010, Keith Packard wrote:

> * PGP Signed by an unknown key
>
> 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).

OK, thanks.  The piece I was missing before was that you planned to
fallback to software if the window was larger than the rendering engine's
max buffer size.  That seems like a steep cliff in a common case, but
I won't argue.

> 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;

Sure; that's fair.

Thanks,
- Andy


> 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
>
> * Unknown Key
> * 0x096C4DD3
>

-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information.  Any unauthorized review, use, disclosure or distribution
is prohibited.  If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------