> This is probably related to the missing xdm-authorization code in the
> DRI built XFree86 server. Not sure though, I think it's usually only a
> problem with kdm, which tries to use xdm-auth even if it's not available
> per default (changeable in the config file). But maybe your xdm is
> conf
Cedric Cellier wrote:
DRI compiled and installed cleanly.
The bug goes away !
Many thanks !
(Note : BTW, now xdm start in B&W mode, and refuses to launch X11 - I
had to install another login manager :-/ )
This is probably related to the missing xdm-authorization code in the
DRI built XFree86 serv
DRI compiled and installed cleanly.
The bug goes away !
Many thanks !
(Note : BTW, now xdm start in B&W mode, and refuses to launch X11 - I
had to install another login manager :-/ )
---
This SF.Net email is sponsored by Sleepycat Software
Le
Im trying right now.
---
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?
Cedric Cellier wrote:
Sorry I should have told :
The driver used by X11 is r200, from the debian package (Sarge),
wich is numbered 4.3.0-7
Sorry, should have mentioned it too, I'm running dri cvs (from some days
ago). So this may be a bug which is already fixed, 4.3.0 is OLD as far
as the dri dri
Sorry I should have told :
The driver used by X11 is r200, from the debian package (Sarge),
wich is numbered 4.3.0-7
---
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to
Cedric Cellier wrote:
Hi list !
If a post something that have been reported many times, Im sorry.
But I searched to google and to this ML's archive and didn't find
anything close to what I got.
Ive coded a little game (ensemblist, hosted at savannah), and I just
realized that the game does not wor
Hi list !
If a post something that have been reported many times, Im sorry.
But I searched to google and to this ML's archive and didn't find
anything close to what I got.
Ive coded a little game (ensemblist, hosted at savannah), and I just
realized that the game does not work on my new laptop (d
--- Tom Vier <[EMAIL PROTECTED]> wrote:
> i finally got dri working, but... i'm using 2.6.5 on x86 (dual
> opteron
> mobo with a single cpu). i have an agp 9200 and i'm using xfree
> 4.3.0.
> whenever i scroll or sometimes when inputing text, i get these white
> horizontal lines that appear in ran
i finally got dri working, but... i'm using 2.6.5 on x86 (dual opteron
mobo with a single cpu). i have an agp 9200 and i'm using xfree 4.3.0.
whenever i scroll or sometimes when inputing text, i get these white
horizontal lines that appear in random spots for a split second. this
happens in the gim
I tried to merge the r200 patch to the radeon driver.
Here is a snapshot.
(hopefully I didn't miss something while sorting out the r200 stuff from the diff.)
I tested:
glxgears works, quake3 works, ut2004demo works (at least to a certain extend)
progs/tests/projtex doesn't work as it should, yuvr
revert libdri.a to the version from your distro.
Alex
--- Matthew Adams <[EMAIL PROTECTED]> wrote:
> Hello. I'm using a Radeon IGP320m. Kernel version 2.6.5, XFree86
> version
> 4.4.0, Dri snapshot 20040408. This is the output i recieve from
> programs
> that run with dri. Any help would be gre
Hello. I'm using a Radeon IGP320m. Kernel version 2.6.5, XFree86 version
4.4.0, Dri snapshot 20040408. This is the output i recieve from programs
that run with dri. Any help would be great. If I use
20040205 DRI works fine, slow but fine. I've tried the last 20 releases, all
seem to be broken.
Hello. I'm using a Radeon IGP320m. Kernel version 2.6.5, XFree86 version
4.4.0, Dri snapshot 20040408. This is the output i recieve from programs
that run with dri. Any help would be great. If I use
20040205 DRI works fine, slow but fine. I've tried the last 20 releases, all
seem to be broken.
I have seen this also on my laptop(mach64) and my desktop(radeon). It
just started happining recently.
--- Daniele Boffi <[EMAIL PROTECTED]> wrote:
> At the beginning I thought is was a hardware problem, even if it started
> immediately after I upgraded to CVS radeon driver. But then, I noticed
>
At the beginning I thought is was a hardware problem, even if it started
immediately after I upgraded to CVS radeon driver. But then, I noticed that the
problem I am describing below doesn't show up in text mode (vt 1-6), so it must
be related with X.
The (pretty annoying) problem is the following
On Sat, 2004-03-06 at 21:38, Andreas Stenglein wrote:
>
> I thought someone would do the conversion of the radeon/r200 driver
> from the t_dd_vbtmp.h template code to "t_vertex" [...]
I don't remember anyone saying they'd do it. Do you want to go for it?
:)
--
Earthling Michel DÃnzer |
Am 2004.03.06 14:59:14 +0100 schrieb(en) Jaakko Niemi:
> On Sat, 03 Jan 2004, Andreas Stenglein wrote:
> > here is what I fiddled together to support the 3rd TMU on radeon
> > and 6TMUs on r200.
> >
> > I tried on R200 with multiarb.c and projtex.c and it works almost as it should.
> > (projtex is
On Sat, 03 Jan 2004, Andreas Stenglein wrote:
> here is what I fiddled together to support the 3rd TMU on radeon
> and 6TMUs on r200.
>
> I tried on R200 with multiarb.c and projtex.c and it works almost as it should.
> (projtex is broken somehow on r200, even with only 2 TMUs)
>
> ut2003_demo wo
Keith Whitwell wrote:
Alan Hourihane wrote:
What I'd really like to be able to do now is build the dri drivers
directly out of the Mesa tree.
Definately. Slate that up for 6.1, I'll certainly work on that issue.
It's not too hard - I had it working on the embedded branch a while ago.
In gen
Otto Solares wrote:
On Tue, Jan 27, 2004 at 08:41:45PM +, Keith Whitwell wrote:
What I'd really like to be able to do now is build the dri drivers directly
out of the Mesa tree.
Does this means that finally we will see XFree and linux-solo build
it's drivers from Mesa-newtree/src/drivers/dr
On Tue, Jan 27, 2004 at 09:44:31PM -0600, Otto Solares wrote:
> On Tue, Jan 27, 2004 at 08:41:45PM +, Keith Whitwell wrote:
> > What I'd really like to be able to do now is build the dri drivers directly
> > out of the Mesa tree.
>
> Does this means that finally we will see XFree and linux-so
On Tue, Jan 27, 2004 at 08:41:45PM +, Keith Whitwell wrote:
> What I'd really like to be able to do now is build the dri drivers directly
> out of the Mesa tree.
Does this means that finally we will see XFree and linux-solo build
it's drivers from Mesa-newtree/src/drivers/dri or this is not t
On Wed, 2004-01-28 at 00:28, Alan Hourihane wrote:
> On Wed, Jan 28, 2004 at 12:25:23AM +0100, Michel DÃnzer wrote:
> >
> > What about a branch corresponding to the Mesa stable branch though?
> > Then David could grab that for XFree86.
>
> It's currently mesa_6_0_branch.
Yes, I mean a corresp
On Wed, Jan 28, 2004 at 12:25:23AM +0100, Michel Dänzer wrote:
> On Tue, 2004-01-27 at 21:41, Keith Whitwell wrote:
> > Alan Hourihane wrote:
> > >
> > > Do we want to bring Mesa 6.0's branch into the DRI repository now or
> > > stick with the way we have it currently ?
> > >
> > > I guess if we
On Tue, 2004-01-27 at 21:41, Keith Whitwell wrote:
> Alan Hourihane wrote:
> >
> > Do we want to bring Mesa 6.0's branch into the DRI repository now or
> > stick with the way we have it currently ?
> >
> > I guess if we stick with the way it is now, then most developers will
> > track Mesa's trun
On Tue, Jan 27, 2004 at 01:17:20PM -0800, Alex Deucher wrote:
>
> --- Alan Hourihane <[EMAIL PROTECTED]> wrote:
> > On Tue, Jan 27, 2004 at 07:38:59PM +, Keith Whitwell wrote:
> > > This is a good time to remind people/establish the principle that
> > driver
> > > bug fixes should be propogat
On Tue, Jan 27, 2004 at 07:52:32PM +, Alan Hourihane wrote:
>On Tue, Jan 27, 2004 at 02:21:42PM -0500, David Dawes wrote:
>> On Tue, Jan 27, 2004 at 06:45:10PM +, Alan Hourihane wrote:
>> >On Tue, Jan 27, 2004 at 12:37:51PM -0500, David Dawes wrote:
>> >> There are quite a few Radeon-relate
--- Alan Hourihane <[EMAIL PROTECTED]> wrote:
> On Tue, Jan 27, 2004 at 07:38:59PM +, Keith Whitwell wrote:
> > This is a good time to remind people/establish the principle that
> driver
> > bug fixes should be propogated to the mesa-6_0_branch of the Mesa
> > repository. Brian's always done
Alan Hourihane wrote:
What I'd really like to be able to do now is build the dri drivers directly
out of the Mesa tree.
Definately. Slate that up for 6.1, I'll certainly work on that issue.
It's not too hard - I had it working on the embedded branch a while ago.
In general, the Mesa make syst
On Tue, Jan 27, 2004 at 08:41:45PM +, Keith Whitwell wrote:
> Alan Hourihane wrote:
> >On Tue, Jan 27, 2004 at 07:38:59PM +, Keith Whitwell wrote:
> >
> >>This is a good time to remind people/establish the principle that driver
> >>bug fixes should be propogated to the mesa-6_0_branch of t
Alan Hourihane wrote:
On Tue, Jan 27, 2004 at 07:38:59PM +, Keith Whitwell wrote:
This is a good time to remind people/establish the principle that driver
bug fixes should be propogated to the mesa-6_0_branch of the Mesa
repository. Brian's always done a good job of making sure core mesa fix
On Tue, Jan 27, 2004 at 07:38:59PM +, Keith Whitwell wrote:
> This is a good time to remind people/establish the principle that driver
> bug fixes should be propogated to the mesa-6_0_branch of the Mesa
> repository. Brian's always done a good job of making sure core mesa fixes
> get copied
On Tue, Jan 27, 2004 at 02:21:42PM -0500, David Dawes wrote:
> On Tue, Jan 27, 2004 at 06:45:10PM +, Alan Hourihane wrote:
> >On Tue, Jan 27, 2004 at 12:37:51PM -0500, David Dawes wrote:
> >> There are quite a few Radeon-related bugs still outstanding in
> >> bugs.xfree86.org, including several
David Dawes wrote:
On Tue, Jan 27, 2004 at 06:45:10PM +, Alan Hourihane wrote:
On Tue, Jan 27, 2004 at 12:37:51PM -0500, David Dawes wrote:
There are quite a few Radeon-related bugs still outstanding in
bugs.xfree86.org, including several related to DRI lockups.
Has anyone followed them up?
D
On Tue, Jan 27, 2004 at 06:45:10PM +, Alan Hourihane wrote:
>On Tue, Jan 27, 2004 at 12:37:51PM -0500, David Dawes wrote:
>> There are quite a few Radeon-related bugs still outstanding in
>> bugs.xfree86.org, including several related to DRI lockups.
>>
>> Has anyone followed them up?
>
>David
On Tue, Jan 27, 2004 at 12:37:51PM -0500, David Dawes wrote:
> There are quite a few Radeon-related bugs still outstanding in
> bugs.xfree86.org, including several related to DRI lockups.
>
> Has anyone followed them up?
David,
I suspect not with XFree86's DRI drivers still being based on Mesa 4
There are quite a few Radeon-related bugs still outstanding in
bugs.xfree86.org, including several related to DRI lockups.
Has anyone followed them up?
David
--
David Dawes
developer/release engineer The XFree86 Project
www.XFree86.org/~dawes
--
Am Sonntag, 04. Januar 2004 14:50 schrieb Andreas Stenglein:
> Am 2004.01.03 16:22:54 +0100 schrieb(en) Felix Kühling:
> [...]
>
> > I just added a short HOWTO to the Wiki:
> > http://dri.sourceforge.net/cgi-bin/moin.cgi/ConfigurationForDevelopers.
> > Let me know if you find any problems with the
I check the mailing-list archive regularly, and noticed the Radeon/R200 TMU
increase patch. It looks like it does not touch the radeon files? Does the
web-based archive cutoff messages after a certain length, or was that all
there is...(not touching radeon_context.c etc..).
If someone has the
Felix Kühling wrote:
A patch is attached. The order in which state atoms are emitted now is
pretty arbitrary. It may be worth finding out exactly which permutations
of state changes trigger the lockup. In the interest of security we
could detect them in the DRM driver and emit a 3D idle to prevent
Keith Whitwell wrote:
Keith Whitwell wrote:
Andreas Stenglein wrote:
here is what I fiddled together to support the 3rd TMU on radeon
and 6TMUs on r200.
I tried on R200 with multiarb.c and projtex.c and it works almost as
it should.
(projtex is broken somehow on r200, even with only 2 TMUs)
Th
Am Sonntag, 04. Januar 2004 14:50 schrieb Andreas Stenglein:
> Am 2004.01.03 16:22:54 +0100 schrieb(en) Felix Kühling:
> [...]
>
> > I just added a short HOWTO to the Wiki:
> > http://dri.sourceforge.net/cgi-bin/moin.cgi/ConfigurationForDevelopers.
> > Let me know if you find any problems with the
Keith Whitwell wrote:
Andreas Stenglein wrote:
here is what I fiddled together to support the 3rd TMU on radeon
and 6TMUs on r200.
I tried on R200 with multiarb.c and projtex.c and it works almost as
it should.
(projtex is broken somehow on r200, even with only 2 TMUs)
The patches look ok. I'v
Andreas Stenglein wrote:
here is what I fiddled together to support the 3rd TMU on radeon
and 6TMUs on r200.
I tried on R200 with multiarb.c and projtex.c and it works almost as it should.
(projtex is broken somehow on r200, even with only 2 TMUs)
The patches look ok. I've actually been working on
On Sun, 4 Jan 2004 19:30:45 +0100
Dieter Nützel <[EMAIL PROTECTED]> wrote:
> Am Samstag, 03. Januar 2004 04:52 schrieb Felix Kühling:
> > Hi,
> >
> > this is referring to the a very reproducable lockup that occurred with
> > glaxium on r100 hardware. Several months ago I tracked it down to
> > emi
Am Samstag, 03. Januar 2004 04:52 schrieb Felix Kühling:
> Hi,
>
> this is referring to the a very reproducable lockup that occurred with
> glaxium on r100 hardware. Several months ago I tracked it down to
> emission of state changes and introduced a workaround that waits for 3D
> idle before state
Felix Kühling wrote:
Hi,
this is referring to the a very reproducable lockup that occurred with
glaxium on r100 hardware. Several months ago I tracked it down to
emission of state changes and introduced a workaround that waits for 3D
idle before state changes. Now I had a new idea about a possible
I forgot to mention on thing in the Wiki (correcting now). You need to
increase the value of __driNConfigOptions accordingly if you add new
options. You should have seen an error message as a reminder though. ;-)
Thanks for these patches. I hope they'll be committed soon.
Felix
P.S.: The driconf
On Sun, 4 Jan 2004 14:50:34 +0100
Andreas Stenglein <[EMAIL PROTECTED]> wrote:
> Am 2004.01.03 16:22:54 +0100 schrieb(en) Felix Kühling:
> [...]
> >
> > I just added a short HOWTO to the Wiki:
> > http://dri.sourceforge.net/cgi-bin/moin.cgi/ConfigurationForDevelopers.
> > Let me know if you find
Am 2004.01.03 16:22:54 +0100 schrieb(en) Felix Kühling:
[...]
>
> I just added a short HOWTO to the Wiki:
> http://dri.sourceforge.net/cgi-bin/moin.cgi/ConfigurationForDevelopers.
> Let me know if you find any problems with the config code or the HOWTO.
thanks a lot!
>
> I'm going to try your pa
On Fri, 2004-01-02 at 23:30, Andreas Stenglein wrote:
> here is what I fiddled together to support the 3rd TMU on radeon
> and 6TMUs on r200.
>
> I tried on R200 with multiarb.c and projtex.c and it works almost as it should.
> (projtex is broken somehow on r200, even with only 2 TMUs)
>
> ut2003
On Sat, 3 Jan 2004 00:30:35 +0100
Andreas Stenglein <[EMAIL PROTECTED]> wrote:
> here is what I fiddled together to support the 3rd TMU on radeon
> and 6TMUs on r200.
>
> I tried on R200 with multiarb.c and projtex.c and it works almost as it should.
> (projtex is broken somehow on r200, even wit
Hi,
this is referring to the a very reproducable lockup that occurred with
glaxium on r100 hardware. Several months ago I tracked it down to
emission of state changes and introduced a workaround that waits for 3D
idle before state changes. Now I had a new idea about a possible cause
of trouble: th
I managed to get the vtxfmt path enabled and fixed a small problem that
didn't show up when vtxfmt wasn't enabled. Flightgear performance
increased only marginally since it draws most of its geometry using
vertex arrays which is a vtxfmt fallback. I was able improve the
situation by not installing
On Wed, 31 Dec 2003 00:00:17 +0100
Jacek Pop <[EMAIL PROTECTED]> wrote:
> On Tue, Dec 30, 2003 at 09:38:21PM +0100, Felix Kühling wrote:
> > And I found out that apperently the entire vtxfmt code path is not working.
>
> Was it working before "newmesa"?
I'm not sure. Looking at an old config-0-
On Tue, Dec 30, 2003 at 09:38:21PM +0100, Felix Kühling wrote:
> And I found out that apperently the entire vtxfmt code path is not working.
Was it working before "newmesa"?
--
Free Software - find interesting programs and change them
NetHack - meet interesting creatures, kill them and eat thei
Hi,
I was wondering why flightgear was so slow so I did some profiling and
debugging. And I found out that apperently the entire vtxfmt code path
is not working. I believe the root cause is that radeonNotifyBegin is
never called with current Mesa. So the driver's own vtxfmt functions are
never ins
> Am Dienstag, 09. Dezember 2003 02:22 schrieb Michel Dänzer:
>> On Fri, 2003-12-05 at 00:24, [EMAIL PROTECTED] wrote:
>> > I am trying to get a Radeon 9000 pro to work using the latest DRI
>> CVS tree, but encountering a few problems.
>> >
>> > The system in question is a pair of opterons runnin
Am Dienstag, 09. Dezember 2003 02:22 schrieb Michel DÃnzer:
> On Fri, 2003-12-05 at 00:24, [EMAIL PROTECTED] wrote:
> > I am trying to get a Radeon 9000 pro to work using the latest DRI CVS
> > tree, but encountering a few problems.
> >
> > The system in question is a pair of opterons running on a
On Fri, 2003-12-05 at 00:24, [EMAIL PROTECTED] wrote:
>
> I am trying to get a Radeon 9000 pro to work using the latest DRI CVS
> tree, but encountering a few problems.
>
> The system in question is a pair of opterons running on a Tyan S2885
> board, with Suse 9.0 Professional (AMD64) installed
Hello,
I am trying to get a Radeon 9000 pro to work using the latest DRI CVS
tree, but encountering a few problems.
The system in question is a pair of opterons running on a Tyan S2885
board, with Suse 9.0 Professional (AMD64) installed and the latest
2.4.21-149 kernel.
I get the same results wh
Your best bet, if you can find one, is a fireGL 8800. It's basically
an overclocked 8500. barring that the 8500's and 9100's are the next
fastest.
Alex
--- Torgeir Veimo <[EMAIL PROTECTED]> wrote:
> On Fri, 2003-11-28 at 07:37, Alex Deucher wrote:
> > I'd say the best supported cards are r200
On Fri, 2003-11-28 at 22:36, Chris Ison wrote:
> > >>I'd say the best supported cards are r200 based radeons (8500 to 9200 cards).
> > >>
> well thats just great, I was hopeing to see something different other
> than r200 as I have had nothing but trouble and poor performance with
> them with D
On Fri, 2003-11-28 at 08:49, David Bronaugh wrote:
> Torgeir Veimo wrote:
>
> >On Fri, 2003-11-28 at 07:37, Alex Deucher wrote:
> >
> >
> >>I'd say the best supported cards are r200 based radeons (8500 to 9200 cards).
> >>
> >>
> >
> >And which one is the fastest?
> >
> >
> >
> Arguably t
> >>I'd say the best supported cards are r200 based radeons (8500 to 9200 cards).
> >>
well thats just great, I was hopeing to see something different other
than r200 as I have had nothing but trouble and poor performance with
them with DRI. I have yet to determine why but since AGP ppl have re
Torgeir Veimo wrote:
On Fri, 2003-11-28 at 07:37, Alex Deucher wrote:
I'd say the best supported cards are r200 based radeons (8500 to 9200 cards).
And which one is the fastest?
Arguably the Radeon 9100.
Just make sure you don't get some crappy card with a 64-bit memory
interface; i
On Fri, 2003-11-28 at 07:37, Alex Deucher wrote:
> I'd say the best supported cards are r200 based radeons (8500 to 9200 cards).
And which one is the fastest?
--
Torgeir Veimo <[EMAIL PROTECTED]>
---
This SF.net email is sponsored by: SF.ne
--- Chris Ison <[EMAIL PROTECTED]> wrote:
> I know you can't give details under NDA, but do the specs for the
> r200
> show any API for PCI, or has the PCI work on the driver been done by
> trial and error.
I'll have to check the docs when I get home. The original PCI GART
work does done for HP
I know you can't give details under NDA, but do the specs for the r200
show any API for PCI, or has the PCI work on the driver been done by
trial and error.
Also I am wondering if there is any word on specs for r250 and r300. If
not, I would like to know what the best supported card is in DRI with
Title: RE: [Dri-devel] Radeon driver, DDCMode
> -Original Message-
> From: Jon Smirl [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, November 26, 2003 7:41 PM
> To: Hui Yu; 'Alex Deucher'
> Cc: dri-devel
> Subject: RE: [Dri-devel] Radeon driver, DDCMod
--- Hui Yu <[EMAIL PROTECTED]> wrote:
> Well, you can do this if you don't mind getting a lot of complains like "I
> updated to version xxx, radeon driver doesn't use the Modeline I specified
> anymore". Of course, you can get around this is by checking
> pScrn->monitor->Modes->type, see whether a
Title: RE: [Dri-devel] Radeon driver, DDCMode
> -Original Message-
> From: Jon Smirl [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, November 26, 2003 4:08 PM
> To: Hui Yu; 'Alex Deucher'
> Cc: dri-devel
> Subject: RE: [Dri-devel] Radeon driver, DDCMod
--- Hui Yu <[EMAIL PROTECTED]> wrote:
> The panel is probably in analog mode so it's treated as a traditional CRT (I
> haven't found a reliable way to tell an analog panel from a CRT that works
> with all versions of EDID). Usually analog panels comply well with VESA
> standard, the traditional way
Why is this defaulted to off? If the monitor is transmitting it's mode
information why is the default to ignore it and use Vesa standard modes?
I have an LCD display connected through a CRT cable. I couldn't figure out why
it wasn't picking up the detailed timings from DDC. Then I traced all throu
On Sat, 2003-11-15 at 15:52, Shobaki sam. wrote:
>
> -
> assertion "vb.context == ctx" failed: file "radeon_vtxfmt.c", line
> 1061
> Abort trap (core dumped)
> -
> I tried to set RADEON_NO_VTXFMT to 1 but the problem go somewhere
> else, blender bec
Am 2003.11.15 20:46:01 +0100 schrieb(en) Peter Meffer:
> after a long odyssey getting xfree86 dri to work (seemingly), everything
> behaves as expected, except that the gl window (also fullscreen) remains
> black; fps is being reported as usual (4300), no error messages appear,
> neither in the
after a long odyssey getting xfree86 dri to work (seemingly), everything
behaves as expected, except that the gl window (also fullscreen) remains
black; fps is being reported as usual (4300), no error messages appear,
neither in the server log nor the kernel log, no hangups, no crashes,
nothing
Hello group,
Here is my first problem, as explained in PR
http://www.freebsd.org/cgi/query-pr.cgi?pr=59298:
When trying to render any scene with blender, and
pushing the "render" button, blender core dumps with this
error message:
-assertion "vb.context
== ctx" fail
On Mon, 10 Nov 2003 09:05:07 +0100
Mark Baas <[EMAIL PROTECTED]> wrote:
> Hey,
>
> When running Scorched3d I get this error:
> drmCommandWrite: -22
> drmRadeonCmdBuffer: -22 (exiting)
>
> I also got this error with a GameSkel of Soya3d
> http://oomadness.tuxfamily.org/en/soya/game_skel.html
I j
Hey,
When running Scorched3d I get this error:
drmCommandWrite: -22
drmRadeonCmdBuffer: -22 (exiting)
I also got this error with a GameSkel of Soya3d
http://oomadness.tuxfamily.org/en/soya/game_skel.html
--
Mark Baas <[EMAIL PROTECTED])
- Penguin Liberation Front -
---
Ian Romanick wrote:
That aside, I think we should be able to remove xf86drmCompat.c now.
Unless I'm mistaken, libdrm.a is statically linked into the *_dri.so. If
that's the case, and all of the client-side drivers have been updated to
not use the functions in xf86drmCompat.c, why do we need it?
Michel DÃnzer wrote:
On Wed, 2003-10-22 at 23:49, Ian Romanick wrote:
I added Keith's proposed struct with int64_t as the value, and I added
'#include ' to xf86drmCompat.c. Everything compiled fine.
Easy enough. :)
I've updated
http://penguinppc.org/~daenzer/DRI/radeon-memory-transition.diff,
Alex Deucher wrote:
The question is, can we start ripping it out now, or will there be a
xfree86 4.5 and 4.6, etc.
As much as I would like to, I don't think we should start ripping yet.
I think that will raise to many support questions like, "The new DRI
drivers won't load!" :) I think putting
On Wed, 2003-10-22 at 23:49, Ian Romanick wrote:
> I added Keith's proposed struct with int64_t as the value, and I added
> '#include ' to xf86drmCompat.c. Everything compiled fine.
Easy enough. :)
I've updated
http://penguinppc.org/~daenzer/DRI/radeon-memory-transition.diff,
addressing the fe
On Fri, 2003-10-24 at 16:15, Alex Deucher wrote:
> The question is, can we start ripping it out now, or will there be a
> xfree86 4.5 and 4.6, etc.
Until there's an official roadmap for 5.x, I'd assume the next release
to be 4.x.
--
Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI
The question is, can we start ripping it out now, or will there be a
xfree86 4.5 and 4.6, etc.
Alex
--- Ian Romanick <[EMAIL PROTECTED]> wrote:
> Jens Owen wrote:
>
> > We can definitely remove the xf86drmCompat layer for XFree86 5.0.
> I
> > believe it's well understood that major version cha
Jens Owen wrote:
We can definitely remove the xf86drmCompat layer for XFree86 5.0. I
believe it's well understood that major version changes will break
existing binary interfaces.
Oh goodie! There's a whole ton of crap that will get ripped out of
lib/GL/glx/glx{cmds,ext}.c then! All of the s
Ian Romanick wrote:
Michel Dänzer wrote:
On Wed, 2003-10-22 at 20:38, Ian Romanick wrote:
Eric Anholt wrote:
Would we ever be setting pointers through a setparam interface? I
think
making it an int makes it relatively clear that it's a 32-bit value,
though it might be valuable to use [u]intXX_
Michel Dänzer wrote:
On Wed, 2003-10-22 at 20:38, Ian Romanick wrote:
Eric Anholt wrote:
Would we ever be setting pointers through a setparam interface? I think
making it an int makes it relatively clear that it's a 32-bit value,
though it might be valuable to use [u]intXX_t for the drm (and dri
On Wed, 2003-10-22 at 20:38, Ian Romanick wrote:
> Eric Anholt wrote:
>
> > Would we ever be setting pointers through a setparam interface? I think
> > making it an int makes it relatively clear that it's a 32-bit value,
> > though it might be valuable to use [u]intXX_t for the drm (and dri
> > s
Eric Anholt wrote:
Would we ever be setting pointers through a setparam interface? I think
making it an int makes it relatively clear that it's a 32-bit value,
though it might be valuable to use [u]intXX_t for the drm (and dri
screen private?) sruct definitions everywhere to make things clear.
A
> systems will break, we don't need to add more. On PPC64 where mixed
> mode is supported, sizeof(int) != sizeof(void*). I assume
> the same is true on IA-64, x86-64, and SPARC64.
x86-64 Linux (gcc)
sizeof(int) == 4
sizeonf(long) == 8
sizeof(void*) == 8
x86-64 Windows (VC)
sizeof(int) =
On Tue, 2003-10-21 at 11:55, Ian Romanick wrote:
> Keith Whitwell wrote:
>
> > Would you consider creating a DRM_RADEON_SETPARAM ioctl instead of
> > DRM_RADEON_FB_LOCATION, with an ioctl struct like:
> >
> > #define RADEON_SETPARAM_FB_LOCATION 1
> >
> > typedef struct drm_radeon_setparam
On Tue, 2003-10-21 at 20:55, Ian Romanick wrote:
> Keith Whitwell wrote:
>
> > Would you consider creating a DRM_RADEON_SETPARAM ioctl instead of
> > DRM_RADEON_FB_LOCATION, with an ioctl struct like:
> >
> > #define RADEON_SETPARAM_FB_LOCATION 1
> >
> > typedef struct drm_radeon_setparam
On Wed, 2003-10-22 at 01:59, Vladimir Dergachev wrote:
> >
> > Anyway, I think the most important point is that the DRM should be able
> > to deal with whatever you throw at it this way; the details can still be
> > changed later. Agreed?
>
> DRM and DRI drivers. :)
What do you mean? Old 3D driv
> > > > time.
> > >
> > > Any idea how soon that will be? I was originally hoping to sneak this
> > > into XFree86 4.4, but that's getting less likely by the day.
> >
> > No idea unfortunately. I'll be very busy the next three weeks and to make
> > tests I would need to port GATOS code to DRI CVS.
On Tue, 2003-10-21 at 17:13, Vladimir Dergachev wrote:
> On Tue, 21 Oct 2003, Michel [ISO-8859-1] Dnzer wrote:
>
> > On Tue, 2003-10-21 at 03:53, Vladimir Dergachev wrote:
> > > On Tue, 21 Oct 2003, Michel [ISO-8859-1] Dnzer wrote:
> > >
> > > > On Tue, 2003-10-21 at 03:35, Vladimir Dergachev wro
Keith Whitwell wrote:
Would you consider creating a DRM_RADEON_SETPARAM ioctl instead of
DRM_RADEON_FB_LOCATION, with an ioctl struct like:
#define RADEON_SETPARAM_FB_LOCATION 1
typedef struct drm_radeon_setparam {
int param;
int value;
} drm_radeon_setparam_t;
If this is done, I w
On Tue, 21 Oct 2003, Michel [ISO-8859-1] Dänzer wrote:
> On Tue, 2003-10-21 at 03:53, Vladimir Dergachev wrote:
> > On Tue, 21 Oct 2003, Michel [ISO-8859-1] Dnzer wrote:
> >
> > > On Tue, 2003-10-21 at 03:35, Vladimir Dergachev wrote:
> > >
> > > > 2) I would have expected SetFBLocation functi
1 - 100 of 1004 matches
Mail list logo
