Re: MGA fixes don't compile
On Wed, 2 Jul 2003, Alex Deucher wrote: Actually you could probably replace the HAL functionality by using the linux matrox framebuffer driver or directfb driver as a reference. it exposes just about all the functionality of the Gxxx driver (tv out, flatpanel, YUV modes on the second crtc). Are we allowed to go grabbing chunks of code from those drivers ? I've never looked at them because I've been afraid that if I did pinch code, we could end up with a court case. Problem is we would be taking code with a GNU copyright and presenting it with an XFree86 copyright. Since I've never been taught how to do clean-room development, and don't have any guidelines, I'd rather not go reading the matroxfb code. -- Andrew C Aitchison ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
S3 Trio64UV+, S3 Trio64V2/DX
With the attached trivial patch I forced these cards to work to some extent
with XFree 4.3.0 ...
Only 8,16 bit depths work.
64V2/DX may be needed slow_dram_refresh option.
diff -u s3.bak/s3_driver.c s3/s3_driver.c
--- s3.bak/s3_driver.c2003-02-27 22:59:43 +0200
+++ s3/s3_driver.c2003-07-02 18:24:02 +0300
@@ -127,11 +127,13 @@
/* supported chipsets */
static SymTabRec S3Chipsets[] = {
-{ PCI_CHIP_964_0,964-0},
-{ PCI_CHIP_964_1,964-1},
-{ PCI_CHIP_968,968 },
-{ PCI_CHIP_TRIO, Trio32/64 },
-{ PCI_CHIP_AURORA64VP,Aurora64V+ },
+{ PCI_CHIP_964_0,964-0},
+{ PCI_CHIP_964_1,964-1},
+{ PCI_CHIP_968,968 },
+{ PCI_CHIP_TRIO, Trio32/64 },
+{ PCI_CHIP_AURORA64VP,Aurora64V+ },
+{ PCI_CHIP_TRIO64UVP, Trio64UV+ },
+{ PCI_CHIP_TRIO64V2_DXGX,Trio64V2/DX/GX },
{ -1, NULL }
};
@@ -142,6 +144,8 @@
{ PCI_CHIP_968, PCI_CHIP_968, RES_SHARED_VGA },
{ PCI_CHIP_TRIO, PCI_CHIP_TRIO, RES_SHARED_VGA },
{ PCI_CHIP_AURORA64VP,PCI_CHIP_AURORA64VP, RES_SHARED_VGA },
+{ PCI_CHIP_TRIO64UVP,PCI_CHIP_TRIO64UVP, RES_SHARED_VGA },
+{ PCI_CHIP_TRIO64V2_DXGX,PCI_CHIP_TRIO64V2_DXGX,
RES_SHARED_VGA },
{ -1,-1, RES_UNDEFINED }
};
@@ -531,6 +535,8 @@
case PCI_CHIP_AURORA64VP:/* ??? */
pS3-S3NewMMIO = FALSE;
break;
+case PCI_CHIP_TRIO64V2_DXGX:
+case PCI_CHIP_TRIO64UVP:
case PCI_CHIP_968:
pS3-S3NewMMIO = TRUE;
break;
@@ -580,6 +586,15 @@
outb(0x102, 0x01);
outb(0x46e8, 0x08);
+if (pS3-Chipset == PCI_CHIP_TRIO64V2_DXGX)
+{
+ outb (0x3d4, 0x86);
+ outb (0x3d5, 0x80);
+
+ outb (0x3d4, 0x90);
+ outb (0x3d5, 0x00);
+}
+
if (!pScrn-videoRam) {
/* probe videoram */
outb(vgaCRIndex, 0x36);
@@ -1118,7 +1133,9 @@
if (pS3-Chipset == PCI_CHIP_968)
shift = 1;/* XXX IBMRGB */
-else if (pS3-Chipset == PCI_CHIP_TRIO)
+else if (pS3-Chipset == PCI_CHIP_TRIO ||
+ pS3-Chipset == PCI_CHIP_TRIO64UVP ||
+ pS3-Chipset == PCI_CHIP_TRIO64V2_DXGX)
shift = -(pS3-s3Bpp 1);
return shift;
diff -u s3.bak/s3.h s3/s3.h
--- s3.bak/s3.h2002-12-11 19:30:47 +0200
+++ s3/s3.h2003-06-27 12:40:22 +0300
@@ -240,6 +240,8 @@
#define S3_964_SERIES()((pS3-Chipset == PCI_CHIP_964_0) ||\
(pS3-Chipset == PCI_CHIP_964_1))
#defineS3_TRIO_SERIES()((pS3-Chipset == PCI_CHIP_TRIO) ||\
- (pS3-Chipset == PCI_CHIP_AURORA64VP))
+ (pS3-Chipset == PCI_CHIP_AURORA64VP) || \
+ (pS3-Chipset == PCI_CHIP_TRIO64UVP) || \
+ (pS3-Chipset == PCI_CHIP_TRIO64V2_DXGX))
#endif /* _S3_H */
diff -u s3.bak/s3_Trio64DAC.c s3/s3_Trio64DAC.c
--- s3.bak/s3_Trio64DAC.c2003-02-27 22:59:43 +0200
+++ s3/s3_Trio64DAC.c2003-07-02 17:40:30 +0300
@@ -324,9 +324,13 @@
if (pS3-Chipset == PCI_CHIP_AURORA64VP)
S3TrioSetClock(pScrn, mode-Clock, 2, 1, 1, 63, 0, 3, 2,
135000, 27);
+else if (pS3-Chipset == PCI_CHIP_TRIO64V2_DXGX)
+S3TrioSetClock(pScrn, mode-Clock, 2, 1, 1, 31, 0, 3, 2,
+ 17, 27);
else
S3TrioSetClock(pScrn, mode-Clock, 2, 1, 1, 31, 0, 3, 2,
135000, 27);
+
outb(0x3c4, 1);
blank = inb(0x3c5);
@@ -347,6 +351,11 @@
sr18 = inb(0x3c5) ~0x80;
outb(pS3-vgaCRIndex, 0x33);
cr33 = inb(pS3-vgaCRReg) ~0x28;
+
+if (pS3-Chipset == PCI_CHIP_TRIO64V2_DXGX)
+{
+ cr33 |= 0x20;
+}
/* ! pixmux */
switch (pScrn-depth) {
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
News about 3D..
Hi, I would like to know when SiS650 users could have the 3D support for the card on Linux. I hope you work on it. Serdar Cevher ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: mkfontscale strikes again
Kean Johnston writes: Egbert Eich wrote: Juliusz, Kean, please check below and tell me if it does what you expect. Mostly, except for the -x stuff. Can you and Juliusz apply and try the attached patch? This doesnt include the X11.tmpl cleanup portion of my original patch, but ti does clean up some missing prototypes and unused variables in mkfontscale, as well as changing the old -x to -a, and making -x be the exclusion suffix. Thanks! I'm currently running a 'make World' with it. As the '-x' option was only added very recently I don't think it has any negative effect. Juliusz? I have your X11.tmpl changes in my tree ready for commit so it shouldn't get lost. Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Negative y values to fbcon_xx_putcs?
On Thu, 2003-07-03 at 10:51, Cheshire Cat Fish wrote: My putcs function is getting negative y values. None of the other driver sources I have looked at appear to do anything to handle negative y values. What would cause my putcs to be called with a negative Y? Wrong list, please follow up to linux-fbdev-devel only. -- Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: MGA fixes don't compile
I believe someone asked Petr once and he said he didn't mind if we used his driver as a reference. IANAL, but as long as you didn't just blatantly cut and paste the code, couldn't you use it as a reference? Still, probably better to get Petr's (and possibly directfb's) ok. Alex --- Andrew C Aitchison [EMAIL PROTECTED] wrote: On Wed, 2 Jul 2003, Alex Deucher wrote: Actually you could probably replace the HAL functionality by using the linux matrox framebuffer driver or directfb driver as a reference. it exposes just about all the functionality of the Gxxx driver (tv out, flatpanel, YUV modes on the second crtc). Are we allowed to go grabbing chunks of code from those drivers ? I've never looked at them because I've been afraid that if I did pinch code, we could end up with a court case. Problem is we would be taking code with a GNU copyright and presenting it with an XFree86 copyright. Since I've never been taught how to do clean-room development, and don't have any guidelines, I'd rather not go reading the matroxfb code. -- Andrew C Aitchison ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: S3 Trio64UV+, S3 Trio64V2/DX
open a bug at http://bugs.xfree86.org/ and include your patch so that
it doesn't get lost. hopefully it will get fixed up and integrated.
Alex
--- áÌÅËÓÅÊ_âÁÊ [EMAIL PROTECTED] wrote:
With the attached trivial patch I forced these cards to work to some
extent
with XFree 4.3.0 ...
Only 8,16 bit depths work.
64V2/DX may be needed slow_dram_refresh option.
diff -u s3.bak/s3_driver.c s3/s3_driver.c
--- s3.bak/s3_driver.c2003-02-27 22:59:43 +0200
+++ s3/s3_driver.c2003-07-02 18:24:02 +0300
@@ -127,11 +127,13 @@
/* supported chipsets */
static SymTabRec S3Chipsets[] = {
-{ PCI_CHIP_964_0,964-0},
-{ PCI_CHIP_964_1,964-1},
-{ PCI_CHIP_968,968 },
-{ PCI_CHIP_TRIO, Trio32/64 },
-{ PCI_CHIP_AURORA64VP,Aurora64V+ },
+{ PCI_CHIP_964_0,964-0},
+{ PCI_CHIP_964_1,964-1},
+{ PCI_CHIP_968,968 },
+{ PCI_CHIP_TRIO, Trio32/64 },
+{ PCI_CHIP_AURORA64VP,Aurora64V+ },
+{ PCI_CHIP_TRIO64UVP, Trio64UV+ },
+{ PCI_CHIP_TRIO64V2_DXGX,Trio64V2/DX/GX },
{ -1, NULL }
};
@@ -142,6 +144,8 @@
{ PCI_CHIP_968, PCI_CHIP_968, RES_SHARED_VGA },
{ PCI_CHIP_TRIO, PCI_CHIP_TRIO, RES_SHARED_VGA },
{ PCI_CHIP_AURORA64VP,PCI_CHIP_AURORA64VP,
RES_SHARED_VGA },
+{ PCI_CHIP_TRIO64UVP,PCI_CHIP_TRIO64UVP, RES_SHARED_VGA
},
+{ PCI_CHIP_TRIO64V2_DXGX,PCI_CHIP_TRIO64V2_DXGX,
RES_SHARED_VGA },
{ -1,-1, RES_UNDEFINED }
};
@@ -531,6 +535,8 @@
case PCI_CHIP_AURORA64VP:/* ??? */
pS3-S3NewMMIO = FALSE;
break;
+case PCI_CHIP_TRIO64V2_DXGX:
+case PCI_CHIP_TRIO64UVP:
case PCI_CHIP_968:
pS3-S3NewMMIO = TRUE;
break;
@@ -580,6 +586,15 @@
outb(0x102, 0x01);
outb(0x46e8, 0x08);
+if (pS3-Chipset == PCI_CHIP_TRIO64V2_DXGX)
+{
+ outb (0x3d4, 0x86);
+ outb (0x3d5, 0x80);
+
+ outb (0x3d4, 0x90);
+ outb (0x3d5, 0x00);
+}
+
if (!pScrn-videoRam) {
/* probe videoram */
outb(vgaCRIndex, 0x36);
@@ -1118,7 +1133,9 @@
if (pS3-Chipset == PCI_CHIP_968)
shift = 1;/* XXX IBMRGB */
-else if (pS3-Chipset == PCI_CHIP_TRIO)
+else if (pS3-Chipset == PCI_CHIP_TRIO ||
+ pS3-Chipset == PCI_CHIP_TRIO64UVP ||
+ pS3-Chipset == PCI_CHIP_TRIO64V2_DXGX)
shift = -(pS3-s3Bpp 1);
return shift;
diff -u s3.bak/s3.h s3/s3.h
--- s3.bak/s3.h2002-12-11 19:30:47 +0200
+++ s3/s3.h2003-06-27 12:40:22 +0300
@@ -240,6 +240,8 @@
#define S3_964_SERIES()((pS3-Chipset == PCI_CHIP_964_0) ||
\
(pS3-Chipset == PCI_CHIP_964_1))
#defineS3_TRIO_SERIES()((pS3-Chipset == PCI_CHIP_TRIO) ||
\
- (pS3-Chipset == PCI_CHIP_AURORA64VP))
+ (pS3-Chipset == PCI_CHIP_AURORA64VP) || \
+ (pS3-Chipset == PCI_CHIP_TRIO64UVP) || \
+ (pS3-Chipset == PCI_CHIP_TRIO64V2_DXGX))
#endif /* _S3_H */
diff -u s3.bak/s3_Trio64DAC.c s3/s3_Trio64DAC.c
--- s3.bak/s3_Trio64DAC.c2003-02-27 22:59:43 +0200
+++ s3/s3_Trio64DAC.c2003-07-02 17:40:30 +0300
@@ -324,9 +324,13 @@
if (pS3-Chipset == PCI_CHIP_AURORA64VP)
S3TrioSetClock(pScrn, mode-Clock, 2, 1, 1, 63, 0, 3, 2,
135000, 27);
+else if (pS3-Chipset == PCI_CHIP_TRIO64V2_DXGX)
+S3TrioSetClock(pScrn, mode-Clock, 2, 1, 1, 31, 0, 3, 2,
+ 17, 27);
else
S3TrioSetClock(pScrn, mode-Clock, 2, 1, 1, 31, 0, 3, 2,
135000, 27);
+
outb(0x3c4, 1);
blank = inb(0x3c5);
@@ -347,6 +351,11 @@
sr18 = inb(0x3c5) ~0x80;
outb(pS3-vgaCRIndex, 0x33);
cr33 = inb(pS3-vgaCRReg) ~0x28;
+
+if (pS3-Chipset == PCI_CHIP_TRIO64V2_DXGX)
+{
+ cr33 |= 0x20;
+}
/* ! pixmux */
switch (pScrn-depth) {
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
__
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
color swapping problem
Hello, I'm working on a PowerPC (big endian) processor but my graphic controller (Silicon Motion SMI712) insists on treating its frame buffer as little endian. Working at 16bpp, byte swapping led me to incorrect colors on my display. Is there an option or a patch available in the Xserver to get rid of this issue? Thanks, Laurent MOHIN ACTERNA ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: mkfontscale strikes again
RM Weired. I don't see that problem when running mkfontscale RM (Solaris2.7/SPARC build with Sun Workshop/Forte 7) ... Try -e. Juliusz ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Blame assignment [was: mkfontscale strikes again]
EE So far submitted code was thoroughly tested... EE I would like to get to a situation where the submitter himself EE takes over more responsibilities and takes his code to a committable EE state... I think that both should be available -- (1) the case when I take full responsibility for a patch and you trust me, and (2) the case when I don't feel competent and want you to double-check what I'm doing. We need some convention to distinguish between (1) and (2). The lkml, for example, use the phrase ``please apply'' to mark case (1). Juliusz ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: mkfontscale strikes again
KJ I am in favour (personally) of making -x mean eXclude a suffix KJ and perhaps changing the current mkfontscale's -x to -a, for (a)dd KJ an encoding. I agree. Juliusz ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: mkfontscale strikes again
From the code I don't see a difference in order between you version and Juliusz's either, am I wrong? KJ No you're not. I didnt know if those semantics were important so I KJ didn't change them. I am not sure they are important, but since this KJ is a replacement for mkfontdir, I think it is prudent to err on the KJ side of caution. I wouldn't bother. No strong objection, though. Juliusz ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: mkfontscale strikes again
Juliusz Chroboczek wrote: RM Weired. I don't see that problem when running mkfontscale RM (Solaris2.7/SPARC build with Sun Workshop/Forte 7) ... Try -e. That's what I did (% mkfontscale-e $PWD # in the encodings/ dir) ... Bye, Roland -- __ . . __ (o.\ \/ /.o) [EMAIL PROTECTED] \__\/\/__/ [EMAIL PROTECTED] /O /==\ O\ MPEG specialist, CJAVASunUnix programmer (;O/ \/ \O;) TEL +49 641 99-41370 FAX +49 641 99-41359 ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Xinerama on GeForce4 cards?
Alex Deucher [EMAIL PROTECTED] wrote: I don't suppose you can contribute your code back? I've sure someone could get it working in due time. Unfortunately no (NVIDIA will not let us Open Source any of our code due to existing NDA's), but we are using the riva_hw.c module from XFree86. Our version only has a few slight modifications from the version in 4.3.0, and not related to multi-head. Basically as long as the BIOS posts both heads and comes up in clone mode, the XFree86 4.3.0 nv driver should be able to handle multi-head if someone sat down and tweaked it. All you need to do is make sure you control the correct CRTC registers etc for the appropriate head, and make sure you have the crtcOwner register set to the correct values. Regards, --- Kendall Bennett Chief Executive Officer SciTech Software, Inc. Phone: (530) 894 8400 http://www.scitechsoft.com ~ SciTech SNAP - The future of device driver technology! ~ ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Xinerama on GeForce4 cards?
Mark Vojkovich [EMAIL PROTECTED] wrote: Ok. Our code is actually working with dual head on the NVIDIA cards provided that the BIOS has posted both heads to run in clone mode. On some cards the BIOS does not post the second head and only one head comes up, and the riva_hw.c module is not able to initialise the second head. I guess we are stuck in that case ;-) This would be the expected behavior. You can run either head if the card was posted in clone mode. You can probably even run CRTs on the secondary head, but DFP will only work if it was posted. Yes, that is correct. We don't yet support DFP flat panels, but run multi- head using BTW, how come some BIOS'es do not post both heads, even though there are two monitors attached? Quadro4's with the splitter cable is one such combination. The second head is never posted, but if you boot the machine with only the second head connected, it comes up fine and runs just on that head. Seems weird that the BIOS does not post both heads Regards, --- Kendall Bennett Chief Executive Officer SciTech Software, Inc. Phone: (530) 894 8400 http://www.scitechsoft.com ~ SciTech SNAP - The future of device driver technology! ~ ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Blame assignment [was: mkfontscale strikes again]
Juliusz Chroboczek writes: EE So far submitted code was thoroughly tested... EE I would like to get to a situation where the submitter himself EE takes over more responsibilities and takes his code to a committable EE state... I think that both should be available -- (1) the case when I take full responsibility for a patch and you trust me, and (2) the case when I don't feel competent and want you to double-check what I'm doing. Definitely. In some cases the four eyes principle is the only way. There are pieces of code where I have just as much expertise about as you do. And I expect that even those who have been on the project much longer than me have not looked into every tiny corner. We need some convention to distinguish between (1) and (2). The lkml, for example, use the phrase ``please apply'' to mark case (1). Right! Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Blame assignment [was: mkfontscale strikes again]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 4 Jul 2003 06:22 am, Egbert Eich wrote: I think that both should be available -- (1) the case when I take full responsibility for a patch and you trust me, and (2) the case when I don't feel competent and want you to double-check what I'm doing. Definitely. In some cases the four eyes principle is the only way. There are pieces of code where I have just as much expertise about as you do. And I expect that even those who have been on the project much longer than me have not looked into every tiny corner. We need some convention to distinguish between (1) and (2). The lkml, for example, use the phrase ``please apply'' to mark case (1). Right! I've personally used please review and apply if OK. Seems to work OK, although if this is going to a mailing list, sometimes you won't get it reviewed - it'll just get dropped. That usually means that no-one else thought it was OK (eg it was too hard, no-one else felt confident, poorly phrased request, just too busy) and you need to work it some more yourself. For more invasive changes, using [RFC/RFD] and describing the changes (not just a posting of a diff) and the relative advantages/disadvantages is clearly a good idea. How you work that into a formal mentoring arrangement probably depends on the individual developers involved. Probably a community based (eg mailing list) arrangement is better, especially in the (common) situation pointed out above, where a particular developer may be quite inexperienced in general, but have particular expertise in a certain area. Brad BTW: Thanks to all the XFree86 developers - great work. -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE/BJjXW6pHgIdAuOMRAoLJAKCWE3T0DXW6jqdf/okbLk5UR/gs6QCfTF9j 27aDHNYCoVJuWbxkhOGEeyQ= =t/Av -END PGP SIGNATURE- ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: S3 Trio64UV+, S3 Trio64V2/DX
On Thu, 3 Jul 2003, Alex Deucher wrote:
Date: Thu, 3 Jul 2003 07:10:09 -0700 (PDT)
From: Alex Deucher [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
Content-Type: text/plain; charset=us-ascii
Subject: Re: S3 Trio64UV+, S3 Trio64V2/DX
open a bug at http://bugs.xfree86.org/ and include your patch so that
it doesn't get lost. hopefully it will get fixed up and integrated.
Be sure to regenerate the patch without gratuitous whitespace
changes though.
Only 8,16 bit depths work.
64V2/DX may be needed slow_dram_refresh option.
diff -u s3.bak/s3_driver.c s3/s3_driver.c
--- s3.bak/s3_driver.c2003-02-27 22:59:43 +0200
+++ s3/s3_driver.c2003-07-02 18:24:02 +0300
@@ -127,11 +127,13 @@
/* supported chipsets */
static SymTabRec S3Chipsets[] = {
-{ PCI_CHIP_964_0,964-0},
-{ PCI_CHIP_964_1,964-1},
-{ PCI_CHIP_968,968 },
-{ PCI_CHIP_TRIO, Trio32/64 },
-{ PCI_CHIP_AURORA64VP,Aurora64V+ },
+{ PCI_CHIP_964_0,964-0},
^
is that necessary?
+{ PCI_CHIP_964_1,964-1},
+{ PCI_CHIP_968,968 },
+{ PCI_CHIP_TRIO, Trio32/64 },
+{ PCI_CHIP_AURORA64VP,Aurora64V+ },
+{ PCI_CHIP_TRIO64UVP, Trio64UV+ },
+{ PCI_CHIP_TRIO64V2_DXGX,Trio64V2/DX/GX },
{ -1, NULL }
};
@@ -142,6 +144,8 @@
{ PCI_CHIP_968, PCI_CHIP_968, RES_SHARED_VGA },
{ PCI_CHIP_TRIO, PCI_CHIP_TRIO, RES_SHARED_VGA },
{ PCI_CHIP_AURORA64VP,PCI_CHIP_AURORA64VP,
RES_SHARED_VGA },
+{ PCI_CHIP_TRIO64UVP,PCI_CHIP_TRIO64UVP, RES_SHARED_VGA
},
+{ PCI_CHIP_TRIO64V2_DXGX,PCI_CHIP_TRIO64V2_DXGX,
RES_SHARED_VGA },
{ -1,-1, RES_UNDEFINED }
};
@@ -531,6 +535,8 @@
case PCI_CHIP_AURORA64VP:/* ??? */
pS3-S3NewMMIO = FALSE;
break;
+case PCI_CHIP_TRIO64V2_DXGX:
+case PCI_CHIP_TRIO64UVP:
case PCI_CHIP_968:
pS3-S3NewMMIO = TRUE;
break;
@@ -580,6 +586,15 @@
outb(0x102, 0x01);
outb(0x46e8, 0x08);
+if (pS3-Chipset == PCI_CHIP_TRIO64V2_DXGX)
+{
+ outb (0x3d4, 0x86);
+ outb (0x3d5, 0x80);
+
+ outb (0x3d4, 0x90);
+ outb (0x3d5, 0x00);
These should not be hard coded register values.
+}
+
if (!pScrn-videoRam) {
/* probe videoram */
outb(vgaCRIndex, 0x36);
@@ -1118,7 +1133,9 @@
if (pS3-Chipset == PCI_CHIP_968)
shift = 1;/* XXX IBMRGB */
-else if (pS3-Chipset == PCI_CHIP_TRIO)
+else if (pS3-Chipset == PCI_CHIP_TRIO ||
+ pS3-Chipset == PCI_CHIP_TRIO64UVP ||
+ pS3-Chipset == PCI_CHIP_TRIO64V2_DXGX)
shift = -(pS3-s3Bpp 1);
return shift;
diff -u s3.bak/s3.h s3/s3.h
--- s3.bak/s3.h2002-12-11 19:30:47 +0200
+++ s3/s3.h2003-06-27 12:40:22 +0300
@@ -240,6 +240,8 @@
#define S3_964_SERIES()((pS3-Chipset == PCI_CHIP_964_0) ||
\
(pS3-Chipset == PCI_CHIP_964_1))
#defineS3_TRIO_SERIES()((pS3-Chipset == PCI_CHIP_TRIO) ||
\
- (pS3-Chipset == PCI_CHIP_AURORA64VP))
+ (pS3-Chipset == PCI_CHIP_AURORA64VP) || \
+ (pS3-Chipset == PCI_CHIP_TRIO64UVP) || \
+ (pS3-Chipset == PCI_CHIP_TRIO64V2_DXGX))
Again, a bit of gratuitous whitespace change. I'd tidy all of
these things up before submitting to increase the chance of it
being committed.
Hope this helps.
--
Mike A. Harris
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
