Grx

grx@gnu.de

559 discussions

Re: keyboard failing in grx 2.4.8 under linux X11
by André Moreira 26 Oct '07

26 Oct '07

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(a)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

1 1

keyboard failing in grx 2.4.8 under linux X11
by Andre Moreira 26 Oct '07

26 Oct '07

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... Did anyone find this problem? Any ideas? regards André

1 0

Problems with SVGALib
by Simnav 18 Oct '07

18 Oct '07

I compiled grx library for linux with SVGALib: unfortunately my video board is incompatible with SVGALib. I tried to configure makefile with --target=console --enable-framebuffer --disable-svgalib but when I run any of test applications I get "GrSetMode: could not find suitable video mode". What's wrong ? Thanks in advance. Simone Navari. -- Email.it, the professional e-mail, gratis per te: http://www.email.it/f Sponsor: Cioccolato Venchi: promozione sul cioccolato da ordinare online Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=7107&d=20071018

1 0

Re: GRX 2.4.8
by Maurice Lombardi 27 Sep '07

27 Sep '07

Arlindo da Silva a écrit: > One of the historical features of GRX is the the notion of a > Graphics mode. The current windows driver behaves in a rather > unintuitive manner: one cannot increase the window size beyond the > size specified at startup and when you shrink it, it simply clips the > display; a more intuitive behavior would be to rescale the contents of > the window and repaint it. > > My question for you: do you see any hope of having a Win32 (and X11 > for that matter) driver that allows one to resize the window and have > its contents rescaled and repainted? I have uploaded to the GRX site in the "More things" section a patch http://grx.gnu.de/ReSize.diff which is a step towards this goal, for both the win32 and the x11 targets. It contains two test program to show how to work with it. In this case the rescaling and repainting is made by the main program which uses grx. When you resize the window, the system only changes the maximum size and the clipping size of the Screen context and of the Current context, and enqueues a GRX event GRX_SIZE_CHANGED. The calling program waits in a loop, recognizes the event, and clears and redraws the window with the new scale. the mousetst.c test program is event driven, and uses the GRX_SIZE_CHANGED event himself. the winclip.c test program is in a GrKeyPressed loop, and recognizes the event by looking for the change of GrSizeX or GrSizeY. You probably had in mind something more difficult: automatic repainting by GRX. I have found functions for rescaling bitmaps, but I see two problems for that - rescaling looses information and degrades the drawing. This accumulates with several resizings. - If you want to draw further on a rescaled window, you have to rescale all contexts in use. There is presently no book keeping of the contexts in use by GRX. You can even create a temporary context or subcontext in stack (using the last pointer "where" of GrCreateContext or GrCreateSubcontext), and never destroy it explicitly, so that the adress becomes invalid when exiting from the function where it is declared. The only clean way to overcome both problems is to have a fixed bitmap, write the drawings on it in its original, never modified size, and put to screen a resized version. But I have no idea on how to do that: it is probably a major rewriting. So no promise ... 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

1 0

Re: GRX 2.4.8
by Maurice Lombardi 10 Sep '07

10 Sep '07

