Most displays I've encountered from STN through TFT use row drivers and column drivers which essentially are little more than shift-registers... 

Imagine building a 24x16 LED matrix, one way to drive it would be to use five 74LS595's. Three daisy-chained for the 24 columns (Anodes) and two separately daisy-chained for the 16 rows (Cathodes, Invert those outputs).

Now you write a driver for this display, and basically you shift 1 active row onto the row-registers, and shift all the pixels in that row onto the column registers. Then shift the next row to be active, and shift in that row's pixels. And so-forth. The row clock is your Hsync, the column clock is your pixel clock. Vsync is accomplished by resetting the row-registers to the first row (reset the outputs to 0, then shift in one 1).

OK...

Now, imagine you shift in more than 24 bits, say 25, on a row, what'd happen? Well, as I recall of the '595, it'd result in your image being shifted to the right, losing your first few columns off-screen...

BUT: 

Display row/column drivers are designed backwards, for the sake of daisy-chaining, and for the sake of puting the first-received pixel at the left.

So, most I've run into (especially older ones. TODO link an OKI Column Driver) handle 64 columns. The first 64 data bits received are shifted to its 64 parallel outputs. Any bits received thereafter are shifted out of that chip and into the next. Once that second chip gets its 64 bits, it shifts any remaining bits to the next, and so-forth.

Thus, say you have a 128x64 STN LCD, you might accidentally try to drive it with a 64x64 input signal, and... in most cases I've run into it'll work. The image will be displayed at the left, and the right 64x64 pixels will display whatever garbage was in those registers from power-on/reset (and if you believe the hype, those liquid crystals might get unhappy with DC... but, I'm not sure about that, since the AC waveform is separate from the shift-register loading).

Now, here's where it suddenly, this evening, got interesting to me:

If you try to drive that with a 192x64 input signal, it will most-likely handle that just fine, as well. The column drivers don't know/care what's daisy-chained off of them. The first two happily receive and store (and display) the first 128 pixels, then spit the remaining out for the third, which just happens to not be attached. But they don't know that.

So, now.... hmmm....

What if we attached a 74LS595 to the output of that last column driver?

Or... maybe even a second display panel's first column driver?

Alright, so maybe that'd be difficult with today's displays, but maybe not. In fact many displays have test-points.

So, what-say your Raspberry Pi is wired to a 640x480 panel, and you configured it for 800x480, and tapped off the daisy-chain with a bunch of '595s? Maybe even 20 of them!

Now you have up to 160 outputs which can be toggled at 28.8kbps! (480x60Hz) or, little bursts of SPI (output only, of course) reaching 4.6Mb/s...

Could be handy.

Also, it shouldn't be too difficult to tap in a second display with a few trace-cuts and wires on the display itself...

The latter is something I'd been trying to figure out for some time, two displays on a lappy from the single display's input. I don't know why, but my brain was stuck this whole time in trying to use the regular input signals, rather than tapping to/from the panels themselves.

Or, heck, say you just want to add a friggin' indicator LED to your lappy's lid... if 60Hz is fast-enough, forgo the 595 altogether... 

Or maybe you dug out a groovy old stencilled LCD from an old lappy with a HD activity indicator, battery indicator, etc. and want to mount it next to the display. Or even a VFD for such things.... oooohhhh....

Heh, though a lot of that could also be done via DDC. Anyhow...

Oh yeah, this came from my escapades with a TI-86 over at #Vintage Z80 palmtop compy hackery ... the whole point was how to add outputs to a system without any.

...

MWAHAHAHA!

https://hackaday.io/project/179772-vintage-z80-palmtop-compy-hackery/log/193466-inside-the-ti-86

I'd forgotten that older displays often load multiple pixels (usually four, sometimes 8 on huge displays where one half and the other refresh simultaneously) side-by-side simultaneously via parallel data bits for each "pixel load" clock... which might well mean that FOUR LEDs or such could be driven this way with little to no extra circuitry. and, of course, more could be done with four parallel shiftregisters.