Jonathan Heaney wrote:
> Am still getting the error message:
> (EE) MGA(0): [drm] MGADRIScreenInit failed (DRI version = 4.0.0,
> expected 3.0.x). Disabling DRI.
>
> Even with the 3.0.2 mga.o module...
The error message isn't about the _DRM_ kernel module but about the X server
_DRI_ module (li
Jonathan Heaney wrote:
> Am still getting the error message:
> (EE) MGA(0): [drm] MGADRIScreenInit failed (DRI version = 4.0.0,
> expected 3.0.x). Disabling DRI.
>
> Even with the 3.0.2 mga.o module...
The error message isn't about the _DRM_ kernel module but about the X server
_DRI_ module (l
Jonathan Heaney <[EMAIL PROTECTED]> writes:
> Even with the 3.0.2 mga.o module...
>
> When X starts I can just catch a line which appears to be telling me
> something about /dev/dri it does not appear in
> /var/log/XFree86.0.log how can I get it to output this to a
> file I can examine
Jonathan Heaney <[EMAIL PROTECTED]> writes:
> Even with the 3.0.2 mga.o module...
>
> When X starts I can just catch a line which appears to be telling me
> something about /dev/dri it does not appear in
> /var/log/XFree86.0.log how can I get it to output this to a
> file I can examine
think they're
Debian GNU/Linux |thinking, they'll love you; but if
[EMAIL PROTECTED] |you really make them think, they'll
http://people.debian.org/~branden/ |hate you.
From: Jonathan Heaney <[EMAIL PROTECTED]>
Subject: X in Sid +G4
t;--
>>G. Branden Robinson|If you make people think they're
>>Debian GNU/Linux |thinking, they'll love you; but if
>>[EMAIL PROTECTED] |you really make them think, they'll
>>http://people.debian.org/~
u make people think they're
> Debian GNU/Linux |thinking, they'll love you; but if
> [EMAIL PROTECTED] |you really make them think, they'll
> http://people.debian.org/~branden/ |hate you.
> From: Jonathan Heaney <[EMA
u make people think they're
> Debian GNU/Linux |thinking, they'll love you; but if
> [EMAIL PROTECTED] |you really make them think, they'll
> http://people.debian.org/~branden/ |hate you.
> From: Jonathan Heaney <[EMA
Can someone help this person out?
I only have access to 3Dfx and ATI cards, and do not experience this
problem.
--
G. Branden Robinson|If you make people think they're
Debian GNU/Linux |thinking, they'll love you; but if
[EMAIL PROTECTED]
Can someone help this person out?
I only have access to 3Dfx and ATI cards, and do not experience this
problem.
--
G. Branden Robinson|If you make people think they're
Debian GNU/Linux |thinking, they'll love you; but if
[EMAIL PROTECTED]
>> "Marcelo E. Magallon" <[EMAIL PROTECTED]> writes:
> > I'm gald it works on your UP athlon, but that doesn't help SMP users. =)
>
> /me schedules a marchine swap for the Radeon...
>
> I'll see if I can get something out. The one SMP system I have access
> to has an evil NVIDIA card
>> "Marcelo E. Magallon" <[EMAIL PROTECTED]> writes:
> > I'm gald it works on your UP athlon, but that doesn't help SMP users. =)
>
> /me schedules a marchine swap for the Radeon...
>
> I'll see if I can get something out. The one SMP system I have access
> to has an evil NVIDIA card
"Terry 'Mongoose' Hendrix II" <[EMAIL PROTECTED]> writes:
> Yes, I don't think it works with SMP chipsets at all as far as I
> know. I don't consider it working when it randomly locks.
It works for me on a Dual PIII/600 BX-based mobo. Admittedly, I'm
only running games and xscreensaver modules, b
"Terry 'Mongoose' Hendrix II" <[EMAIL PROTECTED]> writes:
> Yes, I don't think it works with SMP chipsets at all as far as I
> know. I don't consider it working when it randomly locks.
It works for me on a Dual PIII/600 BX-based mobo. Admittedly, I'm
only running games and xscreensaver modules,
> "Terry" == Terry 'Mongoose' Hendrix <[EMAIL PROTECTED]> writes:
Terry> Juergen Kreileder wrote:
>> However I still get random hangs with Q3A and deterministic
>> hangs with any windowed GL application when the window gets un-
>> and then remapped (e.g. when iconifying/deiconi
> "Terry" == Terry 'Mongoose' Hendrix <[EMAIL PROTECTED]> writes:
Terry> Juergen Kreileder wrote:
>> However I still get random hangs with Q3A and deterministic
>> hangs with any windowed GL application when the window gets un-
>> and then remapped (e.g. when iconifying/deicon
>> Terry 'Mongoose' Hendrix II <[EMAIL PROTECTED]> writes:
> > "UP systems"? I can't make that one out.
>
> UniProcessor
doh.
> I'm gald it works on your UP athlon, but that doesn't help SMP users. =)
/me schedules a marchine swap for the Radeon...
I'll see if I can get something out.
Marcelo E. Magallon wrote:
"UP systems"? I can't make that one out.
UniProcessor
DRI + G400 works for me on an Athlon system (Irongate north bridge). I
do have multiple contexts at the same time and I have never had any
lock up that seems directly related to that (and I do hammer the
>> Terry 'Mongoose' Hendrix II <[EMAIL PROTECTED]> writes:
> I think the only people it "works for" are just playing games or are
> on UP systems. I haven't found anyone yet that can run a
> multicontext and/or windowed GL application yet on MGA DRI. Thanks
> for your input, as I'm tracking
>> Terry 'Mongoose' Hendrix II <[EMAIL PROTECTED]> writes:
> > "UP systems"? I can't make that one out.
>
> UniProcessor
doh.
> I'm gald it works on your UP athlon, but that doesn't help SMP users. =)
/me schedules a marchine swap for the Radeon...
I'll see if I can get something out
Marcelo E. Magallon wrote:
>
> "UP systems"? I can't make that one out.
UniProcessor
> DRI + G400 works for me on an Athlon system (Irongate north bridge). I
> do have multiple contexts at the same time and I have never had any
> lock up that seems directly related to that (and I do hamme
Juergen Kreileder wrote:
However I still get random hangs with Q3A and deterministic hangs
with any windowed GL application when the window gets un- and then
remapped (e.g. when iconifying/deiconifying windows, or when switching
between workspaces).
I don't consider that working. I write wind
>> Terry 'Mongoose' Hendrix II <[EMAIL PROTECTED]> writes:
> I think the only people it "works for" are just playing games or are
> on UP systems. I haven't found anyone yet that can run a
> multicontext and/or windowed GL application yet on MGA DRI. Thanks
> for your input, as I'm tracking
Juergen Kreileder wrote:
>
> However I still get random hangs with Q3A and deterministic hangs
> with any windowed GL application when the window gets un- and then
> remapped (e.g. when iconifying/deiconifying windows, or when switching
> between workspaces).
I don't consider that working. I wri
>>>>> "Terry" == Terry 'Mongoose' Hendrix <[EMAIL PROTECTED]> writes:
Terry> Anyone get MGA ( G400 ) DRI working on an SMP box?
Terry> Everytime I tried it it locks the machine.
I and some others had this problem on Dell Precision worksta
>>>>> "Terry" == Terry 'Mongoose' Hendrix <[EMAIL PROTECTED]> writes:
Terry> Anyone get MGA ( G400 ) DRI working on an SMP box?
Terry> Everytime I tried it it locks the machine.
I and some others had this problem on Dell Precision worksta
Anyone get MGA ( G400 ) DRI working on an SMP box? Everytime I tried it
it locks the machine.
- Btw I'm using 3.3.6 and utah agian - but left debian 4.0.2 incase I
want to lock up my box one day I guess. =)
cheers,
Terry
--
---
| Goo
Anyone get MGA ( G400 ) DRI working on an SMP box? Everytime I tried it
it locks the machine.
- Btw I'm using 3.3.6 and utah agian - but left debian 4.0.2 incase I
want to lock up my box one day I guess. =)
cheers,
Terry
--
---
| Goo
It seems that the problem in the G400 texturing bug is fixed in the current
CVS version of XFree 4 DRI. I went and downloaded the CVS source tree last
night (modems have enough bandwidth when you're not sitting there waiting
:) and built the server myself... it seems that there's a bug in the
rela
It seems that the problem in the G400 texturing bug is fixed in the current
CVS version of XFree 4 DRI. I went and downloaded the CVS source tree last
night (modems have enough bandwidth when you're not sitting there waiting
:) and built the server myself... it seems that there's a bug in the
rel
hing bad in the
> > Debian build anyway. Basically, texturing on the G400 DRI driver is
> > completely borked up in that it seems that texture coordinates aren't
> > getting to the card properly. I have some screenshots comparing the G400
> > driver with software
hing bad in the
> > Debian build anyway. Basically, texturing on the G400 DRI driver is
> > completely borked up in that it seems that texture coordinates aren't
> > getting to the card properly. I have some screenshots comparing the G400
> > driver with software
On Wed, Dec 06, 2000 at 01:21:15PM -0700, Joshua Shagam wrote:
>
> I've completely lost track of where DRI bugs should go, but this seems
> like the kind of thing which might just be due to something bad in the
> Debian build anyway. Basically, texturing on the G400 DRI drive
On Wed, Dec 06, 2000 at 01:21:15PM -0700, Joshua Shagam wrote:
>
> I've completely lost track of where DRI bugs should go, but this seems
> like the kind of thing which might just be due to something bad in the
> Debian build anyway. Basically, texturing on the G400 DRI drive
* Joshua Shagam <[EMAIL PROTECTED]> [001206 15:39]:
> Basically, vertices which are a certain distance from the camera and are
> within the clipping planes seem to get their texture coordinates shoved to
> 0,0. As the camera moves around the broken texture coordinates change
> quite a bit.
Well,
I've completely lost track of where DRI bugs should go, but this seems like
the kind of thing which might just be due to something bad in the Debian
build anyway. Basically, texturing on the G400 DRI driver is completely
borked up in that it seems that texture coordinates aren't gett
* Joshua Shagam <[EMAIL PROTECTED]> [001206 15:39]:
> Basically, vertices which are a certain distance from the camera and are
> within the clipping planes seem to get their texture coordinates shoved to
> 0,0. As the camera moves around the broken texture coordinates change
> quite a bit.
Well,
I've completely lost track of where DRI bugs should go, but this seems like
the kind of thing which might just be due to something bad in the Debian
build anyway. Basically, texturing on the G400 DRI driver is completely
borked up in that it seems that texture coordinates aren't gett
On Thu, Nov 02, 2000 at 08:19:11PM -0800, Seth Arnold wrote:
> I am running Linux Kernel 2.4.0-test7 (mainly since I have heard
> problems of DRM v1 / v2 problems with test9).
Have yuo tried 2.4.0-test10? DRI was broken in test9 and test8 (or wasn't
compatible with newest X4-debs). With test10 a
On Thu, Nov 02, 2000 at 08:19:11PM -0800, Seth Arnold wrote:
> I am running Linux Kernel 2.4.0-test7 (mainly since I have heard
> problems of DRM v1 / v2 problems with test9).
Have yuo tried 2.4.0-test10? DRI was broken in test9 and test8 (or wasn't
compatible with newest X4-debs). With test10
Ok, resolution time -- once this thing hits the ftp servers, people will
want to know how to use it. So, everyone take note, it took me for
fscking ever to figure out what was wrong. and if this saves you two
minutes, go give someone a kiss or something. hehe.
I WAS MISSING MY AGPGART DEVICE.
Ok, resolution time -- once this thing hits the ftp servers, people will
want to know how to use it. So, everyone take note, it took me for
fscking ever to figure out what was wrong. and if this saves you two
minutes, go give someone a kiss or something. hehe.
I WAS MISSING MY AGPGART DEVICE.
Greetings everyone. I broke my G400's DRI. I honestly don't recall
changing anything, but once upon a time it worked, and now it does not.
The error I keep getting is rather simple:
$ glxinfo
X Error of failed request: 80
Major opcode of failed request: 0 ()
Serial number of failed request:
Greetings everyone. I broke my G400's DRI. I honestly don't recall
changing anything, but once upon a time it worked, and now it does not.
The error I keep getting is rather simple:
$ glxinfo
X Error of failed request: 80
Major opcode of failed request: 0 ()
Serial number of failed request
On Mon, Sep 25, 2000 at 09:24:26PM -0500, Branden Robinson wrote:
>
> Well, XFree86 CVS just resynced with the DRI at sourceforge, the Mesa
> version is now 3.4, etc. etc. Maybe try a bleeding edge kernel?
That worked, but I also had to get rid of the binary driver from Matrox.
Although the chang
On Mon, Sep 25, 2000 at 09:24:26PM -0500, Branden Robinson wrote:
>
> Well, XFree86 CVS just resynced with the DRI at sourceforge, the Mesa
> version is now 3.4, etc. etc. Maybe try a bleeding edge kernel?
That worked, but I also had to get rid of the binary driver from Matrox.
Although the chan
On Mon, Sep 25, 2000 at 09:24:26PM -0500, Branden Robinson wrote:
>
>> First, I looked at the logged output from X. There was a conflict
>> between drm 1.0 and 2.0 or something like that, and the next statement
>> was "dri disabled". Shucks.
> [...]
>> Any ideas?
In the snipped-out part of the q
On Mon, Sep 25, 2000 at 04:51:59PM -0500, Thomas E. Vaughan wrote:
> First, I looked at the logged output from X. There was a conflict between
> drm 1.0 and 2.0 or something like that, and the next statement was "dri
> disabled". Shucks.
[...]
> Any ideas?
Well, XFree86 CVS just resynced with th
On Mon, Sep 25, 2000 at 09:24:26PM -0500, Branden Robinson wrote:
>
>> First, I looked at the logged output from X. There was a conflict
>> between drm 1.0 and 2.0 or something like that, and the next statement
>> was "dri disabled". Shucks.
> [...]
>> Any ideas?
In the snipped-out part of the
On Mon, Sep 25, 2000 at 04:51:59PM -0500, Thomas E. Vaughan wrote:
> First, I looked at the logged output from X. There was a conflict between
> drm 1.0 and 2.0 or something like that, and the next statement was "dri
> disabled". Shucks.
[...]
> Any ideas?
Well, XFree86 CVS just resynced with t
When I left work last Friday, everything was working well with phase2v8.
My G400 was providing nice, hardware-accelerated textures, and I was happy.
Today, however, I upgraded to phase2v10, and I was immediately disappointed
to find out that I no longer get hardware acceleration for OpenGL apps.
When I left work last Friday, everything was working well with phase2v8.
My G400 was providing nice, hardware-accelerated textures, and I was happy.
Today, however, I upgraded to phase2v10, and I was immediately disappointed
to find out that I no longer get hardware acceleration for OpenGL apps.
On Sun, Sep 24, 2000 at 11:33:24AM +0200, Marcelo E. Magallon wrote:
> >> Joshua Shagam <[EMAIL PROTECTED]> writes:
>
> > And wouldn't the DRM modules in the kernel source be both
> > quickly-outdated with respect to the actual drivers? I tend to
> > need the bleeding-edge features of the 3D d
On Sun, Sep 24, 2000 at 11:33:24AM +0200, Marcelo E. Magallon wrote:
> >> Joshua Shagam <[EMAIL PROTECTED]> writes:
>
> > And wouldn't the DRM modules in the kernel source be both
> > quickly-outdated with respect to the actual drivers? I tend to
> > need the bleeding-edge features of the 3D
>> Joshua Shagam <[EMAIL PROTECTED]> writes:
> And wouldn't the DRM modules in the kernel source be both
> quickly-outdated with respect to the actual drivers? I tend to
> need the bleeding-edge features of the 3D drivers (for me, 'Quake 3
> working' isn't good enough).
Hmm... I know the fe
>> Joshua Shagam <[EMAIL PROTECTED]> writes:
> And wouldn't the DRM modules in the kernel source be both
> quickly-outdated with respect to the actual drivers? I tend to
> need the bleeding-edge features of the 3D drivers (for me, 'Quake 3
> working' isn't good enough).
Hmm... I know the f
On Sun, Sep 24, 2000 at 01:12:48AM +0200, Marcelo E. Magallon wrote:
> >> Joshua Shagam <[EMAIL PROTECTED]> writes:
>
> > Okay, since posting my original message, I've found out (with
> > Marcelo Magallon's help) that I need to get a DRI driver which
> > matches interfaces with the XFree server
On Sun, Sep 24, 2000 at 01:12:48AM +0200, Marcelo E. Magallon wrote:
> >> Joshua Shagam <[EMAIL PROTECTED]> writes:
>
> > Okay, since posting my original message, I've found out (with
> > Marcelo Magallon's help) that I need to get a DRI driver which
> > matches interfaces with the XFree serve
>> Joshua Shagam <[EMAIL PROTECTED]> writes:
> Okay, since posting my original message, I've found out (with
> Marcelo Magallon's help) that I need to get a DRI driver which
> matches interfaces with the XFree server. As far as I can tell,
> the current Matrox driver (which is based on PI's C
Okay, since posting my original message, I've found out (with Marcelo
Magallon's help) that I need to get a DRI driver which matches interfaces
with the XFree server. As far as I can tell, the current Matrox driver
(which is based on PI's CVS-current driver) uses the 2.0.0 interface,
whereas the
>> Joshua Shagam <[EMAIL PROTECTED]> writes:
> Okay, since posting my original message, I've found out (with
> Marcelo Magallon's help) that I need to get a DRI driver which
> matches interfaces with the XFree server. As far as I can tell,
> the current Matrox driver (which is based on PI's
* [EMAIL PROTECTED] <[EMAIL PROTECTED]> [000923 13:20]:
> Where did you get the Matrox binary drivers? There is only source in the
> Matrox
> homepage, but binaries are mentioned in the README. I don't want to compile
> the
> whole Xfree-sources ;)
It took me a lot of searching on their webpage
On Sat, 23 Sep 2000 22:45:41 Seth Arnold wrote:
> Joshua, first, let me make it clear I am far from knowledgeable about
> this subject. :)
>
> I am pretty sure I didn't do much special to get DRI working on my g400
> max. I am running branden's .debs, the matrox driver, and kernel
> 2.4.0-test7.
turns out, they only distribute a binary
> version of the 2D driver (which makes sense, given the DRI's kernel module
> nature). The DRI driver is only in source. But I don't want to download
> 50 megs of XFree86 source on my 28.8 modem. :)
>
> Has anyone built the G400 DR
Okay, since posting my original message, I've found out (with Marcelo
Magallon's help) that I need to get a DRI driver which matches interfaces
with the XFree server. As far as I can tell, the current Matrox driver
(which is based on PI's CVS-current driver) uses the 2.0.0 interface,
whereas the
* [EMAIL PROTECTED] <[EMAIL PROTECTED]> [000923 13:20]:
> Where did you get the Matrox binary drivers? There is only source in the Matrox
> homepage, but binaries are mentioned in the README. I don't want to compile the
> whole Xfree-sources ;)
It took me a lot of searching on their webpage to fi
On Sat, 23 Sep 2000 22:45:41 Seth Arnold wrote:
> Joshua, first, let me make it clear I am far from knowledgeable about
> this subject. :)
>
> I am pretty sure I didn't do much special to get DRI working on my g400
> max. I am running branden's .debs, the matrox driver, and kernel
> 2.4.0-test7.
turns out, they only distribute a binary
> version of the 2D driver (which makes sense, given the DRI's kernel module
> nature). The DRI driver is only in source. But I don't want to download
> 50 megs of XFree86 source on my 28.8 modem. :)
>
> Has anyone built the G400 DR
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
ry
version of the 2D driver (which makes sense, given the DRI's kernel module
nature). The DRI driver is only in source. But I don't want to download
50 megs of XFree86 source on my 28.8 modem. :)
Has anyone built the G400 DRI module against kernel 2.2.17? I don't even
need this fo
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 wo
ry
version of the 2D driver (which makes sense, given the DRI's kernel module
nature). The DRI driver is only in source. But I don't want to download
50 megs of XFree86 source on my 28.8 modem. :)
Has anyone built the G400 DRI module against kernel 2.2.17? I don't even
need this fo
72 matches
Mail list logo
