RandR version 1.2 revisited

[Alex Deucher]

On 9/13/06, Keith Packard <keithp at keithp.com> wrote:
> On Wed, 2006-09-13 at 11:08 -0400, Alex Deucher wrote:
>
> > Rather then having one big "screen" with multiple crtcs pointed at it,
> > it would be more efficient to have each crtc point at it's own
> > "screen" for multi-head modes.
>
> Each screen gets it's own list of CRTCs, you can do this if you like.
>
> And, there's nothing saying you have to allocate a contiguous frame
> buffer for a screen. Consider how the current Xinerama implementation
> works; the screen is broken up into separate frame buffers.
>
> The main issue is that I'm not interested in attempting to dynamically
> change the number of X screens visible through the protocol; that looks
> 'really hard' to get right. And, I'm not sure it's useful anyway, the

I not trying to expose multiple X screens, I guess I should have used
different wording.  My point was just that it would be nice to support
non-contiguous scan-out buffers. taken together the the buffers would
still make up one X screen.  what's not clear to me is whether the
software fb layer can handle this easily with respect to one X screen.

Alex

> only thing it gives us over Xinerama-style multi-monitor is the ability
> to have different depths. Given Composite's ability to synthesize
> arbitrary depths, you can even run the hardware at different depths as
> long as the software synthesizes a matching set of depths on each
> monitor.
>
> --
> keith.packard at intel.com
>
>
>