Hi,
As far as I can tell, the installation went without glitches. This software I am working on as a couple of years and it started with 2.4.4. or 2.4.5. 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.....
I suppose it's not a grx bug (hopefully). I am thinking that it might be hardware related as I am working on a sony vaio vgn-c2s. But I have to find a desktop to build grx and test this.
For me it is out of the question to revert to a previous grx version because of the refresh issues, so I am quite stuck without the keyboard. I will try to work around it and I'll keep this forum informed of any breakthroughs.
André
On 29/10/2007, kleiter gernot.kleiter@sbg.ac.at wrote:
Hi,
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. I was supposing that I did not properly set the switches in the grxdefs file. But I have not time to check that out carefully. Everything is fine, though, with my old grx246. In my applications, though, also those routines that I need are o.k. in grx248. Thus, I don't care. But for someone new it might not be nice if the demos are not running. I was supposing that I did not properly set the switches in the grxdefs file. But I have not time to check that out carefully.
My system: Linux x11, Fedora.
Gernot Kleiter Uni. Salzburg, Austria
André Moreira wrote:
well, attached you can find a print screen of xkeys...
On 26/10/2007, André Moreira adfmoreira@gmail.com wrote:
My problem isn't that the keys are wrong. My problem isn't something
like
typing an "a" and grx returning an "m".
My problem is that the keyboard event isn't doing anything. In he
example
mousetest, the keyboard value is... trash.
I have no idea if it's hardware or some configuration....
What linux do you use? I am using OpenSuse 10.2 in KDE
André
On 26/10/2007, Maurice Lombardi Maurice.Lombardi@ujf-grenoble.fr
wrote:
Andre Moreira a écrit:
Hello all,
I am porting an application written with GRX developd in win32 to
Linux
X11 and I have just installed GRX 2.4.8.
This solved a problem I had with refresh, but keyboard events just stopped working (in version 2.4.7. keyboard was working fine in X11).
I thought that the problem was with my application, but after checking the grx examples, I found out that the grx examples xmousetest and
xkeys
aren't recognizing what keys are being presses. The keyboard event is recognized, but the key itslef is garbage...
Strange. for me xkeys works fine, including special keys with a french keyboard. Have you used grx 2.4.7 on the same computer ? Are you sure to have configured properley your keyboard (in /etc/X11/xorg.conf) to do with system-config-keyboard At the begin mine was configured as an english default keyboard.
Maurice
-- Maurice Lombardi Laboratoire de Spectrometrie Physique, Universite Joseph Fourier de Grenoble, BP87 38402 Saint Martin d'Heres Cedex FRANCE Tel: 33 (0)4 76 51 47 51 Fax: 33 (0)4 76 63 54 95 mailto:Maurice.Lombardi@ujf-grenoble.fr
-- André Moreira Research Engineer Inteligent Robotics & Non-Linear Dynamics Laboratory Universidade do Minho - Portugal
André Moreira adfmoreira@gmail.com a écrit :
On 29/10/2007, kleiter gernot.kleiter@sbg.ac.at wrote:
Hi,
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
Got it. The problems are with the 32 bits x11 targets. I had checked thoroughly only the 64 bits targets, because they were new, while the 32 bits were _seemingly_ unchanged. With 64 bits all is OK but with 32 bits targets I find that demogrx does not respond properly to mouse click, because the xy values returned by the mouse are bogus, and also that xkeys returns a constant bogus value. I will examine what is wrong, but this will be difficult before next week, because I am not in my lab this week.
Maurice
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
Just wanted to thank you all for this patch and the time spent on solving this bug :) You really took a problem of my hand.
best regards André
On 03/11/2007, Maurice Lombardi lombardi@ujf-grenoble.fr wrote:
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
-- Maurice Lombardi Laboratoire de Spectrometrie Physique, Universite Joseph Fourier de Grenoble, BP87 38402 Saint Martin d'Heres Cedex FRANCE Tel: 33 (0)4 76 51 47 51 Fax: 33 (0)4 76 63 54 95 mailto:Maurice.Lombardi@ujf-grenoble.fr
Maurice Lombardi wrote:
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 ...
I have little time ATM, so sorry for the late reply. At first glance, the "right" way to do it should be to declare the "asm" statement "volatile", but this seems already the case for all "asm" statements in GRX. Which asm routine is it here actually?
Frank
Frank Heckenbach a écrit:
Maurice Lombardi wrote:
I have little time ATM, so sorry for the late reply. At first glance, the "right" way to do it should be to declare the "asm" statement "volatile", but this seems already the case for all "asm" statements in GRX. Which asm routine is it here actually?
I think I have answered in an other mail, with a better solution. Thanks anyway.
Maurice
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
-
André Moreira -
Frank Heckenbach -
Maurice Lombardi -
Maurice Lombardi