Bug#182773: xserver-xfree86: [mga] Any opengl app on 4.2.1-5 and 4.2.1-6 crashes the hardware hard.

2003-03-01 Thread Michael Epting
On Thu, Feb 27, 2003 at 08:04:55PM +, Phil Armstrong wrote:
 Package: xserver-xfree86
 Version: 4.2.1-6
 Severity: normal
 
 Just running glxinfo on 4.2.1-5 or 4.2.1-6 is enough to put my G400
 in an unusable state, with screen corruption all over the
 place. Switching to another console is possible, but the corruption
 remains; switching back to the X console hangs the system completely.
 
 4.2.1-4 appears to be entirely stable. I think I missed this bug on
 4.2.1-5 due to running the experimental dri packages at the time.
 
 Let me know if there's any diagnostics I can run.

Phil, I have a G400 and 3d is working perfectly for me at this point.
All the GL screensavers and armagetron work great and fast.

I seem to have all the 4.2.1.5 sid xfree packages including
xlibmesa-gl and xlibmesa-glu.  I did knock my screen resolution down to
1600x1200 and my color depth to 16 based on a recent post pointing out
that bad things happen when you exhaust the memory on your G400.

Oh, yeah, I'm using the stock mga_drv.o, not the one from Matrox.





Bug#182773: xserver-xfree86: [mga] Any opengl app on 4.2.1-5 and 4.2.1-6 crashes the hardware hard.

2003-02-28 Thread Michael Epting
On Thu, Feb 27, 2003 at 08:04:55PM +, Phil Armstrong wrote:
 Package: xserver-xfree86
 Version: 4.2.1-6
 Severity: normal
 
 Just running glxinfo on 4.2.1-5 or 4.2.1-6 is enough to put my G400
 in an unusable state, with screen corruption all over the
 place. Switching to another console is possible, but the corruption
 remains; switching back to the X console hangs the system completely.
 
 4.2.1-4 appears to be entirely stable. I think I missed this bug on
 4.2.1-5 due to running the experimental dri packages at the time.
 
 Let me know if there's any diagnostics I can run.

Phil, I have a G400 and 3d is working perfectly for me at this point.
All the GL screensavers and armagetron work great and fast.

I seem to have all the 4.2.1.5 sid xfree packages including
xlibmesa-gl and xlibmesa-glu.  I did knock my screen resolution down to
1600x1200 and my color depth to 16 based on a recent post pointing out
that bad things happen when you exhaust the memory on your G400.

Oh, yeah, I'm using the stock mga_drv.o, not the one from Matrox.




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



S3Virge solution

2001-02-14 Thread Michael Epting

I had a different problem from many of the people posting last week:
XFree 4.0.2 worked for me, but my virtual consoles were unusable after
X had run, even if X were killed.  Well I just made a new kernel with
fb support and stuck a vga=791 into my lilo.conf.  Now all is well, 
even glxinfo says so, althought the gl screensavers are molasses-slow.
This is on a Tecra550CDT with a 266 mHz Pentium and an s3virge mx.


--  
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]




S3Virge solution

2001-02-14 Thread Michael Epting
I had a different problem from many of the people posting last week:
XFree 4.0.2 worked for me, but my virtual consoles were unusable after
X had run, even if X were killed.  Well I just made a new kernel with
fb support and stuck a vga=791 into my lilo.conf.  Now all is well, 
even glxinfo says so, althought the gl screensavers are molasses-slow.
This is on a Tecra550CDT with a 266 mHz Pentium and an s3virge mx.



Re: xserver-xfree86 4.0.2-1 and S3 ViRGE/MX problems

2001-02-03 Thread Michael Epting
On Sat, Feb 03, 2001 at 11:49:49AM -0500, Kevin Brosius wrote:
 I've also put up another test version at
 http://www.user1.netcarrier.com/~kbrosius/virge.html.  Try it without
 the pci_burst option if you still have trouble.  Let me know if anything
 changes.

I've been following this thread with great interest, as the upgrade
from testing to unstable sort of broke X on my Tecra laptop, which
uses the S3 Virge MX+ chipset.  X works OK on this machine, but my
virtual consoles are thrashed and only rebooting seems to fix them.  I
just grabbed and tried out the s3virge_drv.402+_161.gz and it works
just the same as the stock driver from the current .deb.

I also tried the vesa driver and it works correctly, so I think that
the s3virge driver just doesn't know how to restore my display when I
pop out of X, either by exiting or by using Ctrl-Alt-Fn.  The vesa
driver either doesn't screw up the display (and the Driver line is the
only change I'm making in my XF86Config-4) or it knows how to restore
it properly.



Re: I am a stupid idiot for posting a FAQ, but...

2000-10-31 Thread Michael Epting

