Grx

grx@gnu.de

559 discussions

bcc cleanall sync
by Dimitar Zhekov 08 Apr '03

08 Apr '03

makefile.bcc: add a cleanall target, as in the other makefiles src/makefile.bcc: sync clean/cleanall with the other makefiles -- E-gards: Jimmy

1 0

GRX 2.4.6 pre-release 3
by Mariano Alvarez Fernandez 05 Apr '03

05 Apr '03

Hi, I have uploaded a new pre-release of GRX 2.4.6, big changes: - Included the new Dimitar's DGA2 video driver, experimental, not compiled by default (Indeed it doesn't work in my ssytem, Xfree86 4.2 and Vodoo 3, the screen is blanked and nothing happens). - New Win32 framedrivers. Using the Thomas idea about the DIB, Josu Onandia and I have written new 8bpp and 24bpp framedrivers based on the standard LFB drivers. Now the Win32 GRX version run very fast and doesn't suffer the bugs that the old framedrivers had. http://grx.gnu.de/more.html Enjoy, M.Alvarez

1 0

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

x11 font driver independence
by Dimitar Zhekov 26 Feb '03

26 Feb '03

This patch changes the x11 font driver to use it's own X11 display and window. It allows X11 fonts to be loaded before GrSetMode() and makes the font driver independent from the X11 video and frame drivers. Additionally, it is now certain that all X11 video/frame drivers variables are used by these drivers only (correct me if I'm wrong). So now I'll try to fix the X11 video output (it either has no buffering or it doesn't work at all), but wanted to get rid of the font driver accessing X11 video/frame first. Any comments? Note: incrementional patch - apply x11-fdv-ulpos-fix.diff first. -- E-gards: Jimmy

2 1

← Newer
1
...
20
21
22
23
24
25
26
...
56
Older →

Jump to page:

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