Xournal note taking app ported

[Gertjan]

DR1000 (and Iliad for that matter) set the display controller in a special 'draw mode' when scribbling. In this mode it redraws only small portions of the screen (basically only the "dot" when the stylus point hits the surface). You could take a look into liberscribble and the scribble test app it includes which seems to handle this.

[chrisf]

That's a real shame, but there must be an answer?

Perhaps you might post this thread on the Irex Forum as well? I'm sure it is in Irex's interest to get third-party apps like this working, so they might be able to help?

Chris

http://forum.irexnet.com/viewforum.php?f=41

[Cliffe]

Great program. Has any progress been made on the refresh issues?

I added this program to the DR software wiki:
https://wiki.mobileread.com/wiki/Digital_Reader_Software

[Mackx]

I have made two small improvements to the xournal port:
1) An icon is now shown in the Task Manager of the DR menu allowing you to switch to another application/document and back again.
2) refresh after each stoke (so when you lift your pen). (Well ... 2 seconds after lifting the pen.)

I made an updated version of the xournal_0.4.2.1_arm.ipk -file. So follow the original instructions from UtterInanity but replace the xournal-ipk-file. (Yes I managed to make proper .ipk-files...:-)

I also had to disable printing (to pdf), like in the original port, since it requires some extra libraries that need to be ported to DR1000, for which I do not have the experience (yet, nor the time...).

I hope this will be a step to an even better port that has a real refresh when writting.

PS: for other 'porters'
The trick to do 1) I explained here. 2) Is done by a trick I also used in mxSudoku, when you refresh a label (gtk_label_set_text()), so I update ' Layer: ' every time in the finilize_stoke()-function. This seems to trigger an internal refresh after some limited time (<2 seconds)

[Grimulkan]

Great work, thanks

Originally Posted by Mackx

This seems to trigger an internal refresh after some limited time (<2 seconds)

