Update on RandR changes from DDC

[Dirk Thierbach]

On Thu, Jul 20, 2006 at 01:48:42AM -0400, Keith Packard 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.

[order changed]
> 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.

Let me quickly introduce myself: I am the author of the 'nvtv'
utility, a small program written first to directly program NVidia
cards to allow TV-out before the closed source drivers were able to do
it, that then somehow grew to also support Intel i810 and Voodoo3
cards, and different TV encoder chips. I have some limited experience
with X, mainly reading driver sources.

The 'nvtv' program was originally written with the idea in mind to
integrate it eventually in X. That never happened, and would be
probably not so easy with the way the code is now, but I have seen
some of the options these cards offer with respect to arranging
different combinations of screens/monitors etc., so I'd like to make a
few comments in the hope that they may be useful.

> 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 like the Intel terminology for those objects: 

plane: What you called a screen.
port:  What you called an output. Maybe call it "pixel port" or something 
       like this to destingiush it from other ports.

They also use

pipe:  Any device that reads from a plane and outputs pixel data to a port.

So that would correspond to a viewport, minus the rectangular subset.
Maybe one could call those subplanes, or something like that -- after all,
a plane just consists of start address, size and rowstride, so planes and
subplanes are not really different. The "pipes" used for TV out sometimes
use different registers than the CRTC, though they are similar. Also,
for some cards (e.g. Riva TNT2) it is possible to connect the video
overlay "pipe" directly to a "port", effectively giving a second 
(specialised) head.

Finally, the situation for TV out is somewhat more complicated: A
modeline sometimes isn't enough to describe a special "pipe", and the
external TV encoder behind the port also needs extra data, and quite a
lot of it. Hence it would be convenient to partition the encoder chip
into several independent blocks, for example one for filtering and
enhancing, one for timing, and one for the output voltage levels that
depend on the TV system. So one could have a configuration like this:

+---------+   +--------+   +--------------+
| Plane 1 |---| Pipe A |---| Monitor port |
+---------+   +--------+   +--------------+

+---------+   +--------+   +---------+   +--------+   +--------+   +---------+
| Plane 2 |---| Pipe B |---| TV port |---| Filter |---| Timing |---| TV Sys. |
+---------+   +--------+   +---------+   +--------+   +--------+   +---------+

For flatpanel, a similar system should work.

So instead of a modeline, one would have a "modepath" with CRTC values
for the pipe, HSync/VSync polarity values for the port, timing values
for the encoder chip etc.

Modesetting would consist of

- Establishing such a path, together with initial values (possibly
  re-using an existing path, so one could drive e.g. several ports
  from the same pipe, of the hardware allows that).
- Destroying such a path
- Changing values for all or just a single block in this path.

I realize that it is much too much to ask to incorporate this in the
next concrete RandR or any other extensions, but maybe it's helpful to
keep it in the back of the mind somewhere as it would made adding TV
output to X a lot easier, in a really general way.

> 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). 

Again, the situation is a bit more difficult with TV out: The "outputs",
i.e. the "ports", are just an intermediate step in the path. As a rule,
TV out encoder chips can be used for a composite (one line) or a S-Video 
signal (two lines), and sometimes also for RGB-output (three lines).
Also, for example on Intel graphics, the internal ports are just
named DVOA..DVOC, and it's up to the hardware manufacturer which of
those ports to use for DVI, TV, or whatever. This assignment information
seems to be stored in the BIOS, but for open source drivers
it's difficult to find that out, so it should be configurable by
the user just in case.

Also, in principle there's nothing to stop the hardware manufacturer
to include any number of TV/DVI/whatever outputs on the card.

> 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.

Sounds like a good idea.

- Dirk