There are a number of different buffers between your program and the screen:
- in-memory surface of SDL when using a software surface
- the Linux frame buffer
- the GRAM of the ILI chip
You get tearing when the copy from one buffer to the next is not synchronized.
The design of A320 PCB does not allow reading of ILI registers, which makes it impossible to synchronize the transfer from the frame buffer to GRAM. Well, impossible is a big word, but the obvious solution doesn't work and so far no-one found a non-obvious solution. So, tearing is unavoidable here.
You control when SDL copies its in-memory buffer into the frame buffer by using SDL_Flip() or SDL_UpdateRect(). So here you can avoid tearing when using a software surface.
If you use a hardware surface, the in-memory surface does not exist and you write directly into the Linux frame buffer from your program. This means that changes you make to the picture can become visible at any moment. So if you paint in layers, it's possible the lower layer will be made visible before the upper layer is painted, resulting in flickering. If you paint in one go, there is no problem though and you gain some speed by not using an intermediate buffer and an extra copy step.
There is a bug in the SLCD driver in the 2.6.24 kernel that makes weird things (crashes, hangs etc) happen when using a hardware surface with double buffering. In OpenDingux this bug does not exist. Older versions of OpenDingux do not support double buffering, but recent versions do. The upload to GRAM is not synchronized yet to the page flip, so there might be glitches, but this is something that I plan to fix soonish. Even right now, the extra performance might be worth the occasional glitch.