iLiad xepdmgr - another approach to auto-refresh

[hansel]

Originally Posted by Antartica

But I have an idea that, if it works, will allow us to overcome that limitation: brushes are indeed implemented ...

Brilliant idea again! I hope it works out.

[ericshliao]

Is there any improvement in speed in xepdmgr 1.9i? I have a feeling that the speed of screen refresh is improved. I am not quite sureabout the fact, since the improvement in speed is very tiny, and maybe it's just my imagination.

[Antartica]

Originally Posted by ericshliao

Is there any improvement in speed in xepdmgr 1.9i? I have a feeling that the speed of screen refresh is improved. I am not quite sureabout the fact, since the improvement in speed is very tiny, and maybe it's just my imagination.

The timer code wasn't touched. There is some code to put a smaller timeout for refreshes in case of small changes, but that code is disabled right now as it didn't feel better in my tests. And now that I look at that code, it requires to update the dirty pixel count every time a new dirty area is added, and that is not done right now :-o... if I use that code for the brushes experiments I'll fix it, as it is a matter of moving some code around .

So, in short, it shouldn't be any faster...

[ericshliao]

Originally Posted by Antartica

So, in short, it shouldn't be any faster...

So, it's confirmed that I had illusion or imagination then. Thanx for the clarification.

[ericshliao]

Antartica,

I am trying to create a simple program so that I can call it to do a full-screen refresh in shell. The following code are borrowed from your xepdmgr. I can compile it with gcc without problem, but I haven't really tried it on my iLiad.
Please comment on the following code if it will provide what I want.
Thank you so much.

#include <stdlib.h>
#include <stdio.h>
#include <unistd.h>
#include <string.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <sys/ioctl.h>

/* ioctl numbers */
#define FBIO_UPLOAD_WAVEFORM 0x40007606
#define FBIO_ERASE_WHITE     0x40087602
#define FBIO_DISPLAY         0x40087601
#define FBIO_DISPLAYPARTIAL  0xfff

/* ioctl structures parameters */
#define WAVEFORM_4BPP_IMAGE       1
#define WAVEFORM_DRAW             4
#define WAVEFORM_FAST_BLACK_WHITE 6
#define WAVEFORM_TYPING           9

/* ioctl structures */
struct display_update_info {
    int waveform;
    int sequence;
};

int main(int argc, char *argv[], char *envp[]){
    struct display_update_info Update;
    int error;
    Update.waveform = WAVEFORM_4BPP_IMAGE;
    Update.sequence = 0;

	int fd;
	if((fd=open("/dev/fb0",O_RDWR))!=-1){
		ioctl(fd, FBIO_ERASE_WHITE, &Update);
	}
    return(0);
}

[Antartica]

Originally Posted by ericshliao

I am trying to create a simple program so that I can call it to do a full-screen refresh in shell. The following code are borrowed from your xepdmgr. I can compile it with gcc without problem, but I haven't really tried it on my iLiad.
Please comment on the following code if it will provide what I want.

It looks OK for me. One minor thing: you forgot to close() the file descriptor after the ioctl. That is:

...
	int fd;
	if((fd=open("/dev/fb0",O_RDWR))!=-1){
		ioctl(fd, FBIO_ERASE_WHITE, &Update);
		close(fd);
	}
    return(0);
}

Just for reference, there is one advantage to use displayMgr to manage the update instead of doing it directly like this: displayMgr will make sure that you don't update the display too fast for the driver to handle it (although I don't know if that is important).

BUT bear in mind that xepdmgr cannot be used without X; OTOH plain displayMgr can.

[Antartica]

Originally Posted by Antartica

		ioctl(fd, FBIO_ERASE_WHITE, &Update);

Ups! I've just realized that the ioctl that you have selected is for clearing the screen, not for updating it. You have to use FBIO_DISPLAY to do a screen refresh (it has the same parameters as the ioctl to clear the screen, so the change to your code is smallish):

		ioctl(fd, FBIO_DISPLAY, &Update);

[ericshliao]

Thanx. I didn't really try my above code on my iLiad. The displayMgrClient that you mentioned can fulfill my objective.

BTW, does it means that the function that I copied from xepdmgr is buggy?

[Antartica]

Originally Posted by ericshliao

Thanx. I didn't really try my above code on my iLiad. The displayMgrClient that you mentioned can fulfill my objective.

BTW, does it means that the function that I copied from xepdmgr is buggy?

No; I've looked up the sources and the function that does the refresh in xepdmgr_einkfb.c uses the correct ioctl.

[tango.0309]

Hai,

I request you to send me some tutorials/examples regarding usage and understanding on X EPD to use it in applications.

I having some query's on X EPD Manager:

Can We use it for screen refresh in applications using WX widgets and TinyX server.

can we use it in applications which are ported on hardware having dual screen.



Regards,
tango.

Originally Posted by Antartica

I've finished the first version of xepdmgr, but I've to recompile the X libraries for the iliad as I don't have the needed libXdamage.so.1 and related headers in the scratchbox environment

