iLiad Partial screen refresh?

[hansel]

Hello developers,

Is there really no way to do a partial refresh (a rectangular section) of the screen? That's what the include fles suggest (not implemented yet)...
... but the 'walking busy bricks' seem to do just that?!?

Hansel

[M@rcel]

I was told there are four different controller chips each handling 1/4 of the screen.

[igorsk]

Haha that's a good one.

[hansel]

What I'm looking for is a way to refresh only the dirty part of the display, like this (in .../arm-linux/include/liberdm/erdm.h)

// Not implemented
int dmDisplayPartial(eDmCmdPriority prior, eDmQuality qual, int xUp, int yUp, int xDown, int yDown );

[Antartica]

Originally Posted by hansel

What I'm looking for is a way to refresh only the dirty part of the display, like this (in .../arm-linux/include/liberdm/erdm.h)

I'm also interested in that. Also in the scribble way of updating, but I've not investigated it yet.

AFAIK, to do partial refreshes you have to open /dev/fd directly and do some ioctls. I don't know the ioctl's numbers or calling conventions, though.

The resources I know that can be useful to learn how to do that are:
- nalim's (Milan Votava) patch for 2.6 kernel has an implementation of the delta driver (display driver). http://www.kwik.cz/irex/
- use strace with the scribble program. AFAICT strace works in the iliad, and outputs to stdout every syscall, including ioctls. ltrace would be great too, but it doesn't work in the iliad, so we can't know what calls to liberdm are done in the scribble program.

If you need more pointers on how to investigate this, just ask :-).

[illiad_fan]

Originally Posted by Antartica

I'm also interested in that. Also in the scribble way of updating, but I've not investigated it yet.

AFAIK, to do partial refreshes you have to open /dev/fd directly and do some ioctls. I don't know the ioctl's numbers or calling conventions, though.

The resources I know that can be useful to learn how to do that are:
- nalim's (Milan Votava) patch for 2.6 kernel has an implementation of the delta driver (display driver). http://www.kwik.cz/irex/
- use strace with the scribble program. AFAICT strace works in the iliad, and outputs to stdout every syscall, including ioctls. ltrace would be great too, but it doesn't work in the iliad, so we can't know what calls to liberdm are done in the scribble program.

If you need more pointers on how to investigate this, just ask :-).

Hi Antartica,
I'm also interested in it, I'm writing a small program like scribble. Although I call dmDisplay(dmCmdPriorUrgent, dmQTyping); each stylus touch the screen, but the display update too slow(about 0.5s later). Could you show me how to strace the scribble?
Thank you very much

[Antartica]

Originally Posted by illiad_fan

Hi Antartica,
I'm also interested in it, I'm writing a small program like scribble. Although I call dmDisplay(dmCmdPriorUrgent, dmQTyping); each stylus touch the screen, but the display update too slow(about 0.5s later). Could you show me how to strace the scribble?
Thank you very much

For these instructions I assume that you have ssh access to the iliad (it can be done in mrxvt, but it can be somewhat frustrating to type the commands there).

I attach a version of strace compiled for the iliad.

First of all, to strace scribble you have to install strace in the iliad (i.e in /usr/bin/).

Then, substitute scribble with a script that calls strace and logs the results to a file

ereader# cd /usr/bin
ereader# mv scribble scribble.real
ereader# echo "#!/bin/sh" > scribble
ereader# echo "exec /usr/bin/strace /usr/bin/scribble 2> /mnt/free/scribble.strace.`date +%Y%m%d%H%M%S`" >> scribble
ereader# chmod 755 scribble

NOTE: Beware of the backticks (`) in the exec line; if unsure how to enter them, left the line as shown below instead and copy the resulting /mnt/free/scribble.strace file to a new name between tests;

reader# echo "exec /usr/bin/strace /usr/bin/scribble 2> /mnt/free/scribble.strace" >> scribble

Then comes the boring part, that is to generate the logs and analyze the output.

Fist generate a baseline compare file; just open scribble and exit it.
Copy the resulting /mnt/free/scrible.strace.<numbers> to your PC as scribble.strace.base

Then start doing more interesting things (like jotting a dot, then a line, then a lot of lines, etc).

Compare the resulting files with a source compare tool. If you're using Linux, meld is a good one ( http://meld.sourceforge.net/ ).

With that you'll get what does the app for the updates. What is missing is the initialization part. You could look in the scribble.strace.base for a line that mentions /dev/fb and if it's opened, look for lines that contain the file descriptor number that the open returned. if it access the screen by other means, you will have to investigate.

If you post here as an attachment some of the scribble.strace files, I can help analyzing them as time permits...

Good luck!

[hansel]

One neat trick with strace: you can hook into a running process with 'trace -p pid'. Of course you miss the startup events, but you can 'see' what happens on files and sockets... You can trace the window manager, contentlister, etc...

When you run it like 'strace -o outfile -ff program' it creates one output file per process (handy when the main process forks).

Antartica: any idea why ltrace doesn't work? I Tried several versions... They all fail with 'unexpected events' and stack overflows... :-(

Happy tracing!

[Antartica]

Originally Posted by hansel

Antartica: any idea why ltrace doesn't work? I Tried several versions... They all fail with 'unexpected events' and stack overflows... :-(

Same here; tried several versions and none of the worked. I don't have any idea of the reason of failing to work as I don't know how it does its magic.

Personally, the method I would use to do it would be examining the list of shared libraries,creating .so with stubs but with a trace prior to calling the "real" function the original library and load that .so with LD_LIBRARY_PRELOAD. But it seems that ltrace is far more smart that the method I supposed (it patches the elf in memory, it seems), so...

I've just found this link about the internals of ltrace:

http://people.redhat.com/~pmachata/r...ace-works.html

Browsing the document, it says that ltrace uses the debugging facilities of the system (it's a special-purpose gdb)... perhaps there is a problem placing breakpoints :-?.

[Antartica]

Hansel, reading the above link (the one about ltrace), I've learned that redhat's Frysk tool comes with an alternative ltrace implementation. The website is:

http://sourceware.org/frysk/build/

[hansel]

Hi,

- I straced scribble (and ipdf) for a few hours... It doesn't show the interesting parts (I think), because they dont' involve system calls.
- I spent a few hours experimenting with the ltrace sources (and googling)... without success and lots of segmentation faults ;-)
- I'm sceptic about the frysk stuff... megaproject (10.000s files), abnormal quantity of dependencies.
- For now I'll focus on making small apps with Gtk and Fox, refreshing with the liberdm stuff as described by Scotty1024 (Thanks Scotty!!!) https://www.mobileread.com/forums/sho...63&postcount=4


PS: maybe gdb is an alternative for ltrace. It is already available in scratchbox, and it allows for remote debugging over tcp

PS2: FOX is a *very* nice cross-platform (C++ object oriented) gui toolkit. It supports Linux and windows. See: http://www.fox-toolkit.org/fox.html and https://www.mobileread.com/forums/showthread.php?t=28733

[Antartica]

Hansel,
Sorry to hear that the hours spent stracing didn't bear fuit :-/.
Didn't know the complexity of frysk; you're right that it's better not pursuing that path .
About FOX: I reply in the other thread :-)

Ok then, I go back to xepdmgr (and leave this partial update investigation for a time when new ideas to tackle it appear ;-).