RandR 1.2 output properties and options

[Keith Packard]

On Sun, 2006-11-19 at 11:11 +0100, Dirk Thierbach wrote:

> I'd again like to point out that for TV encoders, this view doesn't
> reflect reality very well. A substantial part of the data needed is
> intimately coupled to the modeline (and cannot be calculated from the
> modeline). Another part of the data (that determines the TV system,
> e.g. NTSC or PAL) is more loosely coupled (the total number of 
> 625 resp. 525 TV lines affects the overall timing). A third, small
> part is really independent (various forms of filters or enhancements,
> controls like contrast, brightness, saturation).

Right, I just did the 945 TV encoder support yesterday and have
discovered that they are way too configurable. I suggest that they may
be 'magic' enough to warrant a whole separate mechanism in the protocol
which provides the kinds of data they need.

Instead of attempting to design such a mechanism now, I suggest that we
focus on 'regular' computer outputs for this revision of the protocol
and work on figuring out what TV encoders really need later. The current
protocol is sufficient to describe fixed TV encoder modes, but not
nearly sufficient to express what the encoders are truely capable of.

Gathering the set of capabilities for current TV encoders seems like a
useful way to start building what the overall system requirments might
be. It doesn't look easy to express the possible configurations with
static tables though, so we either artificially limit what we offer from
the hardware or provide some programmatic means of exploring the space
of valid settings.

> So again, I'd like to advocate to switch (at least in the long run)
> to a more general design of having "functional blocks" of data,
> of which the modeline is just one particular block. This would make
> transition simple and smooth, drivers which are not affected could
> just go on using the old modeline infrastructure.

I'd like to avoid warping the remaining outputs with the requirements
present only in TV encoders. Providing additional capabilities for TV
encoding which are expressed through other protocol requests seems like
a good way to keep the general parts of the extension easy to use while
also providing better semantics for the TV-specific pieces.

> IMHO, the first way will make implementing TV support just
> unnecessarily difficult, and it will it also make difficult for
> applications to interact with different drivers, if there's no
> standardized interface.

Yes, lack of a standard interface will be bad in the long run. Let's
make sure we come up with good ideas for a TV-encoder addition to the
RandR specification.

-- 
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/20061119/94ba18a9/attachment.pgp>