ROVAEdit is a tool I wrote some years ago for editing binary images distributed with the R.RMxxxx series of LCD controllers. Its two main goals were to remove OSD pop-ups, and also to add support for new LCD panels. Originally all of this information was on the ROVATools page but I have moved it here as (I suspect) no-one actually uses this.
Disappointingly no source code is included with the R.RMxxxx LCD controllers, but this was no surprise to me. I’ve not seen a single line of source code for these controllers in my life. That isn’t to say it’s not out there, there’s plenty of sites flogging off leaked source snapshots of these boards.
The mainstay of this tool suite is descrambling the .GFF files so they can be edited. Because I don’t have a mechanism to re-create .GFF files, this software has to be used to program the controllers.
ROVAEdit – RTD2120 boards only
This gives one access to pretty much all of what you’d need to change when creating an image for an unsupported panel. This program can only edit the firmware for supported R.RMxxxx boards.
Before we can get started with using this program, it’s important to understand the operating theory of the controller silicon RTD2524L (herein the “RTD”).
Unlike some more advanced LCD Panel driving systems which feature RAM chips and framebuffers, the RTD is very much a “what goes in is what comes out” affair.
If the PC is sending a signal at the panel’s native resolution at 85Hz, then the RTD will send that same signal to the panel at 85Hz, likely outside of specification. It cannot do a complicated conversion of one frame rate to another, unless the input resolution is lower than the panel’s native resolution, in which case scaling can resolve higher-than-rated frame rates.
For this reason, it’s important that what the PC is sending is as closely matched to what the panel requires as possible. Not just the pixel clock (which is a product of the refresh rate and resolution) but also the horizontal and vertical blanking periods. What the PC sends is determined by the EDID which is embedded in the RTD’s software, and this application is able to import and export that information.
The RTD has two main operation modes:
Free running mode
In this mode the RTD is able to display a picture on the screen with no input signal. This can be used to display the OSD but from my observation, it is only used to display the “No Signal” message.
During free running mode, the RTD must generate its own clock, and uses timing parameters embedded in the RTD’s software, which this application is also able to edit.
In free running mode, the panel pixel clock (herein DCLK) is determined as:
DCLK = (Horizontal period total * Vertical period total * 60)
(Divide by two for dual channel panels)
Frame sync mode
In this mode the RTD is clocked and timed by the signal coming from the PC. Some of the embedded timing parameters are used to drive the panel, but most are automatically adjusted to match the input signal, which is based on the EDID.
In frame sync mode, DCLK is determined as:
DCLK = (Horizontal period total * Vertical period total * In refresh rate)
(Divide by two for dual channel panels)
Okay, so let’s get onto the interface…
Panel timing configuration
This section is mostly used to configure the “Free running mode” – explained earlier. The RTD’s way of timing is counting the number of lines (V) or clocks (H) then using these numbers to trigger an event.
For example, when the PC asserts the VSYNC signal, the RTD will also assert the VSYNC signal to the panel, then start counting down all of the vertical values as each line comes in.
VSync length: RTD Will de-assert the panel’s VSYNC signal when this count is reached.
Vertical active start: RTD will start sending the visible picture when this count is reached. Caveat: If this is set to, say, 30 lines, but the PC is already sending in picture after just 10 lines from the beginning of VSYNC then some of the top of the visible picture will be lost, as the RTD only has a very small FIFO for storing prematurely arriving picture data. This will show as a vertical “Offset” or perhaps just flickering at the top of the screen. Once again – Get the EDID correct.
The period between the start of VSYNC, and this, is known as the “Back Porch” Vertical active end (Automatically set from input in Frame sync mode):
This marks the end of the visible area, and is mostly unused except for positioning OSD elements.
Vertical period total: (Automatically set from input in Frame sync mode):
Once again, this is mostly only relative in Free running mode to determine the calculation of DCLK.
The period between the end of the active area, and this, is known as the “Back Porch”.
Vertical active: This is an automatically calculated value, which is the Vertical active end minus the Vertical active start.
(Horizontal timings): Are all the same but based on pixels instead of lines.
Larger panels (typically anything over 1366×768) always have two LVDS input channels (and a lot more wires), for these panels, set “Double” output.
Internally RTD’s output is 24-bit only, but if this is set to 18-bit, bits R0, R1, G0, G1, B0 and B1 will be clamped to ‘0’. The effect of this is that LVDS Tx3 will effectively transmit nothing, because the LVDS output will always be set to “FPD-Link” mode (more about that in the next section).
24-bit LVDS format
Just to make life really difficult, there are two different ways of transmitting 24-bit picture data over LVDS. These are:
FPD-Link (Original specificaton)
Also known as: “OpenLDI”, “LVDS 24.0”
In this mode, the fourth LVDS pair (Tx3) carries bits R0, R1, G0, G1, B0 and B1. The data in the first three pairs is shifted up two bits.
This standard was designed to allow 18-bit and 24-bit panels to interoperate by simply not connecting the missing LVDS pair.
Also known as: “SPWG”, “LVDS 24.1”
In this mode, the fourth LVDS pair (Tx3) carries bits R6, R7, G6, G7, B6 and B7. The data in the first three pairs are unchanged.
This standard is an unnecessary annoyance which breaks compatibility between 18-bit and 24-bit panels.
DPLL_CRNT: This register, who’s value is typically calculated at runtime, may be overridden. I have put this here to fix an issue I have seen with a number of builds where DCLK is horrendously unstable. Typically setting the DPLL_CRNT register to 80h fixes it (where is was previously dynamically set to 87h).
LVDS_CTRL2: Not really anything you’d want to fiddle with here.
LVDS_CTRL3: This register contains the LVDS format bit, but the interface automatically sets that, so no need to touch this value either.
LVDS_CTRL4 + LVDS_CTRL5:
These registers would allow one to disable the VSYNC and HSYNC when a “DE Mode” panel is used, which won’t make use of these signals. But eh, given that these signals are ignored by a DE Mode panel, there’s not really any tangible benefit of fiddling with these either.
Last but not least, the EDID blocks which are transmitted over the VGA and DVI interface. I don’t support the editing of these in this program, but can export to Phoenix EDID Designer, which is fairly easy to get a hold of. The most important stuff to look at here is under the “Detailed timings” tab. Generally, so long as you start from an EDID of a panel that’s close, nothing else needs tweaking.
It’s really important that what’s entered in here is correct, as it makes up most of what is finally transmitted to the panel by the RTD.
The representation of timings in Phoenix EDID Designer is quite different to what appears in ROVAEdit, because to RTD, the start of VSync is considered the start of frame, where as in an EDID, the first active line is considered the start of frame. I would recommend reading up on display timings in order to make sense of it all. It’s quite a learning curve.
In some cases “Detailed timings” aren’t needed if the LCD panel is able to operate within a standard timing.
Q: This is all a bit difficult to understand, Can’t you make this easier?
A: No. This stuff is not trivial. I generally assume people understand what they’re doing, or have the willingness and patience to learn before they go anywhere near applications such as this!
Q: I just loaded up a source file, and the settings in it don’t match the file name!
A: There are quite a few images in who’s true configuration doesn’t match what is described in the filename.
Q: What do I enter into the VSync/HSync values for a “DE Mode” panel.
A: It doesn’t matter. DE Mode panels don’t use these signals. Instead ensure that the Vertical/Horizontal blanking periods are correct as the panel will infer from these.