I am still looking for some way to tell the DR to "refresh NOW". For some reason, the GTK functions wait for 2 seconds to queue up screen updates before actually doing it. I am still trying to get the native refresh functions to update instantly, in which case one could directly talk to X for drawing simple lines, shapes etc. (or render to a buffer and use non-GTK calls to display) and update manually. Any thoughts? Perhaps the native "area refresh" functions (I forgot what they're called, update_screen or something, accepts rect coords) do it instantly. If they did, I suppose one could refresh individual points on the screen as the user scribbles, but I suspect the native functions also queue up refresh requests

This sort of stuff is critical whenever there is user interaction, and I think the slight delay is not just because its e-ink, but because GTK doesn't update instantly. So scribbling, pushing buttons rapidly etc. all have a small delay. I understand that iRex couldn't have all button push events trigger an instant refresh or something like that, but I'd sure like some developer control.

[Mackx]

I agree with you, as I already wrote, this is a step towards an app that refreshes instantly. I will also add this one also to my (ever growing) todo-list ...

[Mackx]

I made a mistake in my patch, that caused xournal not to find its local pixmaps (the 2nd line of icons). I fixed that and also managed to create a ipk-file that can be used in the original installation procedure of UtterInanity.
See the first mail in this thread for the installation instructions and my previous post for the updated xournal version.

Sorry if I caused problems for someone.

(I used the wrong value for the configure --prefix parameter, for those of you that want to know the cause of my mistake.)

[Grimulkan]

I'm sure the community would greatly appreciate the source, preferably the entire Anjuta project folder (and the -- prefix option you finally used for configure)

[Mackx]

It took me about three weeks to get it compiling... but I have made some notes, let me see if I can reproduce what I did and share it with the community.

[Grimulkan]

Originally Posted by Grimulkan

I am still looking for some way to tell the DR to "refresh NOW". For some reason, the GTK functions wait for 2 seconds to queue up screen updates before actually doing it. I am still trying to get the native refresh functions to update instantly, in which case one could directly talk to X for drawing simple lines, shapes etc. (or render to a buffer and use non-GTK calls to display) and update manually.

After some more research, it appears that GTK+ does practically nothing other than asking System Daemon (sysd) to update the display. Sysd makes all the decisions such as how long to queue requests (delay time), which waveform to use etc. So bypassing GTK refresh hooks by calling irex_display_update() with the coordinates is not going to fix the problem, as this only triggers the update in sysd. The solution to the Xournal update problem would then be:
1. Bypass GTK+ refresh calls (or add a non-GTK call) by talking directly to sysd, and fooling sysd into using one of its special refresh modes. There are modes for text entry and scribbles which update very fast, you could trace backwards from display.c and delta.h in sysd to see which signals trigger these, and simulate them in your code. If there is a way to trigger these through some GTK call (such as whatever the text entry widget update does), then that will also work. I suspect it might be as simple as doing what irex_display_update() does (see gtkwindow.c in iRex's modified GTK+, for example), while passing in a text entry or some such widget name as the "widget type". Reverse engineer display.c in sysd to figure it out.
2. Otherwise, one could bypass sysd altogether by directly talking to the delta controller (ioctl() call). Anyone doing this will need to use the correct control/waveform codes as used in display.c in sysd. I am not sure if there is a danger of angering sysd (or the delta controller) by doing this, but I think the worst that could happen is multiple refreshes.

The first option is probably easier (and safer?), but the second is incredibly powerful. This allows developers to control exactly how the refresh is done, refresh colors, delay between refresh call and actual refresh, refresh waveforms etc. This is of use in drawing or other apps with non-standard update requirements, like Xournal.

There are also other possibilities with this option: it looks like new refresh waveforms can be loaded from files on disk, and a certain "vcom" voltage can also be varied. I don't have the courage to play with these last 2 options however, and I am not even certain if iRex has implemented them.

[Mackx]

Originally Posted by Grimulkan

2. Otherwise, one could bypass sysd altogether by directly talking to the delta controller (ioctl() call). Anyone doing this will need to use the correct control/waveform codes as used in display.c in sysd. I am not sure if there is a danger of angering sysd (or the delta controller) by doing this, but I think the worst that could happen is multiple refreshes.

I am experimenting with this option 2, I looked at the test directory of erscribble (Sources\1.5\iRex\libs\erscribble\test). Apart from updating the drawing via gtk it also uses the delta controller. So I am calling these erscribble_driver-calls from my mxSudoku program and you see the feedback almost immediately. The drawing is a little light grey.
HOWEVER: The DR hangs completely after some time (it is not reacting to keys or stylus) and a reset is needed to get the device working again. I got it working only for less then an hour so I am not sure what triggers the hang-up of the device. I will integrate the code with xournal and post it here so more people can experiment with it.

[Mackx]

Originally Posted by Grimulkan

I'm sure the community would greatly appreciate the source, preferably the entire Anjuta project folder (and the -- prefix option you finally used for configure)

I have found some time to document the steps I took to make my patches to the original port. I hope this is also OK for you, there are no major changes to the original program and this way I hope to inspire more people to also look into porting programs for the DR.
The 'how-to' consists of 4 part.
PART 1: getting it to run
PART 2: Improving Refreshes
PART 3: Adding icon to Task Manager
PART 4: Getting it on the DR
Please give me your comments, specially if things are missing or wrong. Also other updates are welcome.
Maybe I will also add a PART 5 describing my experiments with erscribble to get 'instant' screen updates.

[Gertjan]

Nice work. Part 3 should be easy. When you send the "startupComplete" IPC with the proper arguments (pid and window id) to system daemon, it will show the xjournal task in the Task Manager. Note that you must call it after the window has been realized and shown.

[Mackx]

Originally Posted by Gertjan

Nice work. Part 3 should be easy. When you send the "startupComplete" IPC with the proper arguments (pid and window id) to system daemon, it will show the xjournal task in the Task Manager. Note that you must call it after the window has been realized and shown.

I now added Part 3 in the original post, you have been too impatient ...

[Grimulkan]

Originally Posted by Mackx

[...] HOWEVER: The DR hangs completely after some time (it is not reacting to keys or stylus) and a reset is needed to get the device working again. I got it working only for less then an hour so I am not sure what triggers the hang-up of the device. I will integrate the code with xournal and post it here so more people can experiment with it.

I am also not sure why this could happen, is it repeatable? Anyway, the scribble packages still do not directly call the delta controller to refresh the screen, but call the delta controller to directly "draw" on the screen (which includes the refresh). You actually don't need to do that because GTK already takes care of storing what pixels are to be displayed etc. You only need to call a refresh whenever the user draws stuff. Maybe you could try using ioctl() directly with the FBIO_DELTA_UPDATE_DISPLAY command (and appropriate parameters), instead of the FBIO_DELTA_DRAWMODE_PIXELS that the scribble driver uses. Don't know if it will fix the hang issue, but its worth a shot.