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 _______________________________________________ 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