Update on RandR changes from DDC

[Jeremy A. Kolb]

On Thu, 20 Jul 2006, Keith Packard wrote:

> On Thu, 2006-07-20 at 13:08 +0200, Dirk Thierbach wrote:
> 
> > I like the Intel terminology for those objects: 
> 
> Yeah, it's workable, but I would rather use more widely understandable
> terminology. Anyone not familiar with the Intel driver would have to
> learn these terms.
> 
> > Finally, the situation for TV out is somewhat more complicated:
> 
> My thinking here is that the RandR extension would provide named
> 'outputs' for the TV encoder and it would use those output names to
> configure the chip correctly. An additional extension could be used to
> communicate with the encoder chip to tweak the parameters if necessary,
> but for most people, that's not necessary.
> 
> I'd like to push work in this area to people with more interest and
> ability without also making them jump into the details of screen
> resizing and the like...
> 
> It does bring up some additional constrants which we may want to expose
> in this extension. The device will have configuration constraints that
> limit how outputs can be connected to the CRTCs, and some outputs can
> only be used with certain modes (LVDS has a fixed maximum size, TV
> encoders may need to use fixed frequencies or modelines). I suspect what
> I'll do is encode the capability matrix in a set of bitmasks and see if
> I can't make that general enough to cover the relevant cases. I do think
> we'll need a general fallback of 'oops, can't do that' for cases whch
> can't be described this way, but that better be limited to the truly
> bizarre.
> 
> 

Doesn't NV-CONTROL cover some of this territory?  It may be worth seeing 
how NVidia does it.

Jeremy