Quote:
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.