André Moreira a écrit:
When I ported it to Linux I started noticing some problems with refresh (solved in grx2.4.8). Mouse events (not working in demogrx) are working in my application. Now about keyboard.....
On 29/10/2007, kleiter <gernot.kleiter@sbg.ac.at mailto:gernot.kleiter@sbg.ac.at> wrote:
I seem to have a related problem with grx248. The demogrx does not respond to the mouse click so that is does not enter any of the demos.t for someone new it might not be nice if the demos are not running. My system: Linux x11, Fedora. Gernot Kleiter Uni. Salzburg, Austria
I have put a better solution in the "more things" directory on the GRX site:
apply the patch http://grx.gnu.de/memory.diff from the root directory of grx248 and revert the previous xwininp.c.diff patch (in fact it is no more useful, but causes no harm)
The problem is that the bug is due to general purpose structure copying macros sttcopy(), memcopy() which are used in many places in grx. With my previous solution we would need to check each call to apply the volatile attribute to its arguments to be sure that the bug will not pop up elsewhere in the future. For 32 bits targets these functions call asm-containing macros like fwdcopy_set gcc does not understand what these asm function do, it knows only pointers to the beginning of the source and destination of the copy, and the number of bytes to copy. By introducing a "memory" clobber in all those asm functions I say not to "optimise" read/writes from/to registers/memory across the asm boundary. This is what it was doing: storing e.g. the key computed before from register to memory (ev) after having copyied (ev) with asm to the grx event queue.
BTW: the bug is not related to the version of GRX (it appears also for GRX 2.4.6 - 2.4.7), but to the version of GCC: without correction it does not appear for gcc 3.4.5, but appears for GCC 4.1.x.
Maurice