DR800 dillo2 & porting non gtk+ based programs

[Iñigo]

Hi,

as we know, DR way to manage screen refresh is handled by some modifications of the gtk+ code. Thus, porting non gtk+ based applications need to refresh screen on their own, similar to what xournal port does due to its use of a special gtk+ widget not covered by the method iRex uses.

So, here am I, trying to port dillo2, a tiny but quite functional web browser.
I've already compiled it successfully (btw, porting fltk2 library has been quite hard), but it's not usable because of the lack of screen refresh and the keyboard issues.

A good way to solve these problems would be to develop an external library we could call from these programs, managing refresh and keyboard, or an external daemon as some hacks on Iliad used.

Sadly, this is beyond my skills... is anyone tempted to help?

I have the same problem with xboard, a frontend for gnuchess.

I've attached a screenshot to show how beautiful dillo browsing could be

[ericshliao]

IMHO, porting xepdmgr to DR800 should be more feasible than adding eink-refresh code to FLTK.
In xepdmgr, "xepdmgr_einkfb.c" contains most eink-refresh control code. Some of them are iLiad-specific. I don't know if the required functions are available for DR800.

[Mackx]

Hi Iñigo,

I only studied this part of the firmware briefly, but it seems that there are already some provisions. See: \Sources\3.0\iRex\libs\erutils\src\display_utils.c . The code is used by the keyboard app: \Sources\3.0\iRex\erkeyb\src\erkeyb-display-sched.c.
The messages send by display_utils.c are handled by sysd (\Sources\3.0\iRex\sysd\src\display.c) there you can see what the effect will be from a message.

[Iñigo]

Originally Posted by Mackx

Hi Iñigo,

I only studied this part of the firmware briefly, but it seems that there are already some provisions. See: \Sources\3.0\iRex\libs\erutils\src\display_utils.c . The code is used by the keyboard app: \Sources\3.0\iRex\erkeyb\src\erkeyb-display-sched.c.
The messages send by display_utils.c are handled by sysd (\Sources\3.0\iRex\sysd\src\display.c) there you can see what the effect will be from a message.

For what I've read in GregorRichards' rxvt port [1] it's as easy as some ioctl here and there.

[1] https://www.mobileread.com/forums/showthread.php?t=81119

Originally Posted by ericshliao

IMHO, porting xepdmgr to DR800 should be more feasible than adding eink-refresh code to FLTK.
In xepdmgr, "xepdmgr_einkfb.c" contains most eink-refresh control code. Some of them are iLiad-specific. I don't know if the required functions are available for DR800.

I was thinking on an external lib with some easy-to-use functions "update_fast()", "update_complete()", etc.

#include <sys/ioctl.h>
#include "delta.h"

int fb0fd=-1;

[...]

struct display_update_info duinfo;
if (fb0fd < 0)
    fb0fd = open("/dev/fb0", O_RDWR);
duinfo.waveform = 1; // 1=full, 6=quick, 9=partial
duinfo.color = 0;
ioctl(fb0fd, FBIO_DELTA_UPDATE_DISPLAY, &duinfo);

[Mackx]

Originally Posted by Iñigo

For what I've read in GregorRichards' rxvt port [1] it's as easy as some ioctl here and there.

[1] https://www.mobileread.com/forums/showthread.php?t=81119

In the past (with R1.7.1 on the DR1000) I found some stability problems with Xournal, related to screen updates. (Maybe it is only the combination of scribbles- and screen- updates.) So I am not sure which method to use the direct ioctl or via the liberutils-display-functions? Maybe an iRex developer can comment on this?

Providing a separate library is a good idea. The proposed interface is sufficient, maybe add a (library-)prefix to the commands to avoid conflict with local names in the application.

[Gertjan]

Originally Posted by Iñigo

I was thinking on an external lib with some easy-to-use functions "update_fast()", "update_complete()", etc.

I suggest giving the code in liberutils (display_utils) a second look. It provides quite similar functionality all within the already available API of the iOn framework. I know it currently lacks documentation but Im happy to answer questions.

[Iñigo]

Originally Posted by Gertjan

I suggest giving the code in liberutils (display_utils) a second look. It provides quite similar functionality all within the already available API of the iOn framework. I know it currently lacks documentation but Im happy to answer questions.

First of all, thanks for your support, Gertjan.

I think you mean the display_update_xxx() functions. They call send_message:

static void send_message(int take_control, int waveform)

where waveform is a DM_HINT_XXX constant: 1=full, 4=partial, ...
but what means take_control? lock and unlock display... but with which purpose?

Thanks, Iñigo

[Gertjan]

/* setup socket for display management (implicitly called by functions below) */
void display_init();

/* close socket for display management */
void display_finialize();

/* take control of display updates, stop automatic GTK+ updates */
void display_gain_control();

/* yield control, resume automatic GTK+ updates */
void display_return_control();

/* force display update and yield control */
void display_update_return_control(gint type);

/* force display update and keep control */
void display_update_keep_control(gint type);

/* block all display updates (both forced and automatic), expect for splash hints */
void display_splash_lock();

/* force display update to show splash screen */
void display_update_keep_splash_lock();

/* unblock display updates, resume forced/automatic updates */
void display_splash_unlock();

Hope that helps a bit.

[Mackx]

Thanks for the extra information!