On Wed, Jul 20, 2011 at 5:23 PM, Keith Packard <kei...@keithp.com> wrote: > On Wed, 20 Jul 2011 14:13:55 -0700, Aaron Plattner <aplatt...@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 <aplatt...@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.
We only expose the underscan options for digital outputs to compensate for TVs that automatically overscan. For analog TV-out would could implement something similar, but we probably also want to support more than just underscan. Alex _______________________________________________ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel