RFC - Overscan compensation configuration in RandR

[Alex Deucher]

On Wed, Jul 20, 2011 at 5:23 PM, Keith Packard <keithp at keithp.com> wrote:
> 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.

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