Previous page: Writing Pixels  
Framebuffer Intro    
Initial investigation led me to try and update the screen by writing values to individual bytes in the memory mapped framebuffer. This does actually update the display, however I found that the screen memory is split into groups of 4 bytes. If we number these 0-3, then the following describes the action when each of these gets set with a value:
ByteAction when set
0Byte 1 set to same value
1Byte 0 set to same value
2Byte 3 set to 0
3Byte 2 set to 0
As you can imagine, this is pretty frustrating. It appears that we can never set pixels exactly as we wish.

After some investigation, I discovered that setting 16 bytes at a time correctly sets all the pixels. This is using either the memset() or memcpy() functions (either when setting blocks to one colour or using a backup copy of the display and copying to the framebuffer as required). I am assuming that the implementations of these functions in the C library does something different for blocks of 16 bytes. Or else the kernel video driver behaves differently. I don't know. If anyone has an explanation of this, please let me know, but there it is. As far as I know, you have to update the framebuffer 16 bytes at a time or you will not get the results you want.

Previous page: Writing Pixels  
Framebuffer Intro