chik
> Date : 2010-03-16 22:03 (23 days old)
I sent a pull request with the patch for this to Dave M. today. :-)
John
--
John W. LinvilleSomeday the world will need a hero, and you
[email protected] might be all we
Pulling drm back out of the kernel tree seems like a hard sell, but the
ddx/mesa hw driver/libdrm set seemed like it might be a good candidate for
grouping.
I guess the core question is whether we expect the X-to-ddx and
mesa-to-hw-driver interfaces to be more or less volatile than the ddx-to-
First call drm_agp_acquire to check if agp has been acquired.
Second call drm_agp_info to fill in the info data struct, including aper_size.
Finally do the check to see if the aper_size makes sense.
Signed-off-by: John Kacur
---
drivers/gpu/drm/radeon/radeon_agp.c | 15 ---
1
- Fix warning by using %zu instead of %d for size_t
- Fix spelling mistake, "to" should be "too".
Signed-off-by: John Kacur
---
drivers/gpu/drm/radeon/radeon_agp.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_agp.
radeon_agp_init fixes:
John Kacur (2):
radeon_agp: Fix warning, format â%dâ expects type âintâ, but argument
4 has type âsize_tâ. Also fix grammar/spelling error, change "to" to
"too"
radeon_agp: Move the check of the aper_size after drm_acp_acquire
On Sun, 31 Jan 2010, Dan Nicholson wrote:
> On Sat, Jan 30, 2010 at 12:51 PM, John Kacur wrote:
> > Fix warning by using %zu instead of %d for size_t
> >
> > Signed-off-by: John Kacur
> > ---
> > drivers/gpu/drm/radeon/radeon_agp.c | 2 +-
> > 1 file
is easily fixed. (following up with a patch)
Assuming the patch in that link fixes the problem, the order of the
check of the aper_size in
radeon_agp_init appears incorrect to me. Also following up with a patch.
John Kacur
-
First call drm_agp_acquire to check if agp has been acquired.
Second call drm_agp_info to fill in the info data struct, including aper_size.
Finally do the check to see if the aper_size makes sense.
Signed-off-by: John Kacur
---
drivers/gpu/drm/radeon/radeon_agp.c | 15 ---
1
Fix warning by using %zu instead of %d for size_t
Signed-off-by: John Kacur
---
drivers/gpu/drm/radeon/radeon_agp.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_agp.c
b/drivers/gpu/drm/radeon/radeon_agp.c
index c9ad7f5..1c4e523 100644
radeon_agp_init fixes
John Kacur (2):
radeon_agp: Fix warning, format â%dâ expects type âintâ, but argument
4 has type âsize_tâ
radeon_agp: Move the check of the aper_size after drm_acp_acquire and
drm_agp_info
drivers/gpu/drm/radeon/radeon_agp.c | 15
On Tue, Jan 26, 2010 at 9:20 PM, Alex Deucher wrote:
> On Tue, Jan 26, 2010 at 9:35 AM, John Kacur wrote:
>> On Tue, Jan 26, 2010 at 3:19 PM, Alex Deucher wrote:
>>> On Tue, Jan 26, 2010 at 9:10 AM, John Kacur wrote:
>>>> On Tue, Jan 26, 2010 at 2:59 PM, Alex Deuc
On Tue, 26 Jan 2010, Gene Heskett wrote:
> On Tuesday 26 January 2010, John Kacur wrote:
> >On Tue, Jan 26, 2010 at 3:19 PM, Alex Deucher wrote:
> >> On Tue, Jan 26, 2010 at 9:10 AM, John Kacur wrote:
> >>> On Tue, Jan 26, 2010 at 2:59 PM, Alex Deucher
> w
On Tue, 26 Jan 2010, Gene Heskett wrote:
> On Tuesday 26 January 2010, John Kacur wrote:
> >On Tue, Jan 26, 2010 at 2:59 PM, Alex Deucher wrote:
> >> On Tue, Jan 26, 2010 at 8:21 AM, John Kacur wrote:
> >>> On Fri, 15 Jan 2010, Jerome Glisse wrote:
> >&g
On Tue, Jan 26, 2010 at 2:59 PM, Alex Deucher wrote:
> On Tue, Jan 26, 2010 at 8:21 AM, John Kacur wrote:
>>
>>
>> On Fri, 15 Jan 2010, Jerome Glisse wrote:
>>
>>> On Fri, Jan 15, 2010 at 03:47:19PM +0100, John Kacur wrote:
>>> >
&
On Tue, Jan 26, 2010 at 3:19 PM, Alex Deucher wrote:
> On Tue, Jan 26, 2010 at 9:10 AM, John Kacur wrote:
>> On Tue, Jan 26, 2010 at 2:59 PM, Alex Deucher wrote:
>>> On Tue, Jan 26, 2010 at 8:21 AM, John Kacur wrote:
>>>>
>>>>
>>>> On Fr
On Fri, 15 Jan 2010, Jerome Glisse wrote:
> On Fri, Jan 15, 2010 at 03:47:19PM +0100, John Kacur wrote:
> >
> >
> > On Fri, 15 Jan 2010, John Kacur wrote:
> >
> > > The oops is triggered because I am missing the firmware for
> > > rade
On Fri, 15 Jan 2010, John Kacur wrote:
> The oops is triggered because I am missing the firmware for
> radeon/R700_rlc.bin and
> radeon/R600_rlc.bin
>
> However, I think it should be able to deal with this more gracefully.
>
> ATOM BIOS: 9498.11.22.6.0.AS03
> [drm] Clo
The oops is triggered because I am missing the firmware for
radeon/R700_rlc.bin and
radeon/R600_rlc.bin
However, I think it should be able to deal with this more gracefully.
ATOM BIOS: 9498.11.22.6.0.AS03
[drm] Clocks initialized !
[drm] Detected VRAM RAM=256M, BAR=256M
[drm] RAM width 128bits DD
On 01/07/2010 12:42 AM, Johan Hovold wrote:
>> Yeap. The fix uncovered a bug in your driver. I haven't heard of problems
>> with the other drm drivers.
>>
>>> The backlight is handled via the DRI driver I assume. At least
>>> i9xx_crtc_dpms is called on powerdown.
>>
>> Can you post your dmesg a
On 12/31/2009 12:00 PM, David John wrote:
> With the current DRM code, an output that has been powered off
> from userspace will automatically power back on when resuming
> from suspend. This patch fixes this behaviour.
>
> Tested only with the Intel i915 driver on an Intel GM45 Ex
Would something like mesa/r600_demo be appropriate ?
-Original Message-
From: Keith Whitwell [mailto:[email protected]]
Sent: Friday, July 17, 2009 9:24 AM
To: Harald Welte
Cc: [email protected]; [email protected];
[email protected]; [email protected]; [email protected]
net/lists/netdev/msg100957.html. In both, the
process is doing both sends and receives on raw sockets.
-- John
--
Enter the BlackBerry Developer Challenge
This is your chance to win up to $100,000 in prizes! For a lim
Original Message-
From: Enno Fennema [mailto:[email protected]]
Sent: Wednesday, May 13, 2009 3:57 PM
To: Jerome Glisse; Bridgman, John
Cc: [email protected]
Subject: Re: Need sample program or tutorial
Jerome Glisse wrote:
...
> Why do you want to use XF86DRIQueryDirectRe
Couldn't DRI also be used by a non-GL direct-rendering driver, eg. for
something like video acceleration ?
-Original Message-
From: Jerome Glisse [mailto:[email protected]]
Sent: Wednesday, May 13, 2009 4:53 AM
To: Enno Fennema
Cc: [email protected]
Subject: Re: Need
- Forwarded message from Peter John Garrone -
From: Peter John Garrone
To: Jesse Barnes
Subject: Re: [RFC] page flipping/buffer swap for DRI2
On Fri, Feb 13, 2009 at 04:44:08PM -0800, Jesse Barnes wrote:
> On Friday, February 13, 2009 4:18 pm Peter John Garrone wrote:
> > In
In reply to Jesse Barnes post.
I'm not on top of the finer details, being a consumer rather than a
developer. I have the following queries:
1) Is the buffer flip to be synchronous in the hardware, or to be
implemented as a software interrupt?
2) By fullscreen, do you mean covering one or all scre
>>Brian Paul wrote :
>>If the new driver won't be an incremental change to the existing
radeon
drivers, I'd recommend basing it on Gallium.
The driver will be an incremental change. The 6xx family is conceptually
different inside and there is a learning curve, but the basic
programming model is l
Rage Mobility is closer to Rage Pro, ie one generation before Rage 128.
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Jacek
Poplawski
Sent: Friday, August 24, 2007 5:18 PM
To: DRI developer's list
Subject: old notebook supported by DRI
I want
these features blocking
on the new memory manager?
3) Assuming that the answer to 1) is Yes, any chance of getting an ETA
of when this might be implemented?
--
John McCutchan <[EMAIL PROTECTED]>
-
This SF.net emai
gestions or feedback that the developers on the list
have for what could be done.
(I'll stay subscribed to the list -- or please point me in a different
direction if there is a more appropriate list for this.)
Thanks,
--
John Sullivan
Program Administrator| Phone: (617)542-5942 x23
would be nice if the actual output to the screen would take advantage of that.
On 3/30/06, Brian Paul <[EMAIL PROTECTED]> wrote:
John Kheit wrote:> Do these drivers do anything to support subpixel rendering of the text> or screen images? Is any of that built in to the hardware accelera
Do these drivers do anything to support subpixel rendering of the text or screen images? Is any of that built in to the hardware acceleration, or is that done only at the operating system level?I think on the Windows side, some of the Nvidia drivers do subpixel work on the driver level.
On Mon, 2006-02-27 at 16:42 -0500, Felix Kühling wrote:
> What do you mean with "unmerge"?
I think he is referring to un-intalling, the Gentoo way :)
---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends
x27;ll either have to go suck it up and buy
an x700 notebook before they disappear, or gamble with a 200m and hope we
can figure out the memory controller (and memory management that goes
with it).
john.c
--
John Clemens http://www.deater.net/john
john at deater.net &
1029
is about to be replaced with the 1039 which comes with the new X1600, so
I'd like to know if I have to move before the 1029 disappears, or if i can
wait a little while.
john.c
--
John Clemens http://www.deater.net/john
john at deater.net &
Thanks,
now for a dumb question... how far back do I need to go to get mesa
without those changes, and where?
Thanks again for the help.
> > I have a Thinkpad T20 with a Savage IX, that is running Gentoo Linux
> > with 2.6.14-rc2-mm1 kernel.
> >
> > In order to get direct rendering working, I ha
hello!
I'm using the r300 driver from mesa+drm cvs and would like to know if there is
any way of using agpfastwrite?
thanx
jon
---
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for
WOW!
worked like a charm! thanks!
On Sunday 21 August 2005 16:01, Vladimir Dergachev wrote:
> On Sun, 21 Aug 2005, john wrote:
> > hi!
> > i'm not too experienced in programming, but here it goes: but i've been
> > able to check out the Mesa cvs and the r300 cvs. i
hi!
i'm not too experienced in programming, but here it goes: but i've been able
to check out the Mesa cvs and the r300 cvs. i've been trying for quite a long
time, to compile r300 Mesa drivers. the drm works fine from r300 cvs, but i
cant get mesa to compile. if i try to compile the r300 code f
I have xorg.conf set up to use radeon driver with big
desktop mode and xinerama.
It works fine, but I want acceleration.
So am I correct in saying all I need to do is
# Load "dri"
Load "glx"
uncomment the dri load, and make install your modules?
___
Hi Vladimir,
On Mon, 21 Feb 2005, John Clemens wrote:
give it a go on my fanless 9600se (RV350 AP).
How much memory do you have ? What kind of CPU and motherboard ?
Duron 1.8G, 256MB ddr, old(ish) via km266 motherboard in a shuttle sk41g.
Gentoo. The card has 128Mb ram.
- glxinfo states r300
I'm guessing the X server or mesa isn't filling
the buffer up fast enough at higher resolutions...but I'm new to
devlopment so i don't know which buffer that would be..
thanks,
john.c
--
John Clemens http://www.deater.net/john
john at deater.net &q
build these libraries that isn't in the sample
host.def for Xorg? Are they necessary for languages other than English?
John
signature.asc
Description: This is a digitally signed message part
ri_screen':
> dri_util.c:157: warning: pointer targets in passing arg 1 of
> `glXGetProcAddress' differ in signedness
I ran into the same problem, but this message convinced me there was
little point in trying to fix it.
http://www.mail-archive.com/[email protected]/msg20719.html
John
signature.asc
Description: This is a digitally signed message part
On Wednesday 06 October 2004 06:54, Felix Kühling wrote:
> On Mon, 04 Oct 2004 12:09:09 +0100
>
> Keith Whitwell <[EMAIL PROTECTED]> wrote:
> > John,
> >
> > I'd say the problem is with these lines in savagetris.c:
> >
> >
> >if (index
mage2d:
> Assertion `texImage->TexFormat' failed.
> signal caught: Aborted
> si_code 0
> Trying to exit gracefully..
> [...]
You need to apply the S3TC patch. You'll also need to start X with 24 bit
color. It loads and runs fine with my FireGL8800, b
On Friday 01 October 2004 04:03, Keith Whitwell wrote:
> John Lightsey wrote:
> > A while back I mentioned on dri-devel that Savage cards will segfault
> > RTCW while loading the Checkpoint demo.
> > ( http://www.nixnuts.net/benchmarks/current/ ) The problem is in
> > M
VB->AttribPtr[a[j].attrib];
a[j].inputstride = vptr->stride;
...
}
vptr is null in the middle of the for loop ( j=2 is null j=0, 1, and 3 is
valid.) I have no idea why this is the case, but I've attached a simple fix
which eliminates the problem.
John Lightsey
---
On Monday 23 August 2004 12:36, Ian Romanick wrote:
> John Lightsey wrote:
> > Once I have all the benchmarks together I'll make some pretty little
> > graphs.
> >
> > Soany suggestions, comments, feedback?
>
> First off, great work! Hopefully you'll
On Sunday 22 August 2004 18:37, Ville Syrjälä wrote:
> On Sun, Aug 22, 2004 at 01:16:18AM -0500, John Lightsey wrote:
> > Matrox G400 32MB (mga)
...
> I'm aware of two perfomance bottlenecks in the driver.
>
> Number one is that it always uses synchronous DMA. I have asy
ink to the graphs on Monday.
John
---
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and F
On Sunday 22 August 2004 05:39, Alan Cox wrote:
> On Sul, 2004-08-22 at 07:16, John Lightsey wrote:
> > I shut off most of the services on the machine. rcconf shows klogd,
> > makedev, and sysklogd as the only services active at boot. The kernel
> > used was 2.6.7-1-k7 from
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I sent this message earlier, but it doesn't seem to have made it through.
Subject: First DRI uber-benchmark
Date: Saturday 21 August 2004 13:17
From: John Lightsey <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
A while back it was sug
On Sunday 22 August 2004 01:52, Adam Jackson wrote:
> On Sunday 22 August 2004 02:16, John Lightsey wrote:
> > At any rate, here are the results of the first run. If anyone has
> > suggestions for fixing any of the cards which failed in one way or
> > another, I would
IW and Radeon 9600se
I also have a Radeon 9200 that I was unable to get working with this machine.
Once I have all the benchmarks together I'll make some pretty little graphs.
Soany suggestions, comments, feedback?
John
---
SF.Net
On Sunday 22 August 2004 04:59, Felix Kühling wrote:
> On Sun, 22 Aug 2004 01:16:18 -0500
>
> John Lightsey <[EMAIL PROTECTED]> wrote:
> > Diamond Speedstar a90 16MB (savage 4 pro+) Lots of lockups. glxgears
> > gave this a disappointing 229 fps.
>
> There are
On Sunday 22 August 2004 04:57, Simon 'corecode' Schubert wrote:
> On 22.08.2004, at 08:16, John Lightsey wrote:
> > glxgears - let it run for 1 minute then marked down the highest score
>
> how reproducable and meaningful is a highest score? I don't know, but I
>
playing
ut2003 and ut2004.
I have a few more cards to benchmark for comparison.
Nvidia - TNT2 and FX5200
FGLRX - Radeon 8500 AIW and Radeon 9600se
I also have a Radeon 9200 that I was unable to get working with this machine.
Once I have all the benchmarks together I'll make s
On Wednesday 11 August 2004 04:01 pm, Charles Sprickman wrote:
> On Wed, 11 Aug 2004, John Baldwin wrote:
> > The i830 DRM stuff is ported in a branch of DRI, but it's not in DRI head
> > because of a security problem with the code.
>
> Just out of curiousity, does this
e not actually ported. (Unfinished? broken? unstable?)
The i830 DRM stuff is ported in a branch of DRI, but it's not in DRI head
because of a security problem with the code.
--
John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/
"Pow
If someone
> > >outside the US is willing to host them, I'll gladly share the newer
> > >versions with S3TC compiled in.
>
> Do they have the mach64 driver compiled in ?
>
The July 7th version doesn't. I&
then I've been
adding the S3TC patch and haven't put them online. If someone outside the US
is willing to host them, I'll gladly share the newer versions with S3TC
compiled in.
John
---
This SF.Net email is sponsored by BEA
nularity
are you suggesting?
Are you assuming a device which can read and execute register settings from a
memory buffer, e.g. the dma ring buffer style devices?
John
---
This SF.Net email is sponsored by the new InstallShield X.
>From Windows t
Hello everyone,
I am offically throwing in my hat to volunteer for
testing and code merging for the gatos/dri/linux
kernel 2.6 effort that I have seen as I lurk through
the DRI and GATOS mailing lists.
My current config:
Debian Testing (sarge) Xfree 4.3.0 configuration
Using: Kernel 2.6.5 at the m
these fixes "upstream". Full explanation in the bugzilla referenced.
http://pdx.freedesktop.org/cgi-bin/bugzilla/show_bug.cgi?id=399
--
John Dennis <[EMAIL PROTECTED]>
---
This SF.Net email is sponsored by: IBM Linux Tutorial
export RADEON_GARTTEXTURING_FORCE_DISABLE=1
i have this in /etc/profile, the machine has been rebooted since then, and rainbow
problem still exists.
--- On Fri 03/12, John H. < [EMAIL PROTECTED] > wrote:
From: John H. [mailto: [EMAIL PROTECTED]
To: [EMAIL PROTECTED],
wrote:> On Mon, 8 Mar 2004 15:19:32
-0500 (EST)> "John H." <[EMAIL PROTECTED]> wrote:> > > well, your
suggestion at least makes the speed ok with 800x600(which isn't that great)> >
> > however, the rainbow color thing is making it unplayable(I ca
:18:20 +0100
Subject: Re: Rainbow colors and AGP texturing (was radeon 320m and 3d problems)
On Wed, 2004-03-10 at 12:24, Felix Kühling wrote:> On Mon, 8 Mar 2004 15:19:32
-0500 (EST)> "John H." <[EMAIL PROTECTED]> wrote:> > > well, your
suggestion at least makes
lace the kernel drm drivers as well? If so
do they manage AGP themselves, or do they use the systems agpgart
driver? Do they replace the systems agpgart driver?
--
John Dennis <[EMAIL PROTECTED]>
---
This SF.net email is sponsored by: SF.ne
s a minor side note, definitions of bit flags should be tagged as
unsigned. Thus things like:
#define DRM_LOCK_HELD 0x8000
#define DRM_LOCK_CONT 0x4000
should really be:
#define DRM_LOCK_HELD 0x8000U
#define DRM_LOCK_CONT 0x4000U
John
--
r that keeps the upstream developers
happy. My personal preference is solution #3.
John
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-
s issue?
FWIW, I googled for this error and came up with several folks who
starting around last spring started seeing the same problem, but none
of the mail threads had a follow up solution.
Thanks,
John
---
This sf.net email is sponsor
send me a pointer to something that
documents it. I'd like to know why one implementation is picked over the
other, are there version dependencies, why it exists as parallel to drm
and what its trying to fix.
Thanks,
John
--
John Dennis &l
the same errors.
> Also try just doing:
>
> make -f Makefile.linux radeon.o
>
> on /home/john/dripkg/drm and see if it helps.
- Original Message -
From: "José Fonseca" <[EMAIL PROTECTED]>
To: "John R. Tomawski" <[EMAIL PROTECTED]>
Cc:
After I see this:
Compiling...
ERROR: Kernel modules did not compile
I get the following in dri.log, when I try sh
install.sh
make -f Makefile.linux DRM_MODULES=radeon.o
modulesmake[1]: Entering directory `/home/john/dripkg/drm'make -C
/lib/modules/2.4.20-8/build SUBDIRS
After I see this:
Compiling...
ERROR: Kernel modules did not compile
I get the following in dri.log, when I try sh
install.sh
make -f Makefile.linux DRM_MODULES=radeon.o
modulesmake[1]: Entering directory `/home/john/dripkg/drm'make -C
/lib/modules/2.4.20-8/build SUBDIRS
ugh the i830
source myself, but the anonymous CVS servers have been a wreck for the last
few days.)
Thanks for the help!
John
---
This SF.Net email is sponsored by: INetU
Attention Web Developers & Consultants: Become An INetU Hosting Partner.
I think it's a been a decent interval to resend
The problem was with a PCI Rage128 card (16 MB video RAM) which seemed to have
problems with memory allocation (i.e. 0 kb texture memory allocated at 1280 *
1024, only 4MB at 1024&768). Since the box claims 3D performance at 1280 in
Windows,
On Thursday 05 June 2003 11:45 am, Leif Delgass wrote:
> I'm pretty sure I ran into this problem on r128 before when I tried
> running at 24-bit depth with a high enough resolution. If this is the
> problem, I think you'd see a message like: "Reserved 0 kb for textures at
> offset 0x0" in the X lo
On Friday 06 June 2003 10:39 am, you wrote:
> On Friday 06 June 2003 08:56 am, Ian Romanick wrote:
> > Hmmm...that is odd. The resolution should only require 7.5MB for the
> > front, back, and depth-buffers. That should leave about 8MB for
> > textures, not 800KB. Are you sure it's at 16-bpp? ~
On Friday 06 June 2003 08:56 am, Ian Romanick wrote:
> Hmmm...that is odd. The resolution should only require 7.5MB for the
> front, back, and depth-buffers. That should leave about 8MB for
> textures, not 800KB. Are you sure it's at 16-bpp? ~800KB left is about
> rigth if you were running at
Just a testI think my e-mail might not be getting through
---
This SF.net email is sponsored by: Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try To
On Thursday 05 June 2003 11:45 am, Leif Delgass wrote:
> I'm pretty sure I ran into this problem on r128 before when I tried
> running at 24-bit depth with a high enough resolution. If this is the
> problem, I think you'd see a message like: "Reserved 0 kb for textures at
> offset 0x0" in the X lo
Managed to get my r128 working by lowering res/bpp (duh moment)
One more thing I noticed: in my wide journeys in getting my DRI to work one of
the things I did was to replace my distro-supplied (Mandrake 9.1) libGL.so
with the one off the DRI download site. Now that I have working 3D accel, I
On Thursday 05 June 2003 07:08 pm, Leif Delgass wrote:
> Try a lower resolution and/or color depth. We can fix the segfault, but
> that won't change the fact that there isn't enough on-card memory to use
> 3D at the configured resolution/depth (at least with the current static
> shared back buffe
Ian Romanick wrote:
> Hmm...looking at the code, my guess is that rmesa->nr_heaps is 2 on Rage
> 128 even on PCI cards. In gdb you can 'print rmesa->nr_heaps' to see.
> You might also try 'print r128scrn->texSize[0]' and (if nr_heaps is 2)
> 'print r128scrn->texSize[1]'. Since I don't have a Rage
On Wednesday 04 June 2003 03:56 am, José Fonseca wrote:
> Please do:
> # gdb glxgears
> > run
> ...
> > bt
> And send the resulting backtrace to pinpoint the problem.
Didn't notice you wanted the backtrace. Here it is (whole)
[start]
Starting program: /usr/X11R6/bin/glxi
Some relevant background:
About a month ago, I clean-installed Mandrake 9.1 on the system. XFree + DRI
works great, except for the fact that the r128 driver was an old system and
evidently had problems with my PCI Rage128 card. So I downloaded the binary
driver packages and installed, with th
Output of gdb on glxinfo:
Starting program: /usr/X11R6/bin/glxinfo
(no debugging symbols found)...[New Thread 16384 (LWP 2145)]
name of display: :0.0
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 2145)]
0x4046dee5 in driSetTextureSwapCounterLocation (heap=0x
> I'm trying to install the binary snapshot of the radeon driver available at
> http://dri.sourceforge.net/snapshots/radeon-20030603-linux.i386.tar.bz2
>
> The build goes smoothly but when the script tries to install it reports:
> GL & GLU libraries...ls: *: No such file or directory
>
> An
purposeful omission?
Thanks
John
---
This SF.net email is sponsored by: eBay
Get office equipment for less on eBay!
http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
___
Dri-devel mailing list
[EMAIL PROTEC
Title: Free
Please Read: Very Important Information for You
& Your
Future.
Investment
Bankers and Analysts Provide You With Information Only They Want to
Hear...Their
Buy Recommendations Always Seem Wrong...They Lose You Money...And
All of That
is While They Collect Big Fees
re all users must
be considered hostile this is less effective.
Thanks for the infomation.
John Bartoszewski Email: [EMAIL PROTECTED]
Senior Systems/Security Administrator .--.
Instructional Laboratories: If you are not ter
ld also
> show up in the dmesg output? Weird...
I went back, and realised that the error I was getting was the old
one...the very old one. Which you said use "export MESA_NO_SSE=1" to
banish.
I did so, and it's fine. Yay. Thanks!
John
--
Is this good ?
>
> Yes, it means the DRI should work once the DRM is new enough.
Hmm. OK, so I've to match the DRM date and the renderer date. And it
looks like the DRM is really old. OK, I'll try update that...properly.
John
--
'm no longer sure what libraries are supposed to be
used).
glxinfo -v does output;
OpenGL renderer string: Mesa DRI Radeon 20021125 AGP 1x x86/MMX/SSE NO-TCL
OpenGL version string: 1.2 Mesa 5.0
Is this good ?
John
---
This SF.NET
nfb 17888 0 (unused)
fbcon-cfb24 4320 0 [radeonfb]
fbcon-cfb8 3392 0 [radeonfb]
fbcon-cfb32 3744 0 [radeonfb]
fbcon-cfb16 4032 0 [radeonfb]
Should the radeon.o not
On Mon, Feb 10, 2003 at 11:24:58PM +0100, Jacek Pop³awski mentioned:
> On Mon, Feb 10, 2003 at 06:31:37PM +0000, John P. Looney wrote:
> > Hi, I was using the old Radeon drivers that shipped with a dist-upgraded
> > Woody, though they were mostly fine in Quake3, in Wolfenst
On Tue, Feb 11, 2003 at 12:36:54AM +0100, Michel Dänzer mentioned:
> On Mon, 2003-02-10 at 19:31, John P. Looney wrote:
> > Hi, I was using the old Radeon drivers that shipped with a dist-upgraded
> > Woody, though they were mostly fine in Quake3, in Wolfenstien, there were
>
START|0x400}, {0x80d5014,
[ILL], SA_RESTART|0x400}, 8) = 0
6882 rt_sigaction(SIGFPE, {0x464d26d4, [FPE], SA_RESTART|0x400}, {0x80d5014,
[FPE], SA_RESTART|0x400}, 8) = 0
6882 --- SIGFPE (Floating point exception) ---
Could this be a problem wit
1 - 100 of 129 matches
Mail list logo