On Mon, Oct 30, 2000 at 09:38:45PM -0500, Buddha Buck wrote:
 The bright ones here will be saying "Oh gods, he's going to ask about 
 libGLU, isn't he?"

Brandon wrote an excellent answer on 17 Sep, which is in the list archives.
Briefly, to quote him:
---
+ In the meantime, users are going to have play games behind the back of
  the packaging system to satisfy any program that requires libGLU:

  - retrieve the appropriate mesag3 .deb package for your architecture
  - put it in a subdirectory of /tmp (not /tmp itself)
  - dpkg-deb -x mesag3-glide2_3.2.1-1_i386.deb .
(or whatever the .deb is named)
  - become root, and return to this directory if necessary
  - cd usr/lib
  - as root, cp *libGLU* /usr/lib
---
This works for me.


--  
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]




Re: I am a stupid idiot for posting a FAQ, but...

2000-10-31 Thread Michael Epting
On Mon, Oct 30, 2000 at 09:38:45PM -0500, Buddha Buck wrote:
 The bright ones here will be saying Oh gods, he's going to ask about 
 libGLU, isn't he?

Brandon wrote an excellent answer on 17 Sep, which is in the list archives.
Briefly, to quote him:
---
+ In the meantime, users are going to have play games behind the back of
  the packaging system to satisfy any program that requires libGLU:

  - retrieve the appropriate mesag3 .deb package for your architecture
  - put it in a subdirectory of /tmp (not /tmp itself)
  - dpkg-deb -x mesag3-glide2_3.2.1-1_i386.deb .
(or whatever the .deb is named)
  - become root, and return to this directory if necessary
  - cd usr/lib
  - as root, cp *libGLU* /usr/lib
---
This works for me.



Re: Hardware GL with a G400

2000-10-13 Thread Michael Epting
On Fri, Oct 13, 2000 at 08:06:45AM -0500, Thomas E. Vaughan wrote:
 On Fri, Oct 13, 2000 at 06:11:47PM +1100, Gordon Heydon wrote:
  
  This is a simple question, can anyone tell me how to or better point me
  in the direction of some documentation on how to get hardware 3gl going
  with my dual head g400 (I am only using 1 head at the moment) with the
  Xfree 4.0.1 debs found here.
 
 If you haven't done so already, then get the source code to kernel
 2.4.0-test9.  I compiled support for my AGP chipset directly into the
 kernel, and I recommend compiling the matrox DRI support as a module.  I
 may be wrong, but it seems that, at least in the past, the X server liked
 to load the kernel module itself.  After installing the new kernel and DRI
 module, remember to reboot.
 
 Dexter, the X configuration program that ran when I installed the most
 recent debs, made a fairly good approximation of an XF86Config-4 file for
 me.  Make sure that you add the following lines:
 
 Section DRI
 Mode 0666
 EndSection

I have had an off-list exchange with Thomas that clarified but did not resolve a
problem I have with DRI.  I get hardware 3d acceleration, as he does, with
2.4.0-test9, which resolved the version mismatch of earlier kernel 2.4 releases.
However, while X is running, my virtual consoles are not usable.  It turns out
that the major difference between our installations is hardware -- I have an 
ASUS
P5A motherboard with the ALI chipset.  Does anybody have DRI working with the
G400/P5A combination?  (or any other ALI-based motherboard?)



Some tips and a question

2000-09-19 Thread Michael Epting
I'm successfully using the latest 4.0.1-0phase2v7 debs from 
 deb http://samosa.debian.org/~branden/woody i386/
and I've discovered a few things that I haven't seen mentioned here.

If you blow away (mv, actually) old XF86Config files and run xf86cfg (not
xf86config!), you can make a perfectly usable XF86Config effortlessly.  Just 
make
sure you click on Configure Layout, because that's really a drop-down menu 
button,
not just a title!  Choose Configure Screen and choose your default color depth 
and
resolutions.

Your bitmap fonts will work with no Files section at all, but if you want Type 
1,
speedo, and truetypes, you will need to load the necessary modules, as has been
mentioned repeatedly here.  Netscape won't recognize truetypes, however, unless 
you
configure xfs and use it by adding to XF86Config:

Section Files
FontPath unix/:7100
EndSection

If you have time to read only one doc, read 
/usr/share/doc/xfree86-common/RELNOTES.
In my case (Matrox G400) it pointed me to one vital link (dri.sourceforge.net).

The question: after I got DRI working perfectly, as shown in 
/var/log/XFree86.0.log
(another free tip!), my virtual consoles were all very screwed up (unusable!) 
and
I experienced a hard crash (I couldn't even telnet in -- I had to hit the reset
switch). Removing DefaultFbBpp 32 from XF86Config kills DRI and restores
stability.  Has anybody gotten DRI to work with G400 and kernel 2.4.0-test8?