XDC: randr extension for full display state setup (full set of outputs and crtcs in one shot)
daniel at fooishbar.org
Tue Oct 6 08:17:51 PDT 2009
On Tue, Oct 06, 2009 at 11:07:02AM -0400, Adam Jackson wrote:
> On Mon, 2009-10-05 at 19:52 -0700, Keith Packard wrote:
> > > 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.
> I think you do still want an atomic setup call. Otherwise, in the
> general case, you have to tear down existing CRTC state to get to the
> desired CRTC state, which means sending (at least) twice as many RANDR
> events to clients.
> Granted this is already a thundering herd, since as a side effect of how
> gobject signals work, every gtk app on the system wakes up for every
> RANDR event. But there's no reason to make it seven thundering herds if
> we don't have to.
So I was the one who brought this up. In our case, the problem wasn't
notification of RandR events, but that relayout + resize in apps is
actually really, really slow, and if you need to disable one or more
CRTCs, change the screen size, then reconfigure and re-enable the CRTCs
in order to rotate, rotation is going to take approximately forever.
: In the worst case, well over a second and verging on two. Thanks,
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 197 bytes
Desc: not available
Url : http://lists.x.org/archives/xorg-devel/attachments/20091007/21379e4c/attachment.pgp
More information about the xorg-devel