RFC - Overscan compensation configuration in RandR

[Keith Packard]

On Wed, 20 Jul 2011 14:13:55 -0700, Aaron Plattner <aplattner at nvidia.com> wrote:
> On Sat, Jul 16, 2011 at 10:29:58AM -0700, Keith Packard wrote:
> > On Fri, 15 Jul 2011 16:51:59 -0700, Aaron Plattner <aplattner at nvidia.com> wrote:
> > 
> > > Since there's no good existing mechanism for clients to do this,
> > > I came up with a few possibilities:
> > 
> > We added margin properties to the Intel TV out driver a few years ago,
> > and now those are a standard part of the KMS interface. Would those do
> > what you want?
> 
> Sort of.  I rejected this idea initially because it causes the actual mode
> timings driven by the hardware to differ from the mode described by the
> client in the RandR protocol.  One of my goals was to make sure that the
> described mode actually matches the driven mode, which means the server
> itself needs to know about the margins.  If you don't think that goal's
> worthwhile, we could certainly fudge the mode inside the driver based on
> some driver-added property.
> 
> Even if we do go that route, I'd still like to standardize the option in
> randrproto.txt so we don't have divergent implementations like it sounds
> like we already have between Radeon and Intel.

I didn't realize the radeon people were going a different way; the intel
properties have been in use for several years now.

And, it is only used with our TV outputs, which have a built-in scaler
and timing generator which completely ignores the 'mode', so I don't
have a strong opinion on whether this makes sense in a more rational
world where the hardware uses the mode passed in.

-- 
keith.packard at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg-devel/attachments/20110720/1e199769/attachment.pgp>