XDC: randr extension for full display state setup (full set of outputs and crtcs in one shot)

Keith Packard keithp at keithp.com
Mon Oct 5 19:52:37 PDT 2009


Excerpts from Dave Airlie's message of Mon Oct 05 17:18:30 -0700 2009:

> On Mon, 2009-10-05 at 20:12 -0400, Alex Deucher wrote:
> > 
> > You may have two or more huge monitors connected to a
> > low-end card that can't drive both at full res due to bandwidth
> > limitations.

It seems to me that the actual requirement here is that the client
needs to know which configurations are possible, and that doing the
mode set atomically isn't actually relevant. As long as the client can
discover the set of possible mode combinations, setting the selected
configuration can use existing RandR protocol.

Adding protocol to expose the possible combinations of modes seems
fairly easy to me; getting applications to use that may be more of a
challenge. That seems like a fairly simple N-dimensional boolean
array. If you have four outputs with 20 modes each, that's 160000
bits. Alternatively, you could set up some way to query the system for
a subset of this array.

I have to say that I'm a little surprised that graphics hardware has
these kinds of limits nowadays; a 2560x1600 display only consumes
about 1GB/sec of memory bandwidth. Don't modern GPUs have around
100GB/s of memory bandwidth available?

> I'm just not sure how failing the modeset is going to help no
> matter what you do, how is the client expected to know what was
> wrong with what he asked for? you need to enable intelligent
> client behaviour much more than fail.

Which is why RandR just bails today; the driver is allowed to say 'no'
to any configuration request.

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


More information about the xorg-devel mailing list