Next release

Search this archive.

From: Matan Ziv-Av (matan@arava.co.il)
Date: Wed 06 Jan 1999 - 22:54:26 IST


First, the previous message was meant to be sent to Christian
Groessler personally, and not to the list, so please ignore it.

Second: I work on the next release, I changed it's number to 1.4.0,
A pre release is available from my svgalib page, 
http://www.cs.bgu.ac.il/~zivav/svgalib/svgalib-1.4.0.pre.19990106.tar.gz
or
http://www.arava.co.il/svgalib/svgalib-1.4.0.pre.19990106.tar.gz

Here are the expected features:
1-*	new modes (320x240, 400x300, 512x384, 960x720, 1600x1200, 1920x1440)
2-	arbitrary modes
3-*	better security (closing /dev/mem in vga_init)
4-	secondary card (no VT switching)
5-	vbe3 (Protected Mode) driver
6-	additional card support.

I already implemented the features marked with *, but tested them
only on my hardware (nv3, mx, apm, cirrus, vesa).

Remarks:
1- The new modes should work with any driver tht uses timing.c, rather
   than save modes. The mode lines I added in timing.c are for nv3
   with a low end 15" monitor, and a CL-5446 with a low end 14"
   monitor, other combinations might need a modeline. The new modes
   work in QuakeII.

2- I think of adding a call  int vga_newmode(int x,int y,int bit) that
   returns the mode that results in the requested resolution and color
   depth (if possible). If a mode does not have a modeline, svgalib
   will calculate a modeline by scaling modelines of modes with the
   same aspect ratio (only 4:3 is available right now).

3- This change required a change to all drivers, as all mmaps must be 
   done in ????_init or ????_test. I did not change et6000, as it is
   both in active development, and seems very different from other
   drivers. Please test on your hardware in all possible combinations
   {BACKGROUND y/n}*{linear/banked}. here's a list of the drivers:
driver 		changed	tested
ali.c		v
apm.c		v	v
ark.c		v
ati.c		v
chips.c		v[2]	
cirrus.c	v[2]	v
egadrv.c	v
et3000.c	v
et4000.c	v[1]
et6000.c
gvga6400.c	v
mach32.c	v
mx.c		v
nv3.c		v	v
oak.c		v
paradise.c	v
s3.c		v[1]
tvga8900.c	v
vesa.c		v	v
vgadrv.c	v

[1] should have no poblems with banked memory, but won't work with 
    linear addressing
[2] should work with linear framebuffer/mmio only on a pci bus.


4- I hoped it would be simply a matter of not calling setsignal (so
   that svgalib won't know when a VT is switched), apparently it is
   more complicated, so if anyone knows how to do it, or has an advice
   I'm open to suggestions.

5- This reuquires creating selectors for a0000, b0000, b8000 and a
   selctor for the bios code (which might be self modifying), and then
   calling the vesa services as a 16 bit protected mode code. I don't
   know how to do it, and the modify_ldt(2) system call does not seem
   to work. dosemu and wine seem to have code that does that, but the
   code is too complicated for me. I'm waiting for someone to write a
   library (similiar to LRMI) for accessing the code, then writing the
   svgalib vbe3 driver will be really simple.

6- I have people who "showed interest" in writing s driver for Matrox
   chipsets, Rendition, ATI (rage), and Banshee. I hope to get some
   code from this people.




--
Matan Ziv-Av.        zivav@cs.bgu.ac.il

        ש"דח הז לאמש םעפה םג
Vote MAKI - The Israeli Communist Party


This archive was generated by hypermail 2.1.4 : Wed 21 Jan 2004 - 22:10:22 IST