Arlindo da Silva a écrit: > I am so glad that GRX is again being maintained. I have been using > GRX on and off for sometime since the old MS-DOS under DJGPP v1. My > current use involves the rework of the old xlibemu from DJGPP which > hooks GRX with the X11R5 (yes, R5) allowing simple X11 clients to run > without an Xserver. (There are other alternatives out there for this, > but none worked as reliably). > > One of the historical features of GRX is the the notion of a > Graphics mode. The current windows driver behaves in a rather > unintuitive manner: one cannot increase the window size beyond the > size specified at startup and when you shrink it, it simply clips the > display; a more intuitive behavior would be to rescale the contents of > the window and repaint it. > > My question for you: do you see any hope of having a Win32 (and X11 > for that matter) driver that allows one to resize the window and have > its contents rescaled and repainted? If you have read the announce on "Sanitized" GRX 2.4.8, you have seen that a step toward this end was made by a patch http://grx.gnu.de/archive/grx/en/mail446.html that I had incorporated in grx 2.4.7, which dealed with WM_SIZE windows events. I discarded this part of the patch in Sanitization because it produced crashes. In fact the situation is better than I was thinking: these crashes are due to a bug in the proposed patch, the usual confusion between number of elements of an array and maximum value of its index. I have thus put in the "more things" section a patch http://grx.gnu.de/ReSize.diff which restores a corrected WM_SIZE treatment, and a test/mousetst program which uses it to to obtain proportional scaling as you request. You can play with it to get an idea. This is however only a small step towards your goal. The central problem is "who repaints ?", the calling program or grx or windows behind the scene. In the current situation, it is the calling program (the simplest to implement). When the running program receives a WM_PAINT event, GRX only changes Sizes in GrScreenContext and GrCurrentContext, and puts a GR_SIZE_CHANGED event in the GRX event queue, nothing more. The calling program (mousetst) watches for this event and clears and redraws the screen using GrSizeX(), GrSizeY() to scale the drawing. A variable GrSizeChangesContext is used to change between old (clipping) and new (scaling) behaviour, defaulting to 0 (clipping), not to break down existing programs which do not expect this new behaviour, and thus do not watch the WM_PAINT events and react accordingly. Automatic scaled repainting by GRX is a more complex problem. Any how, even if this is implemented, all application programs would have to be written keeping in mind that scale can change at any moment, every drawing should be scaled with actual instantaneous GrSizeX(), GrSizeY(), as was made fortunately by the original mousetst program. Finally there is a great technical difference between increasing and decrease the size with respect to the original given by GrSetMode. All graphics information is stored in memory in a bitmap which size is given by GrSetMode. Decreasing the size by clipping (the default automatic windows behaviour) is just putting to screen only a part of this bitmap, an easy task. But all drawings by the program are made on the full bitmap, and thus it needs not care to the actual size seen. Down resizing needs rewriting the part of the bitmap which is seen. Up Resizing would need to use a larger bitmap, with a new GrSetMode probably. This is only very preliminary. I have not even checked carefully if there are not other adverse side effect of the present patch. 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

1 0

"Sanitized" GRX 2.4.8 uploaded
by Maurice Lombardi 31 Aug '07

31 Aug '07

In making grx248, I had problems with the event GR_OS_DRAW_REQUEST which made grx irresponsive to mouse/keyboard events in test programs like mousetst.c, bccbgi.c, demo.pas which make fast continuous drawings. I was astonished not to have noticed previously this serious drawback. In fact it was due to a change for a newer, faster computer/graphics card. These events are generated at each drawing, and were enqueued in the internal grx queue, which serves first to store mouse and keyboard events. This queue is read by the grx program when it calls GrMouseGetEventT() or GrKeyRead() or the like. It can read the stored GR_OS_DRAW_REQUEST with a proper flag, or discard it if this flag is not set, which was the case in the tests programs. With faster drawings, this circular queue was saturating, and the stored keyboard/mouse events are gobbled by the fast arriving GR_OS_DRAW_REQUEST events, before having a chance to be read. One could increase the size of the queue, but to what extent ? I have decided it was best to eliminate this event, given the low probability that somebody uses it. I have looked from where this was coming. It was proposed by a previous maintainer in http://grx.gnu.de/archive/grx/en/mail446.html with the following explanation ------------------------------------------------------------------ I hacked some more event handling into the W32 version of GRX: - GR_SIZE_CHANGED: Tell the program that the size of the GRX window was changed from outside - GR_OS_DRAW_REQUEST: Let the program know that the OS wants the program to redraw its window. (Normally, GRX handles this in the background, but if you use non-GRX output such as OpenGL in parallel, this can be useful.) - GR_COMMAND: Events that come from, e.g., a menu rather than the keyboard or mouse directly Patch attached. -------------------------------------------------------------------- For GR_OS_DRAW_REQUEST the drawbacks are too important to maintain it in a general purpose library. You can start from this patch if you need the functionalities, but you need to think to the problem. For GR_SIZE_CHANGED: without this patch there is already a change size functionaliy in the win32 (not the x11) version of GRX. If you drag the borders od the GRX window with the mouse (or by keying Alt Space, shortcut ..), the size can be reduced (not augmented). In this case, a part of the drawing is no more visible, but the size of the drawings on the visible part is unchanged (try it !). With the patch it is possible to scale the drawings proportionally to the windows size. Try with the grx247 version of mousetst.c where this functions approximately (new drawings are scaled, olds are not erased). But for that to function properly, you need to watch for these events, and correct the drawings accordingly. With test programs in which this was not provided for, you end up nearly always with a crash "writing to an unallowed address". I thus eliminated it also in this "Sanitized" release. The GR_COMMAND has no drawback because the events are generated only if a menu has been programmed. So it is kept. There are some other minor changes, some suggested by Peintler. 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

