iLiad xepdmgr - another approach to auto-refresh

[sphaero]

Nope /bin/cat doesn't work. It needs to be in the foreground on a tty.

DISPLAY=127.0.0.1:0 /home/root/xepdmgr 127.0.0.1:0 /bin/cat [2] + Stopped /home/root/xepdmgr 127.0.0.1:0 /bin/cat
root@ereader:~# bg
[2] /home/root/xepdmgr 127.0.0.1:0 /bin/cat

[Antartica]

Originally Posted by sphaero

Nope /bin/cat doesn't work. It needs to be in the foreground on a tty.

I attach to this message version 1.9d. If the application to launch is "-", it will not launch any application but just wait for a Ctrl-C (or kill -INT pid_of_xepdmgr).

For example:

$ ./xepdmgr :0 - &
$ echo pid is $!

Hope that this is what you needed.

P.S.: It also fixes a bug when using --debug, and now it is possible to compile xepdmgr-dummy again (it had rotten somewhat, now it works as expected).
P.S.2: I've updated the first post of this thread with the information of the versions of xepdmgr, and with references to the posts that have installation or use instructions.

[sphaero]

I'm sorry I couldn't test any sooner but I'm getting a segmentation fault:

root@ereader:~# ./xepdmgr1.9d 127.0.0.1:0        
Segmentation fault

I've tried compiling it myself but no difference.

[Antartica]

Originally Posted by sphaero

I'm sorry I couldn't test any sooner but I'm getting a segmentation fault:

In version 1.9d I broke the server mode if there were parameters (only worked if launched without specifying the display).

It's fixed in this version, if you can test it I would be grateful .

[ericshliao]

I have some idea about updating fbdev in advance.
Based on my current understanding, ipdf preloads the next page in background and writes image data to fbdev, so that when pagebar is flipped, the next page will be drawn from fbdev directly. That's why ipdf can update a page as fast as in 2 second.
When I used xepdmgr, I could get page refresh in as fast as 3 seconds when I prepared the next page in background. I guess the one second difference was due to not pre-writing to fbdev in advance.
Is it possible for xepdmgr (or xepdmgrclient) to provide a function for apps to control writing to fbdev in advance?

[sphaero]

I've tested version 1.9e:

From a ssh session:
client mode with child

./xepdmgr 127.0.0.1:0 ./ghello.o --display=127.0.0.1:0

Works.

client mode without child:

./xepdmgr 127.0.0.1:0 -
./xepdmgr: client mode, without child

Works. But server mode doesn't

server mode:

root@ereader:~# ./xepdmgr 127.0.0.1:0
Error invoking bind: Address already in use
./xepdmgr: error binding the server udp socket (is there other displayMgr runnin

Doesn't work. I am running the displayMgr.

If I kill DisplayMgr:

root@ereader:~# ./xepdmgr 127.0.0.1:0
./xepdmgr: server mode
(W)erdmServer.c:62,initServer() Bound successfully to 127.0.0.1:50555.

So are you suggesting to not use DisplayMgr?

Rg

Arnaud

[Antartica]

Originally Posted by sphaero

I've tested version 1.9e

Thanks!

Originally Posted by sphaero

So are you suggesting to not use DisplayMgr?

Yes. The idea in "server mode" is to be a drop-in replacement for displayMgr; using xepdmgr to talk with the delta driver directly.

But there are some problems to resolve yet in server mode:
1. ContentLister is not updated always (?)
2. double-refresh with ipdf when ipdf updates fbdev directly bypassing the X server
3. refreshes with the soft-keyboard (it has strange behaviour here).

It's not very simple because there is information flowing from displayMgr to and from contentLister, and I'm not sure of the rationale of it. Problem (1) and (3) are related to this.

Another thing is that when the application (ipdf) uses the "update the screen bypassing X" hack to gain 1 second in the refresh, it's not informing anyone of it (It simply assumes that if he is not signaling an update, no update will be done, and that is contrary to the intent of xepdmgr). Perhaps doing an heuristic it can be avoided, but I'm not sure if it will work correctly (as the refresh is done prior to X informing of the damaged area). I'll have to try it. This is problem (2).

And in general, I have to improve the heuristics for how much time to wait after a damaged part is detected; this wait is used to be able to bundle multiple small updates in a single screen flash, but right now is fixed.

Anther thing left is the problem of note-taking programs (scribble-like; i.e. Xournal). I've not tried to resolve that problem yet.

So, that is the current state of the program .

[Antartica]

Originally Posted by ericshliao

Is it possible for xepdmgr (or xepdmgrclient) to provide a function for apps to control writing to fbdev in advance?

How about:

EpdCancel(sEpd *Epd); // Unlike EpdFlush(), canel timeouts but just discards any pending refresh

This way, the app could do the following:

EpdRefreshAuto(Epd,0)
.
.
// Here the app updates the fbdev and does the ioctl to update the screen
// After that it would refresh the X window
.
.
EpdCancel(Epd);
EpdRefreshAuto(Epd,1);

Does that sounds right? If it is, say so, and I'll add the EpdCancel() function to xepdmgrclient.c

[ericshliao]

Originally Posted by Antartica

How about:

EpdCancel(sEpd *Epd); // Unlike EpdFlush(), canel timeouts but just discards any pending refresh

If I get your idea exactly, the basic idea is to disable auto refresh of xepdmgrclient temporarily for app to write to fbdev and then re-enable auto refresh. That should be a solution. Thanx.

[Antartica]

Originally Posted by ericshliao

If I get your idea exactly, the basic idea is to disable auto refresh of xepdmgrclient temporarily for app to write to fbdev and then re-enable auto refresh. That should be a solution. Thanx.

Yes, that is the idea.

Attached is a new version of xepdmgr/xepdmgrclient that implements EpdCancel().

Please post if this solution works .

[ericshliao]

Thanx.
I am stuck by some thread issue. It seems that Gthread in GLIB is not working with gtk_main(), and only pthread can be used with gtk_main(). I will try it later.

[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.
The code in xepdmgr is too complicated for me to understand. By conjecture, I guess xepdmgr use some xlib function to detect refreshment request. Without X, can we still have a automatic screen refreshment control program?
If the answer is no, then we have to insert dmDisplay() call in every QT/E application to control screen-refreshment.

Maybe modifying QT/E lib by inserting dmDisplay() call is a possible solution. Is the idea similiar to that old modded X11 libs?

[Antartica]

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.

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.

[ericshliao]

Thanx for all the detailed expalnation. I guess I will try to code refreshment in individual app, just like the way ipdf does. It's the only possible way that's within my coding skill.

[ericshliao]

Originally Posted by Antartica

1) Do as iRex has done for GTK+ on the DR1000, that is, touch every widget drawing code to make it self-update.

This approach seems quite nice. I will study it also. Fortunately, I can see how iRex does the job.