The last log got me thinking a bit more about my old display projects (e.g. https://sites.google.com/site/geekattempts/home-1/drive-an-old-laptop-display-from-an-avr and #my very first binary-clock, which I just got working again).

And, I remembered... wait a minute... some displays don't actually USE Hsync... INCLUDING some of the displays where I've actually encountered repeated-rows!

So, some overview...

Some (many?) TFT's these days are "DE-Only"... wherein they don't actually make use of the Hsync and Vsync signals, but base the entirety of their timing on the Data-Enable input. WTF. So, basically, what that means is:

Data-Enable is used to indicate when pixel-data is being written. Unlike CRTs (or VGA-interfaced LCDs) which have to guess the location of the pixels based on the horizontal-porch-timings, most bare LCD panels (like found inside your laptop/TV/monitor) have a Data-Enable input which *tells it* when pixel-data is coming-through. Thus, basically, the rising-edge of DE indicates the first pixel in the row, and the falling edge indicates when the last pixel in the row has been drawn.

(Oh, by the way, also unlike CRTs, LCDs *usually* have a pixel-clock... CRTs usually *don't*... look at the VGA pinout, no pixel-clock! If you've got a VGA-interfaced LCD, then it most-likely has circuitry inside to recreate a pixel-clock for the LCD panel.)

(LG Electronics LP121X04)

You can guess, then, that Hsync (and specific-duration H-porches) are unnecessary, when using DE... Instead of paying attention to Hsync, just look for DE going inactive, then reactivating... that indicates a new row.

And some displays do just that, completely ignoring the Hsync input. ("DE-Only" displays).

The interesting bit is that Those Displays (usually) actually ignore the Vsync input, as well.

Wait, what? How does DE indicate that...?

So, my guess is that somewhere in the display's circuitry there's basically something like a counter... That counter says "OK, I've received X number of pixel-clocks but no pixel-data, so we must be doing a new frame"...

(SHARP LQ121S1DG81, 800x600. Has H/V-sync inputs, but apparently ignores them.)

Arighty-then... It's not *that* complicated... A *really* simple implementation might be to say something like... Say we've got a 1024x768 display... normal 1024x768 timings (e.g. sent to a VGA monitor) may have an h-porch of up to 1000 pixels, so if there are, say, more than 3000 pixel-clocks between Data-Enables, then consider it a new frame.

Of course, every display is going to implement that differently... One might be 3000 pixel clocks, another might be 30,000 (v-porches may be in the hundreds of rows, and rows may be thousands of pixel-clocks).

Or, another way it might be implemented is simply by the DE-detection circuit's knowing exactly how many rows are on the panel... Simply count 768 DE-actives, then restart at the top. (That could get complicated if the LCD-panel is turned on *after* the signal starts... (or if the PLL in the LVDS-receiver doesn't sync until after a few rows of data) how would it know where the top is...? Again back to the counting inactive pixel-clocks).

....

But the oddity discussed in the last log... an oddity that I've seen (and kinda want to take advantage of), the repeating of rows... I've seen it on DE-Only displays... How's that work?

Again, with a Hsync/Vsync display, it would make sense that e.g. strobing Hsync Twice might not allow for the column latches to load a new row of image-data, so they probably still store the previous row's data... So two Hsyncs would advance the row twice, but no new data would be loaded, so two rows would display the same data. (see the last log).

But, with a DE-Only display...? Who knows... That display ONLY looks at the DE-signal, ignoring Hsync, completely. One possibility, maybe... Say DE is usually active for 1024 columns (1024 pixels in a row), then say it's only active for *1* pixel the next time around...

Another possibility, now that I've written/revised this a few times, I think I remember seeing this: What happens when DE is active for *far too long*... For *longer* than one row's worth of pixels...? Somewhere in there, again, there's a counter. So when the DE signal is active for too long, eventually the DE-detection circuit's counter might overflow, causing a row-advance, but the column-latches themselves still contain the data from before, causing a repeated-row. Unfortunately, this "method" wouldn't lend itself well to my most-recent plan of doing real-time framebuffer-less resolution-upscaling :/

I haven't experimented with it to the extent to make it repeatable. But I have *definitely* seen repeated rows, and I'm certain I've seen it occur on DE-Only displays, as well. So... The question becomes... is that something that can be characterized to the extent that it can be made use of?

This is where it gets complicated... Because different DE-Only displays *probably* implement their DE->row-advance->frame-advance detection-schemes differently. Atop that, the manufacturers have very little (if any) reason to *document* that scheme, since the important thing in the *vast majority* of cases is that it works with a single "native" signal-timing that happens to match-up with a typical VGA-timing-scheme... Long LONG horizontal porches, Long LONG vertical porches... ("long" when compared to what's necessary for a digital circuit such as the horizontal/vertical shift-registers in an LCD).

So, it may be possible to figure out how to repeat a row on one display, but that scheme may not work for another.

FYI, here's one of the most-detailed diagrams of a display's internal-workings I've seen documented in a display's datasheet:

(LG Electronics LP121X04)

Not much to go by, there, for hack's sake... guess you've just gotta experiment :)