[okl4-developer] Starting with graphic output

[David Mirabito]

Hi all,
If I might chime in quickly here, it's not so much that a have a  
cached framebuffer will create problems for your code, but it could  
just look ugly.

We had a case once with an arm board where the LCD controller would  
DMA the framebuffer from main memory whenever it needed a refresh,  
asynchronously to whatever the CPU was doing at the time. Running a  
graphical app under an old version OKLinux and all worked fine -  
except for this odd effect on the mouse cursor. Whenever it was moved,  
we'd see lines of noise that would appear, and then quickly 'dissolve'  
leading to an unwanted sparkling effect.

It turned out that the framebuffer was being mapped as cached, and the  
noise was the background shining through as the LCD module read stale  
image data from the memory behind the cache. The dissolving was due to  
the CPU doing other stuff and eventually writing back those cache  
lines as part of normal business. After looking closely at the screen,  
we saw that these lines were exactly the same length as the number of  
<rgb> triplets that fit into a single cacheline!
Changing the mapping to uncached did away with all this, and we had a  
nice crisp mouse pointer back :)

Perhaps for slow-changing things such as a screenful of text this  
might not be noticeable but to be sure of avoiding it, we may as well  
just map the buffer as uncached for the general case.

Hope this clears something up,
cheers,
   David

On 07/05/2008, at 8:27 PM, Remy Gottschalk wrote:
>
> It seemed strange to me but i leaved it to default since it was done
> this way for the vga mapping. Even if it is pretty expected setting it
> uncached doesn't seems to create any problem for both vga and fb
> mapping.
>