Update on RandR changes from DDC

[Keith Packard]

Kevin Martin, Matthew Tippett and I sat down for an hour or so and
chatted about the RandR changes and we figured out that the proposal was
missing another level of detail.

RandR classic has screens.
RandR++ has screens and monitors

However, actual hardware has another piece in the middle, the CRTC
itself, which is relevant as there may be 0, 1 or 2 monitors connected
through each CRTC to the frame buffer.

Each CRTC has a fixed screen origin and mode. Connected outputs can
receive only the provided mode. Hardware can limit which outputs may be
connected to the same CRTC, and hardware can provide multiple CRTCs.

Our thought was to avoid the loaded name 'monitor' for either the CRTC
or the physical connector, besides, sometimes you don't connect a
monitor, you connect a projector, or a video recorder or an antenna.

So, we decided to use the following terminology:

screen:	X screen object, a rectangular array of pixels without a defined
destination.

viewport: A rectangular subset of a Screen which has a defined modeline.

output: The destination for pixel data which can be connected to a
viewport.

I'm happy with 'screen' and 'output', perhaps 'viewport' should instead
acquire the technical name 'crtc' as that is fairly well understood by
programmers (the target audience for the physical link), however, using
a non-technical term in the standard will encourage user-facing strings
to share the same term in multiple environments. Suggestions on naming
are, as always, quite welcome.

I'm thinking that viewports shouldn't have names, and instead should be
numbered. However, I think otuputs *should* have names as defined by the
driver. That way, they can match the physical label on the machine if
possible, or at least provide a reasonably descriptive identifier
(Composite Video, HDMI, DVI, etc). I suggest that we should include in
the spec some common names of common connectors so there is consistency
across drivers, but permit the spec to be easily updated with additional
names when necessary.

I'm busy writing up the spec changes for this new scheme and will
replace the implementation that I've started with the new plan.
Questions and comments now will help avoid my rewriting it a third time,
so please step up and comment soon.

-- 
keith.packard at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.x.org/archives/xorg/attachments/20060720/4e6e8c21/attachment.pgp>