1 0

[Fwd: Re: to Maurice Lombardi]
by Maurice Lombardi 30 Aug '07

30 Aug '07

-------- Message d'origine -------- Sujet: Re: to Maurice Lombardi Date: Thu, 30 Aug 2007 16:35:20 +0100 De: Maurice Lombardi <Maurice.Lombardi(a)ujf-grenoble.fr> A: Peintler <peintler(a)chem.u-szeged.hu> Références: <46D46DE1.2080208(a)chem.u-szeged.hu> Peintler a écrit: > Thank You for updating GRX library. I have compiled the libgrx20.a > library from v2.4.8 sources now under both DOS v7.1, Win98SE/MinGW32 > and XPSP2/Mingw32 (with gcc v3.4.4). I use the same for my own works, with the last gpc alpha (20060325) and as backend gcc 3.2.3 with W98se/mingw32 and gcc 3.4.5 (candidate) with XPsp2/mingw32 > I have discovered some small bugs > and I suggest some improvements, concerning mainly the Pascal parts (the > important modifications are attached): > 1. I have noticed a small error in GRX.PAS. Line 764 contains the > "No_color" variable name for a GrColor field, but the right name would > be "Lno_color" comparing to line 1175 of GRX20.H file. OK > 2. The compilation of JPGTEST.PAS does not require GPC.PAS, so "GPC, " > can be deleted form line 23 of the source file. OK > 3. The majority of the Pascal programs cannot be compiled without two > changes: (1) the correct unit-paths must be given under Win32 (see line > 52 in the attached makefile.grx) and (2) the dots must be erased in > lines 53-56 of GRX.PAS since the libraries are not explicitly given in > the makefiles. (1) No, for the first compilation of the library (before installation) but this seems to indicate something wrong in your installation. The unit files grx.pas bgi/graph.pas (and test.pas) are found by the compiler because they are in the same directory as the main program which uses them. The library is called by the {$L }instructions in the beginning of the grx.pas and graph.pas files, and found in place before installation with the GRXLIBPATH = in the makefile.W32. After installation, for your own programs which are not in place, if you use the suggested (non standard) c:\mingw\unit directory, you need indeed a compilation option --unit-path=c:/mingw/units. Now, according to your makedefs.grx, you seem to have put instead these unit files in the directory c:\mingw\lib\gcc\mingw32\3.4.5\units where are the standard unit files which come with the gpc compiler (gpc.pas, crt.pas ...). This is possible (I have done it in installing the compiler for some other users in our lab: the only drawback is the need to move these files if you change the gcc backend version for gpc, the one with which gpc was compiled, not the main one with which your main gcc compiler was compiled), but in this case the compiler should find it without any --unit-path compilation option. You can check your installation by typing gpc --print-search-dirs In the libraries section you should find a path leading to the upper directory c:/mingw/lib/gcc/mingw32/3.4.5/, from which gpc computes the path of the standard units directory. (2) right, the instructions to do so are contained in the readme file in the root of the grx directory, and some other places. This is probably not clear enough. In fact I prefer to use the configure script which does simultaneously and consistently changes in makedefs.grx, grx.pas and graph.pas. For this you need to have installed MSYS and work under it. The grx win32 driver has been first made when MSYS did not exist, and mingw was not a self hosting system. Instructions were given to compile on a bare command.com DOS window, with mingw32-make, instead of the msys make. But the configure script is more convenient. Type configure --help to see the options, then configure ... with your options make make install These are the same standard instructions as for any package in unixes. > 4. The \TEST\BGI\FONTPLAY.C file includes the "gettimeofday" function > which does not exist in mingw32 distritbution, only under DOS. This file > cannot be compiled under MinGW32 and the corresponding makefile.w32 did > not include it in GRX version 2.4.6. This is no more true: in recent versions of mingw gettimeofday() is declared in sys/time.h /* Implementation as per: The Open Group Base Specifications, Issue 6 IEEE Std 1003.1, 2004 Edition The timezone pointer arg is ignored. Errors are ignored. */ int __cdecl __MINGW_NOTHROW gettimeofday(struct timeval *__restrict__, void *__restrict__ /* tzp (unused) */); > 5. Finally, the most strange experience: AR.EXE does not work under > MinGW32 with the original CROSS_PLATFORM="" setting if the command to be > executed contains more than ~500 characters! Removing "" makes > everything to be perfect. Right: in fact we always use the configure script which deletes these "". Nevertheless I have corrected it in the last, just uploaded, version. 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

