Update on RandR changes from DDC
Jeremy A. Kolb
jkolb at brandeis.edu
Thu Jul 20 13:24:07 PDT 2006
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
Doesn't NV-CONTROL cover some of this territory? It may be worth seeing
how NVidia does it.
More information about the xorg