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[0].
Cheers,
Daniel
[0]: In the worst case, well over a second and verging on two. Thanks,
GTK.
pgpKThLEaW1ve.pgp
Description: PGP signature
_______________________________________________ xorg-devel mailing list [email protected] http://lists.x.org/mailman/listinfo/xorg-devel
