Re: lrmi vs new kernels vs libx86
On Sun, Mar 08, 2009 at 09:07:29PM +0100, David Paleino wrote: > Matthew: since you're libx86 upstream, you might be interested in the contents > of debian/patches, I'll remove those as soon as you release a new version > (also, please drop debian/ from upstream tarballs) Thanks, I'll take a look at those. -- Matthew Garrett | mj...@srcf.ucam.org -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#272085: InputDevice stanzas for both /dev/psaux and /dev/input/mice cause events to be received twice on 2.6 kernels
On Thu, Jan 11, 2007 at 07:24:17PM +0100, Brice Goglin wrote: > Hi Matthew, > > About 2 years ago, you reported a bug to the Debian BTS regarding mouse > events being received twice by the X server when running a 2.6 kernels. > Did you reproduce this problem recently? If not, I will close the bug in > the next weeks. I'm afraid I don't have any Debian installs at the moment - however, I believe that this was fixed before the release of woody. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#303640: kernel-image-2.6.8-10-amd64-k8: Xfree86 fails to find a VESA chipset
On Sun, Apr 10, 2005 at 08:03:55PM +0200, Kurt Roeckx wrote: > On Fri, Apr 08, 2005 at 10:17:47PM +0200, David Robin wrote: > > please note the message "XFree86: vm86 mode not supported on 64 bit > > kernel" at the end of the log. I have just noticed it. May this issue > > be related to XFree86? > > I'm assuming that this is using the amd64 kernel with a i386 > userland? ia32 builds of Xorg use vm86 for real-mode BIOS calls. 64-bit kernels don't support the vm86 syscall, even with 32-bit userland. The Vesa driver requires the ability to make real-mode BIOS calls. This can never work. I'd suggest just closing this. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#383465: Contains obfuscated source code, DFSG violation?
Sorry? 12 of the files in the source tree contain explicit Nvidia copyright statements. The others tend to have no copyrights at all, but are generally written by Mark Vojkovich who is an nvidia employee. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#383465: Contains obfuscated source code, DFSG violation?
Package: xserver-xorg-video-nv
Version: 1:1.0.1.5-2
Severity: serious
The nv driver appears to be heavily obfuscated and is effectively
unmodifiable. Rather than symbolic constants, almost every reference to
hardware is performed using undocumented hex. The only registers that
appear to be documented are the legacy CRTC ones which are effectively
identical over all hardware. Take for example NVBacklightEnable:
if((pNv->Chipset == 0x10DE0179) ||
(pNv->Chipset == 0x10DE0189) ||
(pNv->Chipset == 0x10DE0329))
{
/* NV17,18,34 Apple iMac, iBook, PowerBook */
CARD32 tmp_pmc, tmp_pcrt;
tmp_pmc = pNv->PMC[0x10F0/4] & 0x7FFF;
tmp_pcrt = pNv->PCRTC0[0x081C/4] & 0xFFFC;
if(on) {
tmp_pmc |= (1 << 31);
tmp_pcrt |= 0x1;
}
pNv->PMC[0x10F0/4] = tmp_pmc;
pNv->PCRTC0[0x081C/4] = tmp_pcrt;
}
The idea that nvidia do not posess an electronic list of register names
and offsets is entirely implausible. The only rational explanation is
that register information is postprocessed out in order to reduce
information leakage. The shipped code is certainly not the preferred
form for modification, and according to prevailing attitudes on
debian-legal should be removed from Debian.
--
Matthew Garrett | [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: XFree86 4.0.3-0pre1v1 (voodoo3)
On Tue, Apr 10, 2001 at 01:27:24AM +0200, Kenneth Johansson wrote: > I tried it on a voodoo3 card and everything seems good until I try openGL in > DRI mode then the application (gears) gets a segmentation fault. Try reducing your resolution. The TDFX driver seems to have pretty severe problems coping with screens using large amounts of memory. At 1792x1344 (16 bit) everything works for me. At 1840x1392 DRI apps segfault if they try to display anything (glxinfo still works fine). At 1960x1440, I get severe screen corruption. I've had the same problem since 4.01 (which is when I got my V3). As far as I know, it's a known issue. -- Matthew Garrett | [EMAIL PROTECTED]
Re: XFree86 4.0.3-0pre1v1 (voodoo3)
On Tue, Apr 10, 2001 at 01:27:24AM +0200, Kenneth Johansson wrote: > I tried it on a voodoo3 card and everything seems good until I try openGL in DRI >mode then the application (gears) gets a segmentation fault. Try reducing your resolution. The TDFX driver seems to have pretty severe problems coping with screens using large amounts of memory. At 1792x1344 (16 bit) everything works for me. At 1840x1392 DRI apps segfault if they try to display anything (glxinfo still works fine). At 1960x1440, I get severe screen corruption. I've had the same problem since 4.01 (which is when I got my V3). As far as I know, it's a known issue. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Where is libGL hiding?
On Wed, Dec 20, 2000 at 05:15:55PM +0100, Alexander Ehlert wrote: > No it's not, because xlibmesa is the doing software rendering. I'm looking > for the libGL which supports the DRI driven cards. In the original > XFree distribution libGL is included in bin.tgz together with all other > libs which reside in the xlibs package with debian (excluding libGL). xlibmesa3 supports DRI. The old libmesa packages didn't. -- Matthew Garrett | [EMAIL PROTECTED]
Re: Where is libGL hiding?
On Wed, Dec 20, 2000 at 05:15:55PM +0100, Alexander Ehlert wrote: > No it's not, because xlibmesa is the doing software rendering. I'm looking > for the libGL which supports the DRI driven cards. In the original > XFree distribution libGL is included in bin.tgz together with all other > libs which reside in the xlibs package with debian (excluding libGL). xlibmesa3 supports DRI. The old libmesa packages didn't. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: -11 gives graphics corruption with V3 3000
On Wed, Dec 13, 2000 at 01:47:17PM -0500, Zephaniah E. Hull wrote: > On Tue, Dec 12, 2000 at 10:39:55PM +0000, Matthew Garrett wrote: > > xserver-xfree86-11 gives corruption on my V3 3000. Black bars run across > > the top of the screen, and moving windows causes corruption. I'm running at > > 1792x1344 using DRI. Dropping back to the xserver-10 package (and keeping > > the -11 ones for everything else) fixed things. Does -11 have a new > > upstream version? > > Errr, it actually WORKS at 1792x1344? *grumble* > > Try it at 1024x768, it may be the same bug, or a different one. Reducing screen resolution while keeping a 1792x1344 virtual doesn't help, but reducing the size of the virtual as well removes the corruption. -- Matthew Garrett | [EMAIL PROTECTED]
Re: -11 gives graphics corruption with V3 3000
On Wed, Dec 13, 2000 at 01:47:17PM -0500, Zephaniah E. Hull wrote: > On Tue, Dec 12, 2000 at 10:39:55PM +0000, Matthew Garrett wrote: > > xserver-xfree86-11 gives corruption on my V3 3000. Black bars run across > > the top of the screen, and moving windows causes corruption. I'm running at > > 1792x1344 using DRI. Dropping back to the xserver-10 package (and keeping > > the -11 ones for everything else) fixed things. Does -11 have a new > > upstream version? > > Errr, it actually WORKS at 1792x1344? *grumble* > > Try it at 1024x768, it may be the same bug, or a different one. Reducing screen resolution while keeping a 1792x1344 virtual doesn't help, but reducing the size of the virtual as well removes the corruption. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: -11 gives graphics corruption with V3 3000
On Wed, Dec 13, 2000 at 01:47:17PM -0500, Zephaniah E. Hull wrote: > On Tue, Dec 12, 2000 at 10:39:55PM +0000, Matthew Garrett wrote: > > xserver-xfree86-11 gives corruption on my V3 3000. Black bars run across > > the top of the screen, and moving windows causes corruption. I'm running at > > 1792x1344 using DRI. Dropping back to the xserver-10 package (and keeping > > the -11 ones for everything else) fixed things. Does -11 have a new > > upstream version? > > Errr, it actually WORKS at 1792x1344? *grumble* Yup, but only at 16bit. Increasing the resolution or trying 24bit gives corruption. > Try it at 1024x768, it may be the same bug, or a different one. Ok, I'll give -11 a shot with lower resolution in the morning. -- Matthew Garrett | [EMAIL PROTECTED]
Re: -11 gives graphics corruption with V3 3000
On Wed, Dec 13, 2000 at 01:47:17PM -0500, Zephaniah E. Hull wrote: > On Tue, Dec 12, 2000 at 10:39:55PM +0000, Matthew Garrett wrote: > > xserver-xfree86-11 gives corruption on my V3 3000. Black bars run across > > the top of the screen, and moving windows causes corruption. I'm running at > > 1792x1344 using DRI. Dropping back to the xserver-10 package (and keeping > > the -11 ones for everything else) fixed things. Does -11 have a new > > upstream version? > > Errr, it actually WORKS at 1792x1344? *grumble* Yup, but only at 16bit. Increasing the resolution or trying 24bit gives corruption. > Try it at 1024x768, it may be the same bug, or a different one. Ok, I'll give -11 a shot with lower resolution in the morning. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
-11 gives graphics corruption with V3 3000
xserver-xfree86-11 gives corruption on my V3 3000. Black bars run across the top of the screen, and moving windows causes corruption. I'm running at 1792x1344 using DRI. Dropping back to the xserver-10 package (and keeping the -11 ones for everything else) fixed things. Does -11 have a new upstream version? -- Matthew Garrett | [EMAIL PROTECTED]
-11 gives graphics corruption with V3 3000
xserver-xfree86-11 gives corruption on my V3 3000. Black bars run across the top of the screen, and moving windows causes corruption. I'm running at 1792x1344 using DRI. Dropping back to the xserver-10 package (and keeping the -11 ones for everything else) fixed things. Does -11 have a new upstream version? -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: 1600x1200 broken with vooodoo3 and NEC FP950
On Fri, Nov 17, 2000 at 03:36:17PM +, Matthew Garrett wrote: > >From what I recall, dri didn't make any difference. I've a feeling that it > may have been dbe that reduced the corruption when removed, but I'll check > that when I'm back with the machine this evening. Right. Removing DRI makes no difference to the graphics corruption. Noaccel also doesn't seem to help. -- Matthew Garrett | [EMAIL PROTECTED]
Re: 1600x1200 broken with vooodoo3 and NEC FP950
On Fri, Nov 17, 2000 at 03:36:17PM +, Matthew Garrett wrote: > >From what I recall, dri didn't make any difference. I've a feeling that it > may have been dbe that reduced the corruption when removed, but I'll check > that when I'm back with the machine this evening. Right. Removing DRI makes no difference to the graphics corruption. Noaccel also doesn't seem to help. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: 1600x1200 broken with vooodoo3 and NEC FP950
On Thu, Nov 16, 2000 at 08:34:10PM -0500, Zephaniah E. Hull wrote: > On Thu, Nov 16, 2000 at 01:06:51PM +0000, Matthew Garrett wrote: > > > Yup. I switched to a V3 because my G100 wasn't capable of going past > > 1800x1400, and managed to gain about an extra 60 pixels of horizontal > > resolution before this bit me. At 16bpp it seems to appear at > > 1872x1404 or higher. > > Gack. Quite :) > I suspect that the only module which makes a difference on this is the > DRI module, could you verify? >From what I recall, dri didn't make any difference. I've a feeling that it may have been dbe that reduced the corruption when removed, but I'll check that when I'm back with the machine this evening. -- Matthew Garrett | [EMAIL PROTECTED]
Re: 1600x1200 broken with vooodoo3 and NEC FP950
On Thu, Nov 16, 2000 at 08:34:10PM -0500, Zephaniah E. Hull wrote: > On Thu, Nov 16, 2000 at 01:06:51PM +0000, Matthew Garrett wrote: > > > Yup. I switched to a V3 because my G100 wasn't capable of going past > > 1800x1400, and managed to gain about an extra 60 pixels of horizontal > > resolution before this bit me. At 16bpp it seems to appear at > > 1872x1404 or higher. > > Gack. Quite :) > I suspect that the only module which makes a difference on this is the > DRI module, could you verify? >From what I recall, dri didn't make any difference. I've a feeling that it may have been dbe that reduced the corruption when removed, but I'll check that when I'm back with the machine this evening. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: 1600x1200 broken with vooodoo3 and NEC FP950
On Thu, Nov 16, 2000 at 12:46:43AM -0500, Branden Robinson wrote: > No, it has to do with the size of the framebuffer, or possibly with the > pixel clock. You get the same problem at 16bpp at absurdly high > resolutions like 1932x1440 or whatever. Yup. I switched to a V3 because my G100 wasn't capable of going past 1800x1400, and managed to gain about an extra 60 pixels of horizontal resolution before this bit me. At 16bpp it seems to appear at 1872x1404 or higher. Disabling all the loadable modules helps somewhat - then the garbage is limited to the top of the screen rather than the entire display being distorted. It happens with the upstream packages as well, so it's not a Debian specific problem. Does XFree have any sort of bug tracking system? I've been assuming that this is a known bug so haven't reported it, but being able to check that would be handy. -- Matthew Garrett | [EMAIL PROTECTED]
Re: 1600x1200 broken with vooodoo3 and NEC FP950
On Thu, Nov 16, 2000 at 12:46:43AM -0500, Branden Robinson wrote: > No, it has to do with the size of the framebuffer, or possibly with the > pixel clock. You get the same problem at 16bpp at absurdly high > resolutions like 1932x1440 or whatever. Yup. I switched to a V3 because my G100 wasn't capable of going past 1800x1400, and managed to gain about an extra 60 pixels of horizontal resolution before this bit me. At 16bpp it seems to appear at 1872x1404 or higher. Disabling all the loadable modules helps somewhat - then the garbage is limited to the top of the screen rather than the entire display being distorted. It happens with the upstream packages as well, so it's not a Debian specific problem. Does XFree have any sort of bug tracking system? I've been assuming that this is a known bug so haven't reported it, but being able to check that would be handy. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: xfree 4.0 crash
On Sun, Nov 05, 2000 at 04:43:56AM -0500, matt wrote: >Voodoo3 Crash- not much to say here because I have no clue why it isnt >working >(II) Module glide: vendor="The XFree86 Project" >compiled for 4.0.1d, module version = 1.0.0 The glide module is for driving old-style Voodoo and Voodoo 2 cards as if they were 2D devices. I've never managed to get it to work with a Voodoo 2, and it certainly shouldn't with a V3. If you have a line calling for the glide driver to be loaded then remove it - the correct one is called tdfx. >(II) Loading /usr/X11R6/lib/modules/libglide2x.so You also probably don't want to have libglide2 installed when you're using XFree 4 with a V3, since anything that tries to use it will lock the entire system if you have DRI set up. -- Matthew Garrett | [EMAIL PROTECTED]
Re: dexter and USB mouse
On Sat, Nov 04, 2000 at 09:21:03PM -0800, Kimball Thurston wrote: >I upgraded to 4.0.1 packages in woody this morning and have had > quite a few problems, but the one I thought I'd ask about is with my > USB mouse (an Intellimouse Explorer). If I choose USB mouse, when I > start X, it gives an unknown protocol error - I had this same problem > with my own compile of XF86 4.0, and could never figure it out... If I > use "ImPS/2", things work just fine... AIUI, USBmouse is effectively useless under Linux. The new input layer allows USB mice to appear as standard PS/2 ones to userspace apps. Incidentally, if ImPS/2 doesn't give you access to all the buttons on the mouse then try netmouseps/2 instead. -- Matthew Garrett | [EMAIL PROTECTED]
Re: xfree 4.0 crash
On Sun, Nov 05, 2000 at 04:43:56AM -0500, matt wrote: >Voodoo3 Crash- not much to say here because I have no clue why it isnt >working >(II) Module glide: vendor="The XFree86 Project" >compiled for 4.0.1d, module version = 1.0.0 The glide module is for driving old-style Voodoo and Voodoo 2 cards as if they were 2D devices. I've never managed to get it to work with a Voodoo 2, and it certainly shouldn't with a V3. If you have a line calling for the glide driver to be loaded then remove it - the correct one is called tdfx. >(II) Loading /usr/X11R6/lib/modules/libglide2x.so You also probably don't want to have libglide2 installed when you're using XFree 4 with a V3, since anything that tries to use it will lock the entire system if you have DRI set up. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dexter and USB mouse
On Sat, Nov 04, 2000 at 09:21:03PM -0800, Kimball Thurston wrote: >I upgraded to 4.0.1 packages in woody this morning and have had > quite a few problems, but the one I thought I'd ask about is with my > USB mouse (an Intellimouse Explorer). If I choose USB mouse, when I > start X, it gives an unknown protocol error - I had this same problem > with my own compile of XF86 4.0, and could never figure it out... If I > use "ImPS/2", things work just fine... AIUI, USBmouse is effectively useless under Linux. The new input layer allows USB mice to appear as standard PS/2 ones to userspace apps. Incidentally, if ImPS/2 doesn't give you access to all the buttons on the mouse then try netmouseps/2 instead. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Voodoo 5 (tdfx) at 24 bpp and dexter
On Thu, Oct 19, 2000 at 11:48:18PM +0100, Matthew Garrett wrote: > I've noticed this here as well. However, I haven't seen it when using the > server from linux.3dfx.com. Scratch that. I've managed to trigger it with both. -- Matthew Garrett | [EMAIL PROTECTED]
Re: Voodoo 5 (tdfx) at 24 bpp and dexter
On Thu, Oct 19, 2000 at 11:48:18PM +0100, Matthew Garrett wrote: > I've noticed this here as well. However, I haven't seen it when using the > server from linux.3dfx.com. Scratch that. I've managed to trigger it with both. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Voodoo 5 (tdfx) at 24 bpp and dexter
On Thu, Oct 19, 2000 at 04:03:39PM -0500, Branden Robinson wrote: > It does support 24 bit color depth if your resolution is low enough. This > appears to be a bug in the tdfx driver. IIRC I had to get down to 1152x864 > before 24-bit would work on my Voodoo3 3000 PCI. IIRC, the DRI support only works in 16 bit colour depth on the Voodoo3 - given that many people are likely to want to use it if they have a tdfx card, defaulting to 16 may be sensible. (end of stuff that's directly related to the debs) > Some combination of high resolution + depth gets things into a confused > state. I get a corrupt screen even at 16-bit depth if I push the card up > to really ridiculous resolutions (1920x1440 or something). I won't > speculate on the possible causes of this so as to avoid sounding like a > complete idiot. I've had the same problem (which is a pain, because I have a nice shiny new monitor that's capable of doing that). I haven't had a chance to find out why, but dropping to 1800x1440ish fixes it. I tried defining my own modelines, but they get deleted due to "Unknown reason" during X startup. I'd assumed that this was just me being an idiot in some way, so seeing someone else with the same problem is reassuring :) > While I'm pestering Daryll in his inbox, there have been widespread reports > (which I can personally confirm) of occasional VGA text font corruption > upon switching away to a console VC from X when using the tdfx driver. > Pieces of glyphs go missing. Perhaps something needs to wait longer before > switching back to text mode? Note that this doesn't happen every single > time (or perhaps it is simply hitting unusual characters that don't happen > to be on the screen), but if you switch back and forth half a dozen times > with something more than getty on the VC, you should be able to see > this. I've noticed this here as well. However, I haven't seen it when using the server from linux.3dfx.com. Once the process has started (by switching to a text console from X), certain characters (mostly punctuation) are damaged and occasional flashing characters appear. Leaving it at the text console with no input gives more characters appearing over time. I've also been having problems with DRI and objects being rendered out of order when rendering to the root window and in some other applications (wine, for instance), while most windowed stuff works fine. This seems to happen with both the XFree and 3DFX drivers, so may be something specific to my setup. I haven't tried the stock XFree tree with this card, so my experiences are limited to the debs and the 3DFX packages. > Please let me know what I can do to help test fixes for these problems, I > have a Voodoo3 3000 PCI here at work and a 2000 PCI at home. This is with a V3 3000 AGP. I'm also happy to try stuff to fix this - I upgraded to the Voodoo because my G100 wouldn't go above 1800x1400 at 60Hz, so I'd quite like to have working higher resolutions :) -- Matthew Garrett | [EMAIL PROTECTED]
Re: Voodoo 5 (tdfx) at 24 bpp and dexter
On Thu, Oct 19, 2000 at 04:03:39PM -0500, Branden Robinson wrote: > It does support 24 bit color depth if your resolution is low enough. This > appears to be a bug in the tdfx driver. IIRC I had to get down to 1152x864 > before 24-bit would work on my Voodoo3 3000 PCI. IIRC, the DRI support only works in 16 bit colour depth on the Voodoo3 - given that many people are likely to want to use it if they have a tdfx card, defaulting to 16 may be sensible. (end of stuff that's directly related to the debs) > Some combination of high resolution + depth gets things into a confused > state. I get a corrupt screen even at 16-bit depth if I push the card up > to really ridiculous resolutions (1920x1440 or something). I won't > speculate on the possible causes of this so as to avoid sounding like a > complete idiot. I've had the same problem (which is a pain, because I have a nice shiny new monitor that's capable of doing that). I haven't had a chance to find out why, but dropping to 1800x1440ish fixes it. I tried defining my own modelines, but they get deleted due to "Unknown reason" during X startup. I'd assumed that this was just me being an idiot in some way, so seeing someone else with the same problem is reassuring :) > While I'm pestering Daryll in his inbox, there have been widespread reports > (which I can personally confirm) of occasional VGA text font corruption > upon switching away to a console VC from X when using the tdfx driver. > Pieces of glyphs go missing. Perhaps something needs to wait longer before > switching back to text mode? Note that this doesn't happen every single > time (or perhaps it is simply hitting unusual characters that don't happen > to be on the screen), but if you switch back and forth half a dozen times > with something more than getty on the VC, you should be able to see > this. I've noticed this here as well. However, I haven't seen it when using the server from linux.3dfx.com. Once the process has started (by switching to a text console from X), certain characters (mostly punctuation) are damaged and occasional flashing characters appear. Leaving it at the text console with no input gives more characters appearing over time. I've also been having problems with DRI and objects being rendered out of order when rendering to the root window and in some other applications (wine, for instance), while most windowed stuff works fine. This seems to happen with both the XFree and 3DFX drivers, so may be something specific to my setup. I haven't tried the stock XFree tree with this card, so my experiences are limited to the debs and the 3DFX packages. > Please let me know what I can do to help test fixes for these problems, I > have a Voodoo3 3000 PCI here at work and a 2000 PCI at home. This is with a V3 3000 AGP. I'm also happy to try stuff to fix this - I upgraded to the Voodoo because my G100 wouldn't go above 1800x1400 at 60Hz, so I'd quite like to have working higher resolutions :) -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dexter and devfs
On Mon, Oct 16, 2000 at 01:38:03AM -0500, Branden Robinson wrote: > If someone gives me some (POSIX) shell scriptage, invoking no commands > that aren't in essential packages, which will decisively determine whether > or not a system is using devfs, I will add support for devfs filenames in > the mouse configuration section. if [ -c /dev/.devfsd ]; then echo "/dev is using devfs" fi is sufficient if you just want to check whether /dev is. -- Matthew Garrett | [EMAIL PROTECTED]
Re: dexter and devfs
On Mon, Oct 16, 2000 at 01:38:03AM -0500, Branden Robinson wrote: > If someone gives me some (POSIX) shell scriptage, invoking no commands > that aren't in essential packages, which will decisively determine whether > or not a system is using devfs, I will add support for devfs filenames in > the mouse configuration section. if [ -c /dev/.devfsd ]; then echo "/dev is using devfs" fi is sufficient if you just want to check whether /dev is. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dexter, phase2v17
On Sat, Oct 14, 2000 at 11:11:13AM -0700, [EMAIL PROTECTED] wrote: > I may set up a second machine just for testing. > So far, the mouse chooser can still use a few more defined devices. The > default mouse type for /dev/gpmdata should be IntelliMouse as far as I > know. What's the default mouse type for USB? is HID mouse all one protocol > according to the mouse driver, or can it autodetect? USB mice (under 2.4) seem to work happily with either ImPS/2 or netmouseps/2. The first only lets me use 3 of the buttons on my Intellimouse Explorer, but netmouseps/2 gets them all working. I can't see any real reason not to make netmouseps/2 the default provided that it works in 2.2 as well. -- Matthew Garrett | [EMAIL PROTECTED]
Re: dexter, phase2v17
On Sat, Oct 14, 2000 at 11:11:13AM -0700, [EMAIL PROTECTED] wrote: > I may set up a second machine just for testing. > So far, the mouse chooser can still use a few more defined devices. The > default mouse type for /dev/gpmdata should be IntelliMouse as far as I > know. What's the default mouse type for USB? is HID mouse all one protocol > according to the mouse driver, or can it autodetect? USB mice (under 2.4) seem to work happily with either ImPS/2 or netmouseps/2. The first only lets me use 3 of the buttons on my Intellimouse Explorer, but netmouseps/2 gets them all working. I can't see any real reason not to make netmouseps/2 the default provided that it works in 2.2 as well. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: G400 DRI?
On Sat, Sep 23, 2000 at 09:27:21AM -0600, Joshua Shagam wrote: > Has anyone built the G400 DRI module against kernel 2.2.17? I don't even > need this for game playing - I need this for my research. 3D graphics > research really sucks on software Mesa. :) Any help would be greatly > appreciated. Or perhaps if I could just get the necessary header files to > build the module myself (I have the kernel source and I can always just > make-kpkg). DRI is, I believe, included in the 2.2.18 prepatches that you can obtain from ftp.kernel.org. I guess the obvious thing to do would be to include the modules in the distributed kernel packages when 2.2.18 proper is released. -- Matthew Garrett | [EMAIL PROTECTED]
Re: G400 DRI?
On Sat, Sep 23, 2000 at 09:27:21AM -0600, Joshua Shagam wrote: > Has anyone built the G400 DRI module against kernel 2.2.17? I don't even > need this for game playing - I need this for my research. 3D graphics > research really sucks on software Mesa. :) Any help would be greatly > appreciated. Or perhaps if I could just get the necessary header files to > build the module myself (I have the kernel source and I can always just > make-kpkg). DRI is, I believe, included in the 2.2.18 prepatches that you can obtain from ftp.kernel.org. I guess the obvious thing to do would be to include the modules in the distributed kernel packages when 2.2.18 proper is released. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
