Frank C. Earl wrote:
On Wednesday 24 October 2001 07:17 pm, Carl Busjahn wrote:
Your depth is 24. 3D depths are only 16bit and 32bit. The Mach64 is
really not powerful enough to handle 32bit (which is what 24 yeilds in
XFree86 4.1). I'm not even sure if the driver supports 32bit depth, but
On Wednesday 24 October 2001 01:54 am, [EMAIL PROTECTED] wrote:
a=readl(kms-reg_aperture+MACH64_BUS_CNTL);
writel((a | (31) )(~(16)), kms-reg_aperture+MACH64_BUS_CNTL);
same other code
works fine. Now why would this be ?
This could be caused by the same thing
On Wednesday 24 October 2001 11:30 pm, Gareth Hughes wrote:
Hmm, in a day where you can get PC graphics hardware that can run Quake3
at 1600x1200@32 with maximum quality settings at around 100 fps, perhaps
you should reevaluate your idea of powerful enough...
Now, now, not everybody can use
Frank C. Earl wrote:
Now, now, not everybody can use your employer's gear, Gareth... :-
It's not hard to get something rather more powerful than a Rage Pro --
anandtech.com lists current-generation hardware for under $120. One
would guess going back a generation or two would bring the
On Thu, 2001-10-25 at 03:51, Daniel T. Chen wrote:
I'm attempting to incorporate DRI's mesa-4-0-branch into my
current X 4.1.0.1 (Debian sid from X 4_1 branch) setup but am running
into difficulties. I checked out the mesa-4-0-branch and created the build
tree as the DRI compilation
Gareth Hughes wrote:
Frank C. Earl wrote:
Now, now, not everybody can use your employer's gear, Gareth... :-
It's not hard to get something rather more powerful than a Rage Pro --
It is, actually. At least if you are stuck with a notebook computer. The
Rage LT Pro and Rage Mobility
Peter Lemken wrote:
It is, actually. At least if you are stuck with a notebook computer. The
Rage LT Pro and Rage Mobility are among the most popular graphics
adapters around. I wish I could just put in a different card...
Yes, I understand that. That's not the point I was making, or what
Daniel T. Chen wrote:
Hi folks,
I'm attempting to incorporate DRI's mesa-4-0-branch into my
current X 4.1.0.1 (Debian sid from X 4_1 branch) setup but am running
into difficulties. I checked out the mesa-4-0-branch and created the build
tree as the DRI compilation guide instructed
I've only found two posts with regard to the Savage chipset. XFree
supports acceleration for it, and I was wondering what I could do to get
started on making a driver for this thing?
I figure I'll get a bunch of experience by helping to debug the Mach64
driver (which I'm about to go get and
On Thu, 25 Oct 2001, Kees Cook wrote:
Date: Thu, 25 Oct 2001 17:12:40 -0500
From: Kees Cook [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Content-Type: text/plain; charset=us-ascii
List-Id: dri-devel.lists.sourceforge.net
Subject: Savage-4
I've only found two posts with regard to the Savage chipset.
On Thu, 25 Oct 2001, Mike A. Harris wrote:
On Thu, 25 Oct 2001, Kees Cook wrote:
Date: Thu, 25 Oct 2001 17:12:40 -0500
From: Kees Cook [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Content-Type: text/plain; charset=us-ascii
List-Id: dri-devel.lists.sourceforge.net
Subject: Savage-4
I've
On Thu, Oct 25, 2001 at 09:52:23PM -0400, Adam K Kirchhoff wrote:
You will have to contact S3 and ask them for documentation.
They don't to my knowledge seem too interested in Linux, but I
could be wrong.
That would be the first step anyway.
It might also pay to get in touch with
On Thu, 25 Oct 2001, Adam K Kirchhoff wrote:
I've only found two posts with regard to the Savage chipset. XFree
supports acceleration for it, and I was wondering what I could do to get
started on making a driver for this thing?
I figure I'll get a bunch of experience by helping to debug
Hello.
I was investigating on how to allow both 2D and 3D acceleration in the
Mach64. So I'm a little confused:
First of all, I looked at the R128 and RADEON drivers and they are only doing
a DRILock/DRIUnlock in the LeaveVT and EnterVT functions. Does this mean that
those cards can do 3D
I haven't done an extensive look at this, but I've noticed a couple of
things. The 2D driver seems to use a caching scheme for register writes.
Also, at one point I had a nasty lockup trying to switch to a vt from
fullscreen quake, but I haven't tried it with my latest build yet. I've
noticed
El Vie 26 Oct 2001 20:21, Leif Delgass escribió:
I haven't done an extensive look at this, but I've noticed a couple of
things. The 2D driver seems to use a caching scheme for register writes.
Also, at one point I had a nasty lockup trying to switch to a vt from
fullscreen quake, but I
On Fri, 26 Oct 2001, Manuel Teira wrote:
I have been looking to the register caching. I don't know if this caching has
sense once the DRI is also writing directly to some of the registers. I saw
seldom times this in my XFree log file:
.. $REGISTER_NAME write cache disabled!
I've noticed
Manuel, the hang when switching back from a vt to X with Quake running
hangs both in fullscreen and windowed mode (other GL apps like gears don't
exhibit this problem, although there is initially some garbage at the top
of the screen when returning to X). I'm sure you're right that it has to
do
El Vie 26 Oct 2001 22:11, Leif Delgass escribió:
Manuel, the hang when switching back from a vt to X with Quake running
hangs both in fullscreen and windowed mode (other GL apps like gears don't
exhibit this problem, although there is initially some garbage at the top
of the screen when
Hi everybody working on the Mach64 driver,
I think it's really important for you to get in touch with the 2D driver
maintainer, Marc Aurele La France [EMAIL PROTECTED]. First because he is
the single most competent person about the 2D driver and probably about
the Mach chips in general, second
El Sáb 27 Oct 2001 16:08, Michel Dänzer escribió:
Hi everybody working on the Mach64 driver,
I think it's really important for you to get in touch with the 2D driver
maintainer, Marc Aurele La France [EMAIL PROTECTED]. First because he is
the single most competent person about the 2D driver
First off, I messed up on the FIFO size defines in mach64_drv.h (drm
kernel module), they should be:
# define MACH64_CMDFIFO_SIZE_MASK 0x0003ul
# define MACH64_CMDFIFO_SIZE_192 0xul
# define MACH64_CMDFIFO_SIZE_128
El Sáb 27 Oct 2001 18:49, Leif Delgass escribió:
First off, I messed up on the FIFO size defines in mach64_drv.h (drm
kernel module), they should be:
# define MACH64_CMDFIFO_SIZE_MASK 0x0003ul
# define MACH64_CMDFIFO_SIZE_192 0xul
#
Well, I just got my box to hang hard (like with the vt switching) when
running tuxracer and switching modes with Ctrl-Alt-+ (I have 3 modes
defined in my config and the hang happened when looping back to the
original mode, i.e. the third switch), so I think the
answer is yes, it needs
El Sáb 27 Oct 2001 19:49, Leif Delgass escribió:
Well, I just got my box to hang hard (like with the vt switching) when
running tuxracer and switching modes with Ctrl-Alt-+ (I have 3 modes
defined in my config and the hang happened when looping back to the
original mode, i.e. the third
On Sat, 27 Oct 2001, Manuel Teira wrote:
El Sáb 27 Oct 2001 19:49, Leif Delgass escribió:
Well, I just got my box to hang hard (like with the vt switching) when
running tuxracer and switching modes with Ctrl-Alt-+ (I have 3 modes
defined in my config and the hang happened when looping
El Sáb 27 Oct 2001 21:40, Leif Delgass escribió:
On Sat, 27 Oct 2001, Manuel Teira wrote:
El Sáb 27 Oct 2001 19:49, Leif Delgass escribió:
Well, I just got my box to hang hard (like with the vt switching) when
running tuxracer and switching modes with Ctrl-Alt-+ (I have 3 modes
On Sat, 27 Oct 2001, Manuel Teira wrote:
El Sáb 27 Oct 2001 21:40, Leif Delgass escribió:
On Sat, 27 Oct 2001, Manuel Teira wrote:
El Sáb 27 Oct 2001 19:49, Leif Delgass escribió:
Well, I just got my box to hang hard (like with the vt switching) when
running tuxracer and switching
OK, I actually looked at the definition of DRILock/DRIUnlock
(programs/Xserver/GL/dri/dri.c), and it does reference counting, so
locking twice might not be an issue, it just increments the reference
count. What I haven't found yet is where the DRM_LOCK/DRM_UNLOCK macros
used in DRILock/DRIUnlock
On Sun, 2001-10-28 at 01:46, Papadakos Panagiotis wrote:
There are problems with Xfree-4.1.0 and after.I don't know what,but if you
want tou use Openoffice-Staroffice 6.0 you will have to work with
Xfree-4.0.3.
I found that the problem is with libXrender. If this
library is relocated SO
On Sun, Oct 28, 2001 at 02:46:50AM +0300, Papadakos Panagiotis wrote:
There are problems with Xfree-4.1.0 and after.I don't know what,but if you
want tou use Openoffice-Staroffice 6.0 you will have to work with
Xfree-4.0.3.
I'm running Open Office 638 on XFree 4.1 just fine. Without more
Though I do not have either OpenOffice or StarOffice running, (I tried
OpenOffice, some problems) I do know that OpenOffice calls for libGL. I
would guess that your problem is in /etc/ld.so.conf You might want to
put /usr/X11R6/lib in front of /usr/X11R6-DRI/lib in that file.
Good luck,
I try to run setup from openoffice 638C and all I get is the message:
glibc version: 2.2.3 and then I get back to the shell.I am using the
latest CVS from Xfree and I am using a G400 Dualheaded.Also many other
people have the same problem,but nobody has explained why this is
happening.
On Sat,
On Sun, 2001-10-28 at 02:02, Daryll Strauss wrote:
I'm running Open Office 638 on XFree 4.1 just fine. Without more
information as to what's happening when you try to run Star Office I
don't think we can help you.
What do you need? An strace?
--
Gérard Milmeister
Tannenrauchstr. 35
8038
The StarOffice 6.0 beta works just fine here on X 4.1.0[.1, it's a Debian
sid package, 4.1.0-9].
---
Dan Chen [EMAIL PROTECTED]
GPG key: www.cs.unc.edu/~chenda/pubkey.gpg.asc
On Sun, 28 Oct 2001, Papadakos Panagiotis wrote:
There are problems with Xfree-4.1.0 and after.I don't
El Dom 28 Oct 2001 00:10, Leif Delgass escribió:
On Sat, 27 Oct 2001, Manuel Teira wrote:
El Sáb 27 Oct 2001 21:40, Leif Delgass escribió:
On Sat, 27 Oct 2001, Manuel Teira wrote:
El Sáb 27 Oct 2001 19:49, Leif Delgass escribió:
Well, I just got my box to hang hard (like with the
On Sun, 28 Oct 2001, Manuel Teira wrote:
[snip]
I still think that we should avoid more than one consecutive locks. It
has nonsense from my point of view, at least in this case. The
DRM_LOCK/DRM_UNLOCK macros are defined in:
xc/programs/Xserver/hw/xfree86/os-support/xf86drm.h and a lot of
El Dom 28 Oct 2001 19:17, Leif Delgass escribió:
snip
OK. I did test it out doing it in the way I suggested, but I'm still
getting a lockup. I was thinking of compiling with the debugging macros
turned on to get a better idea of where the problem is. Since the problem
doesn't seem to
On Sun, 28 Oct 2001, Manuel Teira wrote:
El Dom 28 Oct 2001 19:17, Leif Delgass escribió:
snip
OK. I did test it out doing it in the way I suggested, but I'm still
getting a lockup. I was thinking of compiling with the debugging macros
turned on to get a better idea of where the
[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote:
- Variables:
-- X 4.1.0, mesa-3-5-branch of DRI as of 10/1/2001
-- Glide3 (downloaded from dri.sourceforge.net),
SLIAA-1-0-branch of Glide3 CVS (which
effectively provides working SLI)
Well it's a bit optimistic to do
On Mon, 29 Oct 2001, Gilles May wrote:
I'm messing a bit with the SLI branch myself since it pains me that the
card cannot use its full potential under Linux. It compiles fine. But
could any of the Glide3 enlightenend people tell me what that error
means and what causes it since I'm
I have been considering lending a hand with supporting the effort to
port the Xpert98 drivers to DRI. Anyone hear know what is happening in
this area?
Robin
--
Robin Forster, Systems Engineer,
http://www.rsforster.ottawa.on.ca/
___
Dri-devel
Could somebody please help me? I have compiled the latest
mach64-0-0-2-branch from cvs, and I can not get direct rendering to
load.
The latest dri kernel modules install properly, and so does the agpgart
kernel module. My video card reports that bus mastering is enabled. And
I have activated
On Monday 29 October 2001 01:04 pm, Robin Forster wrote:
I have been considering lending a hand with supporting the effort to
port the Xpert98 drivers to DRI. Anyone hear know what is happening in
this area?
The Xpert98 should be a RagePRO type chipset (if memory serves...)- we're
working
Where are you placing the mach64*.o modules?
You should be putting them somewhere under your kernel module directory
(/lib/modules/2.4.5*) The mach64 modules are not built automatically by
the DRI make World command. To compile these modules, cd to
Could you describe how you did the build/installation in a bit more
detail? Did you copy anything into your /usr/X11R6-DRI tree from another
installation or make changes to host.def? Your ati_drv.o/atimisc_drv.o
modules are saying compiled for 4.1.0 instead of compiled for
4.1.99.1. You should
I created X11R6-DRI, by copying my old X installation. I have not ran
make install, as it appears that I do not have to do so in the
compilation guide. If that is what I have to do, is it likley that it
won't affect my current X installation (Currently /usr/X11R6)?
Thanks
On Tue, 2001-10-30 at
On 30 Oct 2001, Liam Wilks wrote:
I created X11R6-DRI, by copying my old X installation. I have not ran
make install, as it appears that I do not have to do so in the
compilation guide. If that is what I have to do, is it likley that it
won't affect my current X installation (Currently
Keith Whitwell wrote:
Ralf,
I've had time now to look at the patch and the problem I see with it is the
kernel changes. Kernel changes are problematic because of the compatibility
issues they introduce - people upgrading X but not the kernel and vice versa.
From the look of it, the
Thanks for your help, I now have direct rendering enabled.
On Tue, 2001-10-30 at 16:35, Leif Delgass wrote:
On 30 Oct 2001, Liam Wilks wrote:
I created X11R6-DRI, by copying my old X installation. I have not ran
make install, as it appears that I do not have to do so in the
compilation
Hello!
* Leif Delgass ([EMAIL PROTECTED]) wrote:
Speaking of old hardware, in addition to my RagePRO, I also have a PCI s3
virge, which I think has a Utah driver that's yet to be ported to dri.
Anybody have docs on that one? ;)
Yes, I've S3 ViRGE databook. And maybe a still working card
Yes, I've S3 ViRGE databook. And maybe a still working card ;)
Two years later I do some work on KGIcon drivers (for GGI project). 2D accel
stuff like lines, etc. And try to do some basic 3D too. Nothing special, only
lines and triangles were working. The driver used IOCTLs instead of DMA
On Wed, 2001-10-31 at 10:08, Anders Haugen wrote:
Two years later I do some work on KGIcon drivers (for GGI project). 2D accel
stuff like lines, etc. And try to do some basic 3D too. Nothing special, only
lines and triangles were working. The driver used IOCTLs instead of DMA
transfers.
Hi,
Has anybody experience with a MGA G450 (PCI) and direct rendering?
In my system starting an OGL application, e.g. atlantis causes a system
crash.
I use the X4.1.0 driver with kernel 2.4.13 module (mga.o).
Also tested the driver 1.4.3 from the Matrox web page.
glxinfo shows this
I have a new laptop with a Radeon Mobility and am having troubles
getting the agpgart to load.
Anyone know where I should start debugging?
Here's the info I've got...
Thanks!
-Troy.
Unable to handle kernel NULL pointer dereference at virtual address 0020
*pde =
Matrox just released a set of new drivers for both XFree 4.0.x and 4.1.0 with
the ability to use hardware 3D acceleration on the 2nd screen, among other
things..
www.matrox.com
--
Hetz Ben Hamo
[EMAIL PROTECTED]
On Wednesday 31 October 2001 13:17 pm, Michael Greger wrote:
Hi,
Has
Hello!
* Anders Haugen ([EMAIL PROTECTED]) wrote:
Also looked at the mesa X part of it but i haven't
understood how everything there works yet. Not enough
to start putting in code from the utah-glx driver.
;) I've the same feeling when I try to write ViRGE Mesa target (for kgicon).
On
On Wed, Oct 31, 2001 at 12:02:11PM -0800, [EMAIL PROTECTED]
wrote:
Message: 7
From: Hetz Ben Hamo [EMAIL PROTECTED]
To: Michael Greger [EMAIL PROTECTED],
[EMAIL PROTECTED]
Subject: Re: [Dri-devel] Matrox G450 (PCI) and DRI
Date: Wed, 31 Oct 2001 21:44:39 +0200
Matrox just released a
Hello!
I tried to compile the dri mesa-4-0-branch to see if it works with my
voodoo3.
Before that, I edited the host.def and commented out
the #define MesaSrcDir ... line, because I didnt have this directory
on my system.
then tried make World
It failed with
make[4]: *** No rule to make
Your jumping the gun.
The mesa-4-0-branch is still under construction
As and when - the Mesa 4.0 code will be merged under xc/extras/Mesa
and symlinked in as usual.
Be patient
Alan.
On Fri, Nov 02, 2001 at 05:47:31PM +0100, Andreas Stenglein wrote:
Hello!
I tried to compile the
Hi:
I bought a new laptop Compaq Presario 2700Us. This laptop got the ATI Radeon
Mobility M6 graphics card and I have a 15in XGA monitor. I am trying to
install RedHat 7.2 on this laptop. Everything during the installation was
going fine till the X configuration. RH detected my graphics card
QUESTION:
Why is it that in 1280x1024 mode Win98 works fine but with X my screen
jitters in a HIGHLY annoying fashion?
I am using the DRI accelerated server.
Is there anyway in Xfree 4.0.3 to specify modeline settings so I can
*try* to fix this problem? The monitors spec recommends 1280x1024
On Thu, 8 Nov 2001, Hetz Ben Hamo wrote:
Date: Thu, 8 Nov 2001 20:18:37 +0200
From: Hetz Ben Hamo [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Content-Type: text/plain;
charset=iso-8859-1
List-Id: dri-devel.lists.sourceforge.net
Subject: Rage Pro/Mach 64 driver development
Hi,
I just wanted to
I've managed to install the tdfx DRI-driver on my Slackware Linux system.
'glxinfo' reports that everything is fine and that I've got direct
rendering. But if I go on to some games for example, the performance is
terrible! In FPS-games i get lousy framerates compared to M$-OS'es. Am I
doing
It has been some time...
So, here's is my latest cut at latest AGP support for UniNorth.
It consists of 2 patches:
- uninorth_agp.diff
This one can probably be merged as-is, it adds support for the UniNorth
chipset to the AGP driver backend
- mac_r128_drm.diff
That one cannot be merged
At 6:56 PM -0500 11/11/01, Zilvinas Valinskas wrote:
On Sun, Nov 11, 2001 at 03:17:15PM -0800, strobe anarkhos wrote:
Has anybody seen a project or code which renders X11 graphics using OpenGL calls?
Sort of what you are looking for is the http://www.enlightenment.org/
Check out E17 in CVS ...
Hey Ben, I don't suppose you would consider helping a Darwin port of DRI
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
On Sun, 11 Nov 2001 15:17:15 -0800 strobe anarkhos [EMAIL PROTECTED] babbled
profusely:
Has anybody seen a project or code which renders X11 graphics using OpenGL
calls?
evas.
(canvas library - can use X11, software rendering or opengl - stubs for xrender
support - but missing functionality
Hey Ben, I don't suppose you would consider helping a Darwin port of DRI
Sorry, I really don't have time for that. Also, my knowledge of
Darwin's mach kernel internals isn't good enough I beleive ;)
Ben.
___
Dri-devel mailing list
[EMAIL PROTECTED]
Carsten Haitzler (The Rasterman) wrote:
On Sun, 11 Nov 2001 15:17:15 -0800 strobe anarkhos [EMAIL PROTECTED] babbled
profusely:
Has anybody seen a project or code which renders X11 graphics using OpenGL
calls?
evas.
(canvas library - can use X11, software rendering or opengl - stubs
Probably the only useful platform for such a
beast would be windows or maybe darwin (everyone else has an
X server already,
or else they don't have opengl). People have put work into X
servers layered
or mingled with windows, so darwin is perhaps the only
platform that could
benefit
Probably easier to write an X server ddx that targets the darwin 2d apis and
works in a similar way to the existing X-on-win32 products.
1) There are no darwin 2d apis
2) OS X 2D isn't accelerated, and it wouldn't match X11 bit-for-bit either. Win32
isn't relevant, it's graphics library is
- having multiple Users and X-Servers running on a single
video card output plug. This would mean having a hosting
X11 system and multiple windows (i.e. vertically tiled)
with X11-on-OpenGL application windows that will never
interfere with each other.
This is not an OpenGL
It's an interesting idea. Sometimes I've been concerned that the X
world is reinventing concepts that already exist in the OpenGL world,
thus reducing the leverage that we might otherwise gain from driver
optimizations and from relationships with hardware vendors. An X server
based on an OpenGL
On Mon, Nov 12, 2001 at 08:03:16PM +0100, yhata wrote:
Thanks for answering me, Mike :)
I couldn't download that file from dri.sourceforge.net, but fortunately I
had a copy of it on my HD. I tried that, but it didn't seem to have any
problems. Anyway, here is the output:
Direct Rendering
i was playing ut and it froze and had to telnet in to kill it off and
after i got
back x i noticed this error in the console i ran ut from:
ut-bin: tdfx_texman.c:392: tdfxTMFindOldestObject: Assertion
`t-range[0]' failed
after talking with mharris on #xfree86 and some digging i found out this
is
At 10:51 AM -0800 11/12/01, Allen Akin wrote:
It's an interesting idea. Sometimes I've been concerned that the X
world is reinventing concepts that already exist in the OpenGL world,
thus reducing the leverage that we might otherwise gain from driver
optimizations and from relationships with
On Tue, Nov 13, 2001 at 02:54:43AM -0800, strobe anarkhos wrote:
|
| Well if you're going to add all that you might as well develop a
| completely new API or just copy a better standard like display
| postscript.
Or use OpenGL, in many cases.
The reason I brought it up is that people *are*
Hi!
I have been off for some weeks but It seems Mach64 dri module is currently
working...
As I have not cvs access (I'm behind a HTTP proxy and I'm trying to get rid
of it using desproxy (desproxy.sf.net)), I can't pull it from cvs so I guess
if someone could point me to some location where
Hi all,
I am using the DRI on my Dell Latitude C800 with a Rage 128, and it has
been working very well for quite some time now. I have recently updated my
debian woody (weekly apt-get upgrade), though, and from then on, things
suddenly stopped working. I'm not sure which libs were
Answering my own question. :)
I found in tdfx_driver.c,
TDFXScreenInit()
`TDFXLoadPalette16()
TDFXLoadPalette16() is functionally equivalent to
linhwc.c:hwcGammaTable().
I looked into how TDFXLoadPalette16() is called, and I soon discovered
xgamma(1) which I believe will solve my problems
I have a ATI Rage Mobility Mach32 card I beleave ... Its in a Dell inspiron 7500 and I
was just wondering is there DRI support for it? I was looking for something that
might speed up my frame rate
Thanks
Nick
___
Dri-devel mailing list
[EMAIL
On Friday 16 November 2001 12:51 pm, Nick Hudson wrote:
I have a ATI Rage Mobility Mach32 card I beleave ... Its in a Dell inspiron
7500 and I was just wondering is there DRI support for it? I was looking
for something that might speed up my frame rate.
Drivers for the RagePRO family (which
On Fri, 2001-11-16 at 23:34, Jose Fonseca wrote:
(II) LoadModule: bitmap
(II) Loading /usr/X11R6-DRI/lib/modules/fonts/libbitmap.a
Not loading .rodata.str1.1
[ ... ]
See the Xpert mailing list archives. The module loader can't cope with a
feature of your compiler. A workaround is in XFree86
On 2001.11.18 17:37 Michel Dänzer wrote:
On Fri, 2001-11-16 at 23:34, Jose Fonseca wrote:
(II) LoadModule: bitmap
(II) Loading /usr/X11R6-DRI/lib/modules/fonts/libbitmap.a
Not loading .rodata.str1.1
[ ... ]
See the Xpert mailing list archives. The module loader can't cope with a
On Wed, 2001-11-14 at 13:41, Daniel Polombo wrote:
I am using the DRI on my Dell Latitude C800 with a Rage 128, and it has
been working very well for quite some time now. I have recently updated my
debian woody (weekly apt-get upgrade), though, and from then on, things
suddenly stopped
dri-cvs compilation fails with: cannot find -lXau. I followed the
compilation guide to the letter. What could I have done wrong? I used
xfree86 cvs instead and i have dri enabled for my rage 128 pro ultra tf
which is not supported on debian testing or unstable.
I also have a locale problem. I
Michel Dänzer wrote:
First make sure that both xserver-xfree86 and xlibmesa3 are the same
versions, namely 4.1.0-x.
Both are indeed 4.1.0-9.
My first guess would have been a wrong version of the kernel module, but
the one from the 2.4.14 kernel should work. Could there be a stray
Hi,
I was wondering, the driver status of the r128 driver says DPMS is supported,
but somehow I can only get the screen blanking to work (works automagically).
Whatever tool I try to use, my screen will never go standby or suspend.
Anyone else managed in doing this?
Regards,
-- tinus
Steve Bergman wrote:
Hi,
I'm having problems with lockups since I upgraded my memory to 1GB. I
have reason to suspect that the location of the SAREA (just above the
1GB level) is my problem. Does anyone know how to change the address
that DRI picks for the SAREA?
I don't know the
On Tue, Nov 20, 2001 at 06:36:35PM +, Keith Whitwell wrote:
Steve Bergman wrote:
Hi,
I'm having problems with lockups since I upgraded my memory to 1GB. I
have reason to suspect that the location of the SAREA (just above the
1GB level) is my problem. Does anyone know how to
I am im running debian unstable with 1.5 gb main mem, 64mb Radeon ddr
with no problems what so ever
adam edgar
On Tue, 2001-11-20 at 12:36, Keith Whitwell wrote:
Steve Bergman wrote:
Hi,
I'm having problems with lockups since I upgraded my memory to 1GB. I
have reason to suspect
Hi mach64 people!
I've successfully run glxgears on my laptop and I drew
a big smile on my
face when the fps were set at 220, compared to the 40
that were before.
Thanks to you all guys.
Spite of that, I know that there is work to be done,
so I'm voluteering to
give the help I can. I've just
All the people actively doing development have gotten docs directly from
ATI rather than through the xfree86/DRI project as I understand it.
That's how I got them, but I mentioned that I wanted to contribute to
xfree/DRI when I signed up with ATI. We've agreed to an NDA by accepting
the docs,
On Mon, 2001-11-19 at 12:40, M.G. Houtman wrote:
I was wondering, the driver status of the r128 driver says DPMS is supported,
but somehow I can only get the screen blanking to work (works automagically).
Whatever tool I try to use, my screen will never go standby or suspend.
Do you have
On Tuesday 20 November 2001 04:36 pm, you wrote:
Having said all that, the docs that I have (and most others I think) don't
really cover 3D operations (except for register listings). I'm not sure
if the DRI project has 3D documentation available for project members.
I don't think there's
On Tue, Nov 20, 2001 at 07:18:16PM -0500, Frank C. Earl wrote:
I don't think there's any more available from ATI than what we already have.
If memory serves, Gareth and John worked from the register docs and the 2D
coding info from the Programmer's guide.
Yep, that's correct. Had to
Hi there,
the last days I was amusing myself with finding out about the status
of the Matrox G450 _PCI_ w.r.t. to hw 3D support. The card is plugged
into an Alpha station (UP2000).
I ended up hacking the agpgart module to kind-of emulate an agp
chipset by using the iommu of the UP2000
On Tue, 20 Nov 2001, Dorin Lazar wrote:
Sorry to bother you again. I talked with the people from ATI - they said
that (and I quote)
Hello Dorin.
I noticed in your form you are doing work with Linux. We have provided the
necessary documents to the Xfree86 and DRI projects. In order
On 2001.11.21 07:27 Mike A. Harris wrote:
On Tue, 20 Nov 2001, Dorin Lazar wrote:
Sorry to bother you again. I talked with the people from ATI -
they said
that (and I quote)
Hello Dorin.
I noticed in your form you are doing work with Linux. We have
provided
the
necessary
801 - 900 of 46322 matches
Mail list logo
