Bug 14143 - RANDR CRTCs forced to share a single allocation
Summary: RANDR CRTCs forced to share a single allocation
Status: RESOLVED INVALID
Alias: None
Product: xorg
Classification: Unclassified
Component: Server/General (show other bugs)
Version: git
Hardware: All All
: medium normal
Assignee: Xorg Project Team
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-01-19 14:34 UTC by Adam Jackson
Modified: 2018-06-13 16:40 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments

Description Adam Jackson 2008-01-19 14:34:53 UTC
The current design of the RANDR CRTC implicitly assumes that all CRTCs share a single allocation of framebuffer memory.  This is certainly the simplest thing that could possibly work, and it's very efficient in terms of rendering overhead.  However many configurations are approaching a point where the total desired pixel area exceeds the allocation limits of a single CRTC.

An example is instructive.  Intel 945 hardware has a CRTC pitch limit of 2048 pixels.  However, it has two CRTCs, and they can each be pointed at different allocations.  It is not possible to satisfy two adjacent non-overlapping 1920x1200 monitors within a single 2048x2048 allocation, but two distinct allocations would work fine.

Implementing this requires that rendering be broken up across allocation boundaries, appropriately translated within the screen's coordinate space.  Logically you can think of this as having multiple pixmaps backing the root window.

With the introduction of the Composite extension, pixmaps can already have "screen coordinates", so much of the translation work is already in place.  It just remains to implement the various GC and Render wrappers to do the iteration.
Comment 1 Adam Jackson 2018-06-13 16:40:56 UTC
Will create a new bug for this post-gitlab.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.