Hi.
I have uploaded a second pre-release of GRX 2.4.4. Download it from:
http://grx.gnu.de/download/grx244p2.zip
MD5SUM for the package:
48de67cdf90d24be30e4ae4f013e1a61 *grx244p2.zip
Only the zip archive is provided, but note, the zip archive expand to grx244, not to the contrib directory.
Changes from 2.4.3 p1:
01/11/29 better w32 keyboard handling. Now most special keys with shift, alt and control combinations work 01/11/29 added jpeg functions to grx.pas and jpgtest.pas demo, by Maurice Lombardi 01/11/29 patch to define gpc-main in grx.pas and graph.pas, by Frank Heckenbach 01/11/29 patch to remove warnings on unix in test/bgi programs, by Frank Heckenbach 01/11/16 Added new function: GrSaveContextToGrayJpeg. Now GrLoadContextFromJpeg can load grayscale jpeg files
Testing and comments will be welcome.
--------
Note for Frank Heckenbach:
Frank, I have modified makefiles for linux/x11 to create the instalation subdirs and to install the info manual as suggested. But there are two problems: 1) a normal user can't run install-info 2) running it with root makes a "dir" file in the installation subdirectory, but "info grx" don't work, except if you are in this subdirectory.
Mariano Alvarez Fernandez schrieb:
Hi.
I have uploaded a second pre-release of GRX 2.4.4. Download it from:http://grx.gnu.de/download/grx244p2.zip
MD5SUM for the package:48de67cdf90d24be30e4ae4f013e1a61 *grx244p2.zip
Only the zip archive is provided, but note, the zip archive expand to grx244, not to the contrib directory.
Changes from 2.4.3 p1:
01/11/29 better w32 keyboard handling. Now most special keys with shift, alt and control combinations work
Q1: is therw any way to determine the keyboard status i.e.: (lshift, rshift, numlock... -- like s=bioskey(2) -- ? without having a pending event in W32
Q2: is there a way to set active focus to console/graphics window by a -mwinows -mconsole compiled program (like clicking on them) ?
01/11/29 added jpeg functions to grx.pas and jpgtest.pas demo, by Maurice Lombardi 01/11/29 patch to define gpc-main in grx.pas and graph.pas, by Frank Heckenbach 01/11/29 patch to remove warnings on unix in test/bgi programs, by Frank Heckenbach 01/11/16 Added new function: GrSaveContextToGrayJpeg. Now GrLoadContextFromJpeg can load grayscale jpeg files
Testing and comments will be welcome.
Note for Frank Heckenbach:
Frank, I have modified makefiles for linux/x11 to create the instalation subdirs and to install the info manual as suggested. But there are two problems: 1) a normal user can't run install-info 2) running it with root makes a "dir" file in the installation subdirectory, but "info grx" don't work, except if you are in this subdirectory.
Thanks to everybody contributing to this grat package.
Hi Waldemar
Q1: is therw any way to determine the keyboard status i.e.: (lshift, rshift, numlock... -- like s=bioskey(2) -- ? without having a pending event in W32
I don't know, GRX uses GetKeyState, but it really get the asociated state to the last key event. Perhaps you can explore GetAsyncKeyState.
Q2: is there a way to set active focus to console/graphics window by a -mwinows -mconsole compiled program (like clicking on them) ?
Not easy. GRX, by now, doesn't have input drivers, so the Win32 input code handles only the windows events.
Mariano Alvarez Fernandez wrote:
Frank, I have modified makefiles for linux/x11 to create the instalation subdirs and to install the info manual as suggested. But there are two problems: 1) a normal user can't run install-info
He can run it -- but only in a directory where he has write access. So if he installs in his home directory or builds a binary package, it will work just fine. And he can't install the other files in the system directories, anyway, so that's no additional restriction.
- running it with
root makes a "dir" file in the installation subdirectory, but "info grx" don't work, except if you are in this subdirectory.
Indeed. install-info can only work correctly if installing in the global directories directly. If installing in a temp directory or below home, it will leave a dir file there which contains only the GRX entry. I've seen this with other packages, and it can be a problem -- if a careless user installs such a binary package, he might overwrite his existing dir file. So it might be better to run install-info only if the dir file exists already.
Another question seems to be about /etc/info-dir. I don't know which systems use it (mine doesn't, and I've seen no support for it in other packages I've checked, only in GRX). Anyway, if there are systems that have it, we can do the same with it, i.e. update it only if it exists and we have write permissions (which probably means we are root, though another privileged user should also work). A `-w' test will check both existence and writability, so I hope this will be ok for all of our different needs now. (diff18)
As I said in an earlier mail, I think it should be possible via makedefs settings to disable shared libs. I've added this now (INCLUDE_SHARED_SUPPORT, default y). (diff14)
All other issues I've mentioned in previous mails are solved now. :-)
Some other things:
For the Pascal interface: I think it would be better if GrAllocEgaColors, GrGetScanline, etc. return a pointer to an array of GrColor, rather than to a single GrColor (in C it's the same, so it's only a question of grx.pas). (diff15)
I wrote a little Pascal program to demonstrate to someone how to load PNGs. I've now added JPEG support as well, and would like to contribute the program (imgviewer) to GRX as a demo. Another program (colortest) has proved useful to me to examine the behaviour on various kinds on xterms with different color depths etc. (both in diff16)
Is it important to you to run `ar' in verbose mode? I prefer to run `make -s' to see nothing but real error and warning messages, and the `ar' output is disturbing it, so I'd prefer to change this (i.e., invoke it with `-r' instead if `-rv'). (diff17)
Frank
Thanks Frank, I have applied diff14 to diff18 with only a change, I have renamed
imgviewer.pas to imgview.pas colortest.pas to colortst.pas
to maintain 8.3 DOS file name compatibility in GRX
Mariano Alvarez Fernandez wrote:
Thanks Frank, I have applied diff14 to diff18 with only a change, I have renamed
imgviewer.pas to imgview.pas colortest.pas to colortst.pas
to maintain 8.3 DOS file name compatibility in GRX
OK, no problem.
Frank
On Sat, 8 Dec 2001, Mariano Alvarez Fernandez wrote:
Hi.
I have uploaded a second pre-release of GRX 2.4.4. Download it from:
What is Your plans with linuxfb driver. It's very likely I'll need that to provide real time display of some measurement data (it would be best not to use X11 or svgalib in this case). It seems to be mostly working except of "amnesia" after switching virtual consoles
Perhaps I could try to port virtual console switching code from Allegro-4.0.0 (allegro-4.0.0/src/linux/vtswitch.c), but not immediatelly now, now perhaps not earlier than in begin of next year. This is perhaps most annoying thing for me now.
Absence of 8bpp mode there is currently not critical for me.
Another thing is similar "amnesia" for X11 driver (verified now with 2.4.4p2): if I obscure GRX window, the contents is lost. I would write related code, I would prefer to use gtk+ and gdk, build image in pixmap and blit it to screen as needed (tried to wrote some related custom widgets recently). Maybe it's worth to have such GTK+ driver (maybe it could be useable also for Windows, as there is Windows port of gtk+)
Andris
Hi, Andris
What is Your plans with linuxfb driver. It's very likely I'll need that to provide real time display of some measurement data (it would be best not to use X11 or svgalib in this case). It seems to be mostly working except of "amnesia" after switching virtual consoles
Well, I was very excited with the framebuffer driver, the video driver was very easy to write, the stock GRX framedrivers do all the hard work. Thanks for test it, it's the first "feed-back" I have about it.
Current problems I know, from www.gnu.de/software/GRX/problems.html:
- Try to change modes if the underlaying framebuffer driver allow it.
- Hide the text cursor.
- Working mouse (this is not trivial), GRX linux console mouse is handled by svgalib functions, but obviously this not work with the framebuffer driver, a new mouse driver is necesary, but Linux don't have a real mouse driver, and the user program must handle all the possible mouse types.
Now I have two more things:
- It doesn't work in my recently installed Mandrake 8.1, the device driver has changed from /dev/fb to /dev/fb0, but a simple change to the file to open doesn't work, I have to investigate it.
- Optionally make a framebuffer only GRX library.
Perhaps I could try to port virtual console switching code from Allegro-4.0.0 (allegro-4.0.0/src/linux/vtswitch.c), but not immediatelly now, now perhaps not earlier than in begin of next year. This is perhaps most annoying thing for me now.
This will be great! (but, can we apply the GRX license to the ported code?)
Absence of 8bpp mode there is currently not critical for me.
I think this is not difficult, but with my graphics card I can't switch the fb color resolution except at boot I time, so I didn't work on it.
Another thing is similar "amnesia" for X11 driver (verified now with 2.4.4p2): if I obscure GRX window, the contents is lost. I would write related code
I have a workarround for this, from www.gnu.de/software/GRX/problems.html again:
- The driver can't respond to PAINT events, so it has problems with XFree86 v4 because the backing-store is not enabled by default. The best solution is to have a context to save the actual window (and the GrPixel problem can be solved too). The workaround is to add next lines to the /etc/X11/XF86Config-4 file, in the Device section:
Option "BackingStore"
Option "SaveUnders"
, I would prefer to use gtk+ and gdk, build image in pixmap and blit it to screen as needed (tried to wrote some related custom widgets recently). Maybe it's worth to have such GTK+ driver (maybe it could be useable also for Windows, as there is Windows port of gtk+)
I don't know how to use GTK, are you speaking a GRX driver over GTK is possible?
M.Alvarez
Mariano Alvarez Fernandez wrote:
- Working mouse (this is not trivial), GRX linux console mouse is handled by
svgalib functions, but obviously this not work with the framebuffer driver, a new mouse driver is necesary, but Linux don't have a real mouse driver, and the user program must handle all the possible mouse types.
You might want to borrow the code from GPM ...
Frank
On Wed, 19 Dec 2001, Mariano Alvarez Fernandez wrote:
Hi, Andris
What is Your plans with linuxfb driver. It's very likely I'll need that to provide real time display of some measurement data (it would be best not to use X11 or svgalib in this case). It seems to be mostly working except of "amnesia" after switching virtual consoles
Well, I was very excited with the framebuffer driver, the video driver was very easy to write, the stock GRX framedrivers do all the hard work. Thanks for test it, it's the first "feed-back" I have about it.
Current problems I know, from www.gnu.de/software/GRX/problems.html:
- Try to change modes if the underlaying framebuffer driver allow it.
I used VESA framebuffer support, so it's set at boot time. I don't know whether I can change a resolution after that.
- Hide the text cursor.
Haven't looked into that. At least I don't see text cursor in allegro-4.0.0 demo program running with framebuffer driver.
- Working mouse (this is not trivial), GRX linux console mouse is handled by
svgalib functions, but obviously this not work with the framebuffer driver, a new mouse driver is necesary, but Linux don't have a real mouse driver, and the user program must handle all the possible mouse types.
Maybe one can use GPM directly, however I don't know whether it can be done for framebuffer mode (whether resulution is good enough)
Now I have two more things:
- It doesn't work in my recently installed Mandrake 8.1, the device driver has
changed from /dev/fb to /dev/fb0, but a simple change to the file to open doesn't work, I have to investigate it.
Same for Slackware-8.0: I added /dev/fb as symlink to /dev/fb0 before even trying (looked in source of driver and noticed that immediatelly)
- Optionally make a framebuffer only GRX library.
Maybe drivers could be loaded at run time. At least it could be possible for Linux.
Perhaps I could try to port virtual console switching code from Allegro-4.0.0 (allegro-4.0.0/src/linux/vtswitch.c), but not immediatelly now, now perhaps not earlier than in begin of next year. This is perhaps most annoying thing for me now.
This will be great! (but, can we apply the GRX license to the ported code?)
Perhaps I should put console switching code (if I'll write it) at first in my program and only after that to move it to try to put it into a driver. So I could tell program to redraw all when coming back.
Absence of 8bpp mode there is currently not critical for me.
I think this is not difficult, but with my graphics card I can't switch the fb color resolution except at boot I time, so I didn't work on it.
The same for me. Tried to do the same under Allegro, and my program have a different problems and works in 8bpp mode only. But these are results of rather few hours hacking, so it's much too early for real conclusions.
Another thing is similar "amnesia" for X11 driver (verified now with 2.4.4p2): if I obscure GRX window, the contents is lost. I would write related code
I have a workarround for this, from www.gnu.de/software/GRX/problems.html again:
- The driver can't respond to PAINT events, so it has problems with XFree86 v4
because the backing-store is not enabled by default. The best solution is to have a context to save the actual window (and the GrPixel problem can be solved too). The workaround is to add next lines to the /etc/X11/XF86Config-4 file, in the Device section:
Option "BackingStore" Option "SaveUnders"
Thanks. Only how it would influence performance of X server. Currently I installed XFree86-4.1.99.2, at lesat 4.1 and earlier 4.X versions have problems for me one box I'm using most often, development versions seems to work better (if they are not temporary broken)
, I would prefer to use gtk+ and gdk, build image in pixmap and blit it to screen as needed (tried to wrote some related custom widgets recently). Maybe it's worth to have such GTK+ driver (maybe it could be useable also for Windows, as there is Windows port of gtk+)
I don't know how to use GTK, are you speaking a GRX driver over GTK is possible?
I also don't know. How about having GTK widget we can draw with GRX or BGI functions with. Perhaps we should need something similar as I wrote for initialization of printing code to use GrContext but not to go throu´h full GrSetMode (as far as I remeber, it was long time ago) as one may want to draw on more than one widget.
Andris
-
Andris Pavenis -
Frank Heckenbach -
Mariano Alvarez Fernandez -
Waldemar Schultz