Re: Re: Fbdev magics

On Thursday 06 May 2004 06:17, Geert Uytterhoeven wrote:
...

So you cannot access the frame buffer memory from the CPU, except through
sending commands to the LCD controller, right?

Right, but today I discovered that the display controller allows to have DMA 
access for every "page" (8 lines on the display). Cool! ;-)

quoted

...
- how is the "refresh" done by fbdev? I don't want to keep sending the
same data to the display if there isn't any update to be done.

If the frame buffer memory is accessible directly by the CPU, it will be
updated automatically. If not, things get more difficult:
  - For text console output, 2.4.x will do direct accesses to the frame
buffer, which won't work.
    In 2.6.x, fbcon will call the fb_{fillrect,copyarea,imageblit}()
routines of your fbdev driver, so you can handle that easily
  - For graphics from user space, things are more complex, since the
    application cannot mmap() your frame buffer memory. Either you use a
shadow frame buffer that updates the hardware periodically, or teach your
application to talk to the LCD controller directly.

Given that DMA facility, I started to write the code with a frame buffer of 
the same size of the screen and installed an interrupt handler for the DMA; 
when a transfer of a page is done, it interrupts and I can switch this page 
and select another "page" to be automatically updated to the display.

It won't update the entire display at a single time, but it will probably make 
the magic. At least I got the impression that this could be a good logic, 
I'll do some tests tomorrow and will tell if everything worked fine then :-)

quoted

- also related to this refresh: I haven't seen any interrupt being
handled by many fbdev drivers. Is this ok? How will fbdev knows when the
card is trying to communicate with the CPU?

Most drivers don't use interrupts yet, because until recently (speaking
about 2.6), you could not use them there.

I've seen some LCD display drivers for embedded devices that handled it 
directly with request_irq() on 2.4. As I could see from the bottom layers of 
fbdev, an interrupt handler in a driver doesn't seem to hurt anyone there.. 
or am I wrong?

quoted

- given that I can be told when the user is going to write some data to
the fbdev (should I implement my own fb_read and fb_write operations?),
is there an automatic way to get only the pixels that he's modifying?
This would save a lot of unnecessary transfers to the display as well.

You should implement your own fb_{read,write}() if the CPU cannot access
the frame buffer memory directly.

quoted

Just forgot to tell that I'm running Linux 2.4.20 for ARM.

2.6 would make life simpler for you :-)

Sure, I'll give a look for 2.6 fbdev ASAP, it already seems to have a better 
interface, just by looking into the headers.

Cheers, and thanks for the reply,
Lucas


-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to 
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3