Quote:
Originally Posted by ericshliao
Now that I have QT/E ported to iLiad, and still got stuck by the same old problem: screen refreshment, I am thinking if xepdmgr can control screen refreshment without X.
|
First of all, congrats for your port
About using xepdmgr's approach: no, the way xepdmgr works will not work with Qt/E (or any other direct-to-framebuffer tookit/library; it won't work with directFB either).
xepdmgr uses de XDamage extension to be informed by the X server when a region of the screen has been updated.
That means that it is completly dependant on using an X server. For Qt/E you have various options:
1) Do as iRex has done for GTK+ on the DR1000, that is, touch every widget drawing code to make it self-update.
2) Just enable a "dirty flag", and make the Qt/E primitives to set it to 1 whenever something is drawn to the screen, and have a periodic event that checks this flags and redraws the screen appropiately (and resets the flag to 0).
3) Touch the fb driver and implement auto-refresh via page access. IIRC, it was explained in one paper about apollofb or metronomefb (Jaya Kumar?).It's not trivial, and it's behaviour is disastrous for vertical lines. Basically, it divides the framebuffer in 4KB blocks (pages; that would be about 5 display lines in the iliad) and it writes down when a page has been accessed for writing. After some timeout, it updates the dirty lines.
Quote:
Originally Posted by ericshliao
Maybe modifying QT/E lib by inserting dmDisplay() call is a possible solution. Is the idea similiar to that old modded X11 libs?
|
I think that the libX11 approach is not useful for Qt/E. This is how it worked: The modded libX11 monitored the communications between the libX11 and the Xserver, and whenever bytes were sent/received, it thought that something would have changed in the screen. Some timeout after that (to try to avoid double refreshes) it would update the entire display.
As I've not programmed for Qt/E, I'm not sure how it communicates with the "screen", and depending if it writes to the framebuffer directly or passes along the commands to other process to do the drawing this would be feasible or not.
If it passes the command to other process, then you have to modify that "other process" to do the Dmxxx calls appropiately.