quoted

quoted

Can you send a couple of links to the modules you are considering?

quoted

there are some 320x240 from EDT (Emerging Display Technologies) with

S1D13305

quoted

S1D13700
http://www.actron.de/graphic_displays_edt.htm

also from Powertip a 320x240 with S1D13305/ S1D13704 is available
http://www.actron.de/graphic_displays_powertip.htm

and also from ampire is one ... (available /w or w/o Epson's S1D

controller)

quoted

http://www.ampire.com.tw/AmpireCatalogue/P082-AT320240Q3.pdf

Ok, I see the problem with the S1D13305, but the S1D13704 looks ok.
In order to work as a linux framebuffer, the cpu must be able to directly
address
pixels.  You can't have a controller like the 13305 that makes you write a
pixel address and then write the pixel.  A controller like the 13704 just
makes
the pixel memory look like RAM, so it's easy to interface.

I have done this in the past when the cpu could not directly access the
pixels.  I created a virtual framebuffer in RAM, and had a timer-driven
routine that regularly sent the contents of the virtual framebuffer to 
the LCD device through the "register bottleneck" of the LCD device interface.
It actually worked well.  I expected a big performance hit with all the 
additional bus activity, but it was not bad (no, I don't remember any
numbers).  The platform had a 48 MHz mpc8xx if I remember correctly,
and the LCD device was an old Epson chip that had a registered interface
(no direct access to pixels).

It is not an optimal situation, but if you find yourself stuck with an LCD
device that does not provide a RAM-like interface to the pixels, then it is
at least a known-working solution.

Chuck Meade
The PTR Group