Anyway, if someone wants to look at how it's at the moment and try it in his desktop (you will have a nice line in stdout when the iliad refresh would be invoked), here it is.

To compile, just do "make" in the directory.

It has two modes of being used, as an standalone server and as a wrapper for one program only.

As a standalone server:
1. In one window launch ./xepdmgr :0
2. In another window exec ./xepdmgrtest
3. To futher tests, exec ./xepdmgrtest --help
4. When you want to stop the server, just hit Ctrl-C in the server window

As a wrapper for one program only:
1. Just exec ./xepdmgr :0 ./xepdmgrtest
(or ./xepdmgr :0 xterm)
2. When you exit the launched program, xepdmgr also exits

I'll document the inner workings and the meaning of the different commands that can be send with xepdmgrtest on another messsage, as today is somewhat late for me :-).

OTOH, the xepdmgrclient.h and xepdmgrclient.c are intended to be included in your programs to be able to communicate with the server; see xepdmgrtest.c for an example. Multiple clients are allowed at once, but races can occur in that case (if two programs send a message to the server in the same exact moment, one of the messages will be lost).

Something that makes this interesting as an alternative to the hacked libX11 is that [when I manage to compile xepdmgr for the iliad] the problem of having exported windows on the iliad will vanish, as they would auto-refresh correctly ;-).

Advantages of this approach:
- lets the application force refreshes (or delay them) when needed, unlike the hacked libX11.
- Has some heuristics as to when to use the full refresh or the Typing refresh, as it knows how big the portion to refresh is (for small portions it will use the Typing refresh, and for large portions the Full refresh).

Enjoy your hacking!

[Antartica]

Originally Posted by tango.0309

I request you to send me some tutorials/examples regarding usage and understanding on X EPD to use it in applications.

I having some query's on X EPD Manager:

Can We use it for screen refresh in applications using WX widgets and TinyX server.

can we use it in applications which are ported on hardware having dual screen.

xepdmgr works in any X server that supports the DAMAGE extension. TinyX supports it so no problem. To query a X server if it supports the DAMAGE extension, use the following command in a shell:

$ xdpyinfo | grep DAMAGE

If it says "DAMAGE" it is all right.

About WX widgets: xepdmgr is toolkit-agnostic, so that is also covered. You can use it for wxwidgets applications.

About using xepdmgr in hardware different from the iliad: you will have to adapt the code, as it uses ioctls specific of the iliad to signal the e-ink driver to refresh. The dual screen setup is not a problem. If only one of the screens is e-ink, just have different X servers for each screen (so each has its own display, i.e. :0 and :1).

Specifically you will have to

1. adapt the xepdmgr_einkfb.c file for your e-ink driver

2. insert the following code in xepdmgr.c to omit the dependencies to irex libraries (code taken from the DUMMY_BUILD target):

/* Setup some macros so that we can build without irex libraries */
static int dummy_var;
#define initServer(ptr_udp_fd,b) ((*(ptr_udp_fd))=0)
#define dmMessageParser(a,b) 1
#define dmDisplay(a,b) dummy_var=0
#define erIpcStartClient(a,b) ((*(b))=0)
#define clDisplayUpdated(a) dummy_var=0
#define busySetBusy(a,b) dummy_var=0

3. Modify the Makefile and delete "-lerdm -Lliberipc -leripc"

4. Build xepdmgr ("make xepdmgr")

5. In the target hardware, use xepdmgr in "server mode", that is, launching it as "./xepdmgr :0".

Hope that helps.

NOTES:
- there is an alternative implementation in lua by Hansel called "xx" elsewhere in the forums. May be worthwhile to take a look at it.
- the "meat" of xepdmgr is just using the damage extension of the X server to have the information of when something has changed in the display and what portion of the display to update. You can roll your own update maanager easily having the code of xepdmgr and xx as a guide.

BTW, out of curiosity, if you are allowed to say it: to what e-reader are you intending to port it?

Happy hacking

[tango.0309]

Hi Antartica,

I want to send damage events to "xepdmgr" with (x,y) coordinates and (width,height) of the damaged region.The present "xepdmgrclient.c" is sending only property event. I found in xepdmgr is capable of receiving damage events. I am not clear in sending damage event to xepdmgr, whether any changes required in xepdmgr server side also.
note:
I am exploring "xepdmgr-1.0-iliad" code.

Regards,
tango.

Originally Posted by Antartica

xepdmgr works in any X server that supports the DAMAGE extension. TinyX supports it so no problem. To query a X server if it supports the DAMAGE extension, use the following command in a shell:

$ xdpyinfo | grep DAMAGE

If it says "DAMAGE" it is all right.

About WX widgets: xepdmgr is toolkit-agnostic, so that is also covered. You can use it for wxwidgets applications.

About using xepdmgr in hardware different from the iliad: you will have to adapt the code, as it uses ioctls specific of the iliad to signal the e-ink driver to refresh. The dual screen setup is not a problem. If only one of the screens is e-ink, just have different X servers for each screen (so each has its own display, i.e. :0 and :1).

Specifically you will have to

1. adapt the xepdmgr_einkfb.c file for your e-ink driver

