Grx March 2003

grx@gnu.de

5 participants
7 discussions

GRX 2.4.6 pre-release 2
by Mariano Alvarez Fernandez 14 Mar '03

14 Mar '03

Hi, I have uploaded a new pre-release of GRX 2.4.6, mostly due for GPC people, because they need it to be compatible with the new GPC version (if I have understood it). The pre-release doesn't include yet the latest changes from Dimitar and Thomas. http://grx.gnu.de/more.html Greetings, M.Alvarez

2 1

Re: The rest of DGA2 driver
by Dimitar Zhekov 13 Mar '03

13 Mar '03

DZ>> Warning: any attempt to read from stdin while in "graphics" mode DZ>> blocks the application. This is a bad practice IMHO ... DZ>> there are any objections, replace such reads with GrKeyRead()-s. FH> I have some programs that do terminal (via ncurses) and GRX I/O at FH> the same time (under X11, in two windows -- xterm and GRX). I don't FH> see a bad practice in this. Normally, GRX runs in fullscreen mode and there is no 2nd window where to perform terminal I/O, so it can't be guaranteed that the terminal I/O will work while in graphics mode, or that the GRX I/O will work while in text mode. Moreover, the terminal I/O may try to echo the characters entered on the graphics screen (if fullscreen), or even try to scroll it, thus corrupting the graphics image. FH> Would this break with those changes? Only if you (1) set USE_XF86DGA_DRIVER=y in makedefs.grx, (2) activate XFree86 DGA2 (it's off by default) and (3) run your programs as root. -- E-gards: Jimmy

3 3

Re: The rest of DGA2 driver
by Demmer, Thomas 13 Mar '03

13 Mar '03

It is possible under W32 to use the console if you do not use the "-mwindows" compiler switch. Ciao Tom > -----Original Message----- > From: Frank Heckenbach [SMTP:frank@g-n-u.de] > Sent: Mittwoch, 12. März 2003 17:53 > To: jimmy(a)is-vn.bg; grx(a)gnu.de > Subject: Re: The rest of DGA2 driver > > Dimitar Zhekov wrote: > > > DZ>> Warning: any attempt to read from stdin while in "graphics" mode > > DZ>> blocks the application. This is a bad practice IMHO ... > > DZ>> there are any objections, replace such reads with GrKeyRead()-s. > > > > FH> I have some programs that do terminal (via ncurses) and GRX I/O at > > FH> the same time (under X11, in two windows -- xterm and GRX). I don't > > FH> see a bad practice in this. > > > > Normally, GRX runs in fullscreen mode and there is no 2nd window where > > to perform terminal I/O, so it can't be guaranteed that the terminal > > I/O will work while in graphics mode, or that the GRX I/O will work > > while in text mode. > > You mean in the non-X11 versions? (In X11, the window is as big as I > make it, say 800x600, with space for more windows.) It might be > possible under Linux (FreeBSD?) to use two virtual consoles this way > (i.e., run the GRX program on one console and redirect its standard > I/O to another one or set it up via newterm() in curses). I've never > tried this and don't really plan to, though ... > > I don't use MS-Windows, so I don't know if it's possible to launch a > GRX program from the command line window and let it open a graphics > windows and still do text I/O. I think it would be nice if it is > possible ... > > > Moreover, the terminal I/O may try to echo the > > characters entered on the graphics screen (if fullscreen), or even try > > to scroll it, thus corrupting the graphics image. > > Of course, doing text and graphic I/O on the same screen (not in > different windows) is not a good idea, I know. > > > FH> Would this break with those changes? > > > > Only if you (1) set USE_XF86DGA_DRIVER=y in makedefs.grx, (2) activate > > XFree86 DGA2 (it's off by default) and (3) run your programs as root. > > Should be no problem then, since these programs are not meant to be > run as root. > > Frank > > -- > Frank Heckenbach, frank(a)g-n-u.de > http://fjf.gnu.de/ > GnuPG and PGP keys: http://fjf.gnu.de/plan (7977168E)

1 0

The rest of DGA2 driver
by Dimitar Zhekov 11 Mar '03

11 Mar '03

This patch contains the rest of the XFree86 DGA2 driver and some small changes in xwininp.c the handle fullscreen mode. 8bpp modes now work. The input also works, even if switching from "graphics" to "text" mode and vice versa, or executing one GRX application from another. In the last case, caller must switch to "text" mode before exec (it's a normal practice, demogrx does it). Warning: any attempt to read from stdin while in "graphics" mode blocks the application. This is a bad practice IMHO, so I will, unless there are any objections, replace such reads with GrKeyRead()-s. -- E-gards: Jimmy

2 1

src/makefile.lnx svgalib debug fix
by Dimitar Zhekov 11 Mar '03

11 Mar '03

- Use ADDON_LIBS instead of PLIBS, as in the other Makefile-s - ADDON_LIBS aka PLIBS are required to link any GRX program in debug mode even if it doesn't call GrSetMode() etc., because utils/dbgprint.c:_GR_debug_printf() calls GrKeyPressed() and GrKeyRead(), which in turn require the input libraries, which directly or indirectly (through their video driver) refer to ADDON_LIBS / PLIBS. Personally I'd like to see these GrKey*() calls removed and have the debug feature independent of the input and video drivers, but other people may need them... -- E-gards: Jimmy

1 0

DGA2 driver (incomplete)
by Dimitar Zhekov 04 Mar '03

04 Mar '03

This is an incomplete GRX driver for DGA2. 8bpp modes don't work, and so the doesn't GRX input. Do not use stdin while in graphics mode (that limitation will probably stay); if you want to test the driver, replace all input in your application with sleep()-s. Keep in mind that DGA is unstable and may completely lockup your machine or fail to restore the original resolution. I spent a lot of time attemting to workaround the lockup bug, but that seems to be impossible. So if your system locks up, try the VESA driver... x11-fdv-own-disp.diff is required for the fonts to work. x11-test-dep-fix.diff is required for syntactical reasons. If you aren't root or DGA2 is not available, GRX will fallback to the default X driver, xwin :-) No DGA1 will be supported (by me). -- E-gards: Jimmy

2 1

Re: x11 font driver independence
by Mariano Alvarez Fernandez 01 Mar '03

01 Mar '03

Dimitar Zhekov wrote: > DZ>> This patch changes the x11 font driver to use it's own X11 display > MAF> Not sure. Do you mean the X11 driver is broken after the patch? > > The X11 video driver is broken now, it works exactly as a win32 driver > with no buffering would (you know what I mean). The patch changes the > font driver only, separating it completely from the video driver. > OK, I will aply the patch them But, for me, the X11 driver has only minor problems: -the inability to respond to paint events, so it must use the X11 backing-store feature, disabled by default in XFree86 4. -the slow GrPixel function. -catch the close event (like in the Win32 driver) > MAF> Or, do you plan to add backing-store capabilities to the driver? > > No, it's a dead end by me. Actually, I want to see what the direct > rendering is. Albeit it's present in XFree86 4.0+ only, a GRX driver > based on it will work much better and faster that any Window based one. > No problem if you want to work on this, but do it a independent driver, please. > Not willing to disregard the work being done on win32, I also think > that direct draw it the only correct solution for mswin. It simply does > not fit to run GRX in a window, no matter the windowing platform. > Perhaps. But is good to have the window drivers. (And the Thomas aproach to the win32 driver using DIB's is promising). Regards, Mariano.

1 0

2025

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 March 2003