RFC - Overscan compensation configuration in RandR

[Aaron Plattner]

I'm trying to add support for overscan compensation to the Tegra
X driver.  This driver uses RandR 1.2, so I need to add an
official mechanism for X clients to describe the desired
configuration through the protocol.

RandR currently assumes that a mode with a given
HDisplay/VDisplay size will display pixels from the framebuffer
into a rectangle of raster pixels with those dimensions.  For
example, if your modeline is

   172.80  1920 2040 2248 2576  1080 1081 1084 1118  -HSync +Vsync

then a region of 1920x1080 pixels of the raster area will read
from a region of the framebuffer described by the transform (plus
rotation and the (x, y) CRTC offset).

For VGA displays, a client can simply adjust the timings by
shrinking H/VDisplay and then moving the sync pulse around to
position the image.  VGA devices don't have any idea when the
active region ends and blanking begins, so that works fine.
Unfortunately, digital display do know and care, so that
mechanism breaks down.  What is needed is a way of decoupling the
H/VDisplay size of the mode from the viewport used to display the
actual desktop pixels within the active raster image.

Since there's no good existing mechanism for clients to do this,
I came up with a few possibilities:


1. Add fields to DisplayModeRec.

Adam Jackson suggested exposing the HBorder/VBorder fields in
DisplayModeRec to clients.  This sounds great, except that no
such fields exist.  Adding them will require changing the driver
ABI (not a big deal), the modeline parser and documentation
(annoying, but still not a huge deal), and the protocol and
libraries (kill me now).

2. Add a viewport rectangle attribute to the CRTC alongside the
   transform.

This still requires changing the protocol, but doesn't require
changing the decades-old modeline syntax.  The disadvantage is
that you won't be able to have overscan compensation applied
automatically on a per-mode basis and instead will need an X
client to be aware of your desired settings.  It also means that
VidMode clients like video games will blow away your overscan
settings when they change the mode.  However, it matches the way
things like the transform and rotation work.

This is a bit ugly because the new protocol required would be
special-purpose and designed specifically for this new viewport
attribute.  It's unfortunate that CRTCs don't have
general-purpose properties that could be used for things like the
rotation, panning, and the transform rather than adding yet more
single-purpose get/set requests every time we want to add
attributes that get applied at modeset time.

3. Add a standardized property to the outputs that the server
   will recognize.

This has the advantage of not requiring a protocol change.  The
downside is that it's the first client-settable property that the
server will read on its own.  However, the property mechanism
does seem perfectly suited for this, except that CRTCs don't have
properties, meaning it would have to be set on the outputs and
you get the usual "what do we do when the output properties don't
agree" problem when multiple outputs are bound to a CRTC.  I
think the agreed-upon solution for similar conflicts was to use
whichever one we see first, which seems fine.

4. Who cares about overscanned pixels, you can't see them anyway!

The problem with this is that the server rejects modesets where
the CRTC would be reading outside the framebuffer area.  This
means that a client can't, for example, change the framebuffer
size to 1820x980 and then use the transform to position the
framebuffer's upper-left corner at (50, 50) in the 1920x1080
raster picture because the 50px border would exist outside the
framebuffer's area.

We could solve this by relaxing the constraints to allow a CRTC
to scan out any region of pixels, even ones outside the
framebuffer, and just define those pixels to be black.  This
doesn't allow the client to mask off the bottom and right edges
of the image if the framebuffer is larger (for example if there's
a second CRTC in a side-by-side configuration), but who cares,
you can't see them anyway!

It might be worth relaxing this restriction even if we implement
one of the other solutions above, because it could be useful for
situations like non-cardinal rotations or keystone compensation.


I'm kind of leaning toward option #3 since it's the least
disruptive, but maybe that's just laziness on my part.  What do
you think?

-- Aaron