The key in most cases is to experiment and not be afraid to push (and even completely disregard) the documented limits. Look for those "easter eggs"!
-----------
In avr-lvds-lcd, dang-near all of the "abilities" (functionality at extremely low bit-rates, retaining images at extremely low refresh-rates, syncability with *huge* horizontal front-porches, repeating of lines, etc.) are undocumented by the manufacturers, and in fact go completely against the documented limits. Further, many of the "abilities" developed here are far-outside the de-facto methods. They can only be found by experimentation... And maybe a bit of understanding about what you're working with (e.g. TFTs by definition have "memory" at each pixel, so why not take advantage of that?)
Other extremes having been pushed on the AVR-side include using the PLL at 128MHz (documented to "saturate" at 85MHz) running the system clock at 32MHz (via the PLL, documented limit at 16MHz). Figuring out how to use the PWM outputs to create pseudo-FPD-Link serial-data signals that actually cover a reasonable range of colors and timing-signals. Pushing 512Bytes of RAM to handle a color image at 200x768 (That'd be 153KB in a frame-buffer!), and figuring out how to stretch that into a possible resolution of 600x768...
And yet even more extremes pushed: Being able to view these 128MHz signals on an analog oscilloscope rated for 20MHz. Level-triggering the 'scope on the fact that certain digital bit-patterns cause increased analog-overshoot and DC-offsets... (At these bit-rates and with this equipment, the digital bit-streams become quite a bit more analog, and therefore can not only be triggered at a certain point in the refresh, but the various porches and syncs can also be recognized when zoomed way-out).
...Using TTL chips older than I am; rated for 4.5-5.5V at 3.3V, rated for loads of >1Kohm at a load of 100ohms and finding the signals output are dang-near perfect for LVDS voltage-requirements. (Running them at frequencies way higher than they're rated and finding the analog effects to be *useful*).
And then there're other possibilities... For instance, considering the fact that two of the serial-streams are nothing more than color-data, essentially "red" and "green", it's entirely possible to have the timing generated by the processor and image-data generated by an entirely different source. With little more than two comparators, outputs tied directly to the red and green serial channels, this could easily be turned into a dual-trace oscilloscope. With an actual LVDS serializer chip, or maybe even a simple shift-register, it could be three-trace.
Then some other possibilities discovered... the particular "Data-Enable-Only" display I'm working with tries so hard to find valid syncing-signals that you can get interesting effects by simply sending a constant DE-signal... (Similar may be true for most displays DE-only or not?). With nothing more than a crystal oscillator (27MHz in my case), two shift-registers (one for the pixel clock, and one for the sync signal), a buffer, and an inverter, (no AVR necessary!), solid-colors can be generated... Could be used, e.g., for an adjustable color-filter on a stage-light. Or by introducing a bit of randomness it creates some interesting soothing "meditation" patterns. Again, just a handful of TTL parts.
So, yeah, it's maybe not possible with an 8-bit microcontroller to do full-color-full-resolution-fast-refresh video, but a shitton *is* possible.
Please also visit the avr-lvds-lcd code-page and browse the Projects links on this site to see more...