1 0

to Maurice Lombardi
by Peintler 28 Aug '07

28 Aug '07

Dear Sir, Thank You for updating GRX library. I have compiled the libgrx20.a library from v2.4.8 sources now under both DOS v7.1, Win98SE/MinGW32 and XPSP2/Mingw32 (with gcc v3.4.4). I have discovered some small bugs and I suggest some improvements, concerning mainly the Pascal parts (the important modifications are attached): 1. I have noticed a small error in GRX.PAS. Line 764 contains the "No_color" variable name for a GrColor field, but the right name would be "Lno_color" comparing to line 1175 of GRX20.H file. 2. The compilation of JPGTEST.PAS does not require GPC.PAS, so "GPC, " can be deleted form line 23 of the source file. 3. The majority of the Pascal programs cannot be compiled without two changes: (1) the correct unit-paths must be given under Win32 (see line 52 in the attached makefile.grx) and (2) the dots must be erased in lines 53-56 of GRX.PAS since the libraries are not explicitly given in the makefiles. 4. The \TEST\BGI\FONTPLAY.C file includes the "gettimeofday" function which does not exist in mingw32 distritbution, only under DOS. This file cannot be compiled under MinGW32 and the corresponding makefile.w32 did not include it in GRX version 2.4.6. 5. Finally, the most strange experience: AR.EXE does not work under MinGW32 with the original CROSS_PLATFORM="" setting if the command to be executed contains more than ~500 characters! Removing "" makes everything to be perfect. I hope this helps Your work. Sincerely, Gabor Peintler

1 0

GRX 2.4.8 is released
by Maurice Lombardi 24 Aug '07

24 Aug '07

This is a bug fix release. - for the X11 driver: backport of Mariano's MGRX improvement: this driver now responds to Expose events (i.e. repaints parts of the GRX window brought to front) - for the win32 driver, correction of several annoying bugs . no more enqueue WM_PAINT events to give GR_OS_DRAW_REQUEST this is of no use and it had a great drawback: it saturated the grx's event queue, gobbling mouse and keyboard events. Compare responsivity to mouse and keyboard hits of tests which produce fast frequent drawings like test/mousetst.c test/bgi/bccbgi.c and pascal/bgi/demo.pas . some bitmap characters drawn were missing in various test programs. This was due to a Window's bug: the GetUpdateRect() function gives wrong UpdateRect. The BeginPaint() function gives a correct UpdateRect. This is contrary to Microsoft specs. Do'nt ask me why ! . Some Sleep() are needed to yield control to system to draw. Compare behaviour of PlayRGBpalette() in test/bgi/bccbgi.c (for this driver which has not a true palette working) - for the djgpp driver: Now the syntax /dev/env/DJDIR works as expected for loading fonts: GRX_DEFAULT_FONT_PATH or direct loading by GrLoadFont() with an absolute path. Beware that many tests work because they give relative pathes towards the grx248/fonts directory. This is so to enable to run tests before installing the fonts. - some random improvements See the changes file Enjoy, 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

1 0

GRX and OSX
by richard 13 Aug '07

13 Aug '07

do you know of a way to get GRX working or a graphical mode working under OSX? I am baffled as to how to begin.DOS is easier, but am working on a multi-arch/multi-platform program here. I'm looking for same routines as GRX or the old graph,and crt units provide.So far CRT unit doesn't redraw screen right.There is no GRX unit, only turtle graphix.

2 1

← Newer
1
...
5
6
7
8
9
10
11
...
56
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

1994

Grx