2. insert the following code in xepdmgr.c to omit the dependencies to irex libraries (code taken from the DUMMY_BUILD target):

/* Setup some macros so that we can build without irex libraries */
static int dummy_var;
#define initServer(ptr_udp_fd,b) ((*(ptr_udp_fd))=0)
#define dmMessageParser(a,b) 1
#define dmDisplay(a,b) dummy_var=0
#define erIpcStartClient(a,b) ((*(b))=0)
#define clDisplayUpdated(a) dummy_var=0
#define busySetBusy(a,b) dummy_var=0

3. Modify the Makefile and delete "-lerdm -Lliberipc -leripc"

4. Build xepdmgr ("make xepdmgr")

5. In the target hardware, use xepdmgr in "server mode", that is, launching it as "./xepdmgr :0".

Hope that helps.

NOTES:
- there is an alternative implementation in lua by Hansel called "xx" elsewhere in the forums. May be worthwhile to take a look at it.
- the "meat" of xepdmgr is just using the damage extension of the X server to have the information of when something has changed in the display and what portion of the display to update. You can roll your own update maanager easily having the code of xepdmgr and xx as a guide.

BTW, out of curiosity, if you are allowed to say it: to what e-reader are you intending to port it?

Happy hacking

[Antartica]

Originally Posted by tango.0309

I want to send damage events to "xepdmgr" with (x,y) coordinates and (width,height) of the damaged region.The present "xepdmgrclient.c" is sending only property event. I found in xepdmgr is capable of receiving damage events. I am not clear in sending damage event to xepdmgr, whether any changes required in xepdmgr server side also.

You have some misconception: xepdmgr makes screen updates automatic, as in "the app doesn't need to send damage events to xepdmgr".

xpedmgr gets the damage events directly from the X server.

xepdmgrclient implements a protocol to send some messages to xepdmgr to optimize the screen refresh, but it is not needed for the basic operation.

xepdmgrclient exists because it is very common for a reader application to update the entire screen with a new page of content and wanting to display it ASAP, not wanting the timeout to pool requests that xepdmgr uses in its "autonomous" operation. Also xepdmgrclient makes possible to avoid double-refreshes by signaling xpedmgr to "freeze" the display while doing some slow screen update, and "thaw" it after the drawing has finalised, hence updating the display only once (this is only useful for screen updates that are longer to perform than the xepdmgr timeouts, that are 500ms in the current 1.9i implementation).

note:
I am exploring "xepdmgr-1.0-iliad" code.

Please, use version 1.9i as it fixes numerous bugs compared to 1.0 version. It is available in the following post (it has sources included):

https://www.mobileread.com/forums/sho...&postcount=146

If you have additional questions, don't hesitate to ask.

Best regards,
Antartica.

[tango.0309]

Dear Antartica,

We are using X EPD Manager 1.3 version on X11(compiled with xcb option).
The version of xcb is 1.1.
In this case the refresh is not happening properly.
(The screen will be refrehed partly initially later fully. In case of pop up windows of our application, each window is refreshed twice)

I request you to suggest where is the problem.

Thanks and Regards,
P.Ravi Sankar.

Originally Posted by Antartica

You have some misconception: xepdmgr makes screen updates automatic, as in "the app doesn't need to send damage events to xepdmgr".

xpedmgr gets the damage events directly from the X server.

xepdmgrclient implements a protocol to send some messages to xepdmgr to optimize the screen refresh, but it is not needed for the basic operation.

xepdmgrclient exists because it is very common for a reader application to update the entire screen with a new page of content and wanting to display it ASAP, not wanting the timeout to pool requests that xepdmgr uses in its "autonomous" operation. Also xepdmgrclient makes possible to avoid double-refreshes by signaling xpedmgr to "freeze" the display while doing some slow screen update, and "thaw" it after the drawing has finalised, hence updating the display only once (this is only useful for screen updates that are longer to perform than the xepdmgr timeouts, that are 500ms in the current 1.9i implementation).



Please, use version 1.9i as it fixes numerous bugs compared to 1.0 version. It is available in the following post (it has sources included):

https://www.mobileread.com/forums/sho...&postcount=146

If you have additional questions, don't hesitate to ask.

Best regards,
Antartica.

[Antartica]

Originally Posted by tango.0309

In this case the refresh is not happening properly.
(The screen will be refrehed partly initially later fully. In case of pop up windows of our application, each window is refreshed twice)

You can try with a larger refresh timeout. In xepdmgr.c, change the line that says:

#define REFRESHTIMEOUTMS 500

To something larger, such as

#define REFRESHTIMEOUTMS 750

And see if the double refreshes disappear with that.

Rationale: After receiving a damaged area from the X server, xepdmgr waits for more damaged areas for REFRESHTIMEOUTMS milliseconds, and if no more damaged areas are received in that time period it refreshes the screen. Larger values for REFRESHTIMEOUTMS makes double-refreshes improbable, but provoke worse responsiveness. Requiring values higher than 1500 is a symptom that something is wrong, either in the app (too slow) or in xepdmgr (a timing bug?).