RFC - Overscan compensation configuration in RandR

[Alex Deucher]

On Fri, Jul 15, 2011 at 7:51 PM, Aaron Plattner <aplattner at nvidia.com> wrote:
> 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?
>

FWIW, I implemented this in the open source radeon driver as a set of
randr output properties:
	underscan vborder: 0 (0x00000000)	range:  (0,128)
	underscan hborder: 0 (0x00000000)	range:  (0,128)
	underscan:	off
		supported: off          on           auto
The border properties allow you to adjust the amount of underscan, and
the underscan property selects whether you want to turn it on, off, or
auto.  Auto only enables it for "standard" HDTV modes if the monitor
can be determined to be HDMI based on the edid.

Alex