André Moreira adfmoreira@gmail.com 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 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.tfor someone new it might not be nice if the demos are not running.
Gernot Kleiter Uni. Salzburg, Austria
Please apply the following patch ------------------------------------------------------- --- xwininp.c~ 2007-11-01 23:27:52.000000000 +0100 +++ xwininp.c 2007-11-02 00:00:50.000000000 +0100 @@ -566,7 +566,7 @@ return; } while (--count >= 0) { - GrMouseEvent ev; + GrMouseEvent volatile ev; XEvent xev; KeySym keysym; int btn; --------------------------------------------------------
There is a weird bug related to the optimisation in gcc. ev is filled through a macro which calls an asm routine when in 32 bits mode. It is then enqueued by an other macro which calls the same asm routine. Following the process with a debugger at the assembly level, I see that the instructions are reordered by gcc so that the enqueing is made before the filling is complete (the filling is correctly done, but afterwards). Declaring ev volatile is a hack that in principle says to gcc that ev can be modified in a way uncontrolled by gcc, so do not try to reorder the readings/writings on it. For me this solve both your problems on xkeys and demogrx. This is probably not the "right" way to do it, this volatile attribute has been imagined to solve problems when the memory is changed by an external process, not by something which seems to be on the control of gcc. I need to investigate further, and I have no practice of this stuff ...
Anayway try it.
Maurice