Update on RandR changes from DDC

[Alex Deucher]

On 7/20/06, Keith Packard <keithp at keithp.com> wrote:
> 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.

One question,  once the new xrandr is out and reviewed, is there a
general consensus to rip out the old screen based dualhead code?  I'd
like to see it gone and would volunteer to convert the existing
drivers.

Alex

>
> --
> keith.packard at intel.com
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.3 (GNU/Linux)
>
> iD8DBQBEvxk6Qp8BWwlsTdMRAh++AJ4rFvsggIcfpEclw7jc7EsrGvyelwCghfhD
> gYvER/W6ZjaUSrEi2FsVGsI=
> =LcAa
> -----END PGP SIGNATURE-----
>
>
> _______________________________________________
> xorg mailing list
> xorg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xorg
>
>