Hello all,
I'm wondering what the status of linux support for Radeon chipsets on
PPC is. All i've been able to find on the web is that it might work with
XFree86 4.1.0 with some patches, and that XFree86 4.2 should support it.
I'm thinking about getting one of the new model titanium Powerbooks wi
Cool. Thanks, that's a big improvement! I suspect that this may have to
do with texture blending modes. I have a simple OpenGL app that I've been
working on and texture mapping and blending are not working properly yet.
I think there's still some work to be done in the Mesa driver for mach64
Leif,
I've managed to solve that same problem by leaving
"NoLighting=False" and
changing "UseMultiTexture=0".
Fortunatly we can get the source for the
OpenGLDrv at http://openut.sourceforge.net . I'm sure
that that will help
us find the "source" of these problems...
Regards,
Jose Fonseca
On 2
On Sat, Dec 01, 2001 at 01:17:16PM -0700, Brian Paul wrote:
> Keith Whitwell wrote:
> >
> > Jorge Luis Williams wrote:
> > >
> > > Hello,
> > >
> > > I've run into what appears to be a dead-lock while running tessellation
> > > demo by David Blythe which is included in the Glut-3.7 source
> > > d
On Mon, 3 Dec 2001, Zephaniah E. Hull wrote:
> On Mon, Dec 03, 2001 at 03:09:13PM -0500, Leif Delgass wrote:
> > I get the garbled pointer in UT too. Also, the only way I can get
> > wall/ceiling/floor textures to show up is by disabling lighting altogether
> > (with "NoLighting=True" under [SDL
On Mon, Dec 03, 2001 at 03:09:13PM -0500, Leif Delgass wrote:
> I get the garbled pointer in UT too. Also, the only way I can get
> wall/ceiling/floor textures to show up is by disabling lighting altogether
> (with "NoLighting=True" under [SDLDrv.SDLClient]). Otherwise I just get
> white instead
On Mon, 3 Dec 2001, Leif Delgass wrote:
> On Mon, 3 Dec 2001, Otto E Solares wrote:
>
> > On Mon, Dec 03, 2001 at 03:09:13PM -0500, Leif Delgass wrote:
> > > I get the garbled pointer in UT too. Also, the only way I can get
> > > wall/ceiling/floor textures to show up is by disabling lighting a
On Mon, 3 Dec 2001, Otto E Solares wrote:
> On Mon, Dec 03, 2001 at 03:09:13PM -0500, Leif Delgass wrote:
> > I get the garbled pointer in UT too. Also, the only way I can get
> > wall/ceiling/floor textures to show up is by disabling lighting altogether
> > (with "NoLighting=True" under [SDLDrv
I get the garbled pointer in UT too. Also, the only way I can get
wall/ceiling/floor textures to show up is by disabling lighting altogether
(with "NoLighting=True" under [SDLDrv.SDLClient]). Otherwise I just get
white instead of textures. I had the same thing with q3demo until I set
lighting t
On Mon, 2001-12-03 at 17:38, Sergey V. Udaltsov wrote:
> > fine. Unless you tell me I also don't have access to a Windows computer
> > with 500 Mb free.. :)
> :) OK. I am convinced.
>
> > I'm not sure. I think that about 20Mb... for the sources. (I don't have
> > my laptop with me so I can't giv
> fine. Unless you tell me I also don't have access to a Windows computer
> with 500 Mb free.. :)
:) OK. I am convinced.
> I'm not sure. I think that about 20Mb... for the sources. (I don't have
> my laptop with me so I can't give precise figures. Anyway just give a
> look in the size of XFree 4
On Mon, 2001-12-03 at 16:24, Sergey V. Udaltsov wrote:
> > As far as I know this is not so simple as a X server and libs. You also
> > have the kernel modules... and those are tied to the kernel version &
> > configuration you have.
> AFAIR there is a way to build kernel modules without precise ke
> As far as I know this is not so simple as a X server and libs. You also
> have the kernel modules... and those are tied to the kernel version &
> configuration you have.
AFAIR there is a way to build kernel modules without precise kernel
version dependance (correct me if I am wrong) - as long as
Alan Hourihane wrote:
> I need the output from the loading of the drm module to when these
> *ERROR*'s started.
Here it is, all un-edited.
[drm] AGP 0.99 on Intel i815 @ 0xe400 64MB
[drm] Initialized r128 2.1.6 20010405 on minor 0
uhci.c: USB Universal Host Controller Interface driver v1.
As far as I know this is not so simple as a X server and libs. You also
have the kernel modules... and those are tied to the kernel version &
configuration you have.
If the problem you have is hard disk space (you need about 500 Mb) you
could try to build on a remote machine disk, mounted via sam
Hi all
It seems people are actively testing mach64 branch. So I have a couple
of questions:
1. Could anyone please periodically make binary snapshots including only
X server, necessary libs and little (~10 lines) readme?
2. Is mach64 driver binary compatible with XFree 4.1.0 or does it depend
on
On Mon, Dec 03, 2001 at 03:02:35PM +0100, Daniel Polombo wrote:
> Alan Hourihane wrote:
>
>
> >O.k. That looks good. What does the last 10 or so lines of 'dmesg' say ?
>
> I'm not sure this is what you want, but :
>
I need the output from the loading of the drm module to when these
*ERROR*'s s
I'm aware that I don't have much memory. I'm running it at 640x480x16
otherwise DRI would be disabled because it preallocates 3x the virtual
screen size and that would be too much for higher resolutions. But I
don't think that insufficient is the reason for this behavior:
* This happens not only d
Alan Hourihane wrote:
> O.k. That looks good. What does the last 10 or so lines of 'dmesg' say ?
I'm not sure this is what you want, but :
[drm:r128_cce_vertex] *ERROR* process 27792 using buffer owned by 0
[drm:r128_cce_vertex] *ERROR* process 28769 using buffer owned by 0
[drm:r128_cce_verte
On Mon, Dec 03, 2001 at 02:34:56PM +0100, Daniel Polombo wrote:
> Alan Hourihane wrote:
>
>
> >Then we need to see the full /var/log/XFree86.0.log file.
>
> Here it comes (attached).
>
O.k. That looks good. What does the last 10 or so lines of 'dmesg' say ?
Alan.
Alan Hourihane wrote:
> Then we need to see the full /var/log/XFree86.0.log file.
Here it comes (attached).
--
Daniel
This is a pre-release version of XFree86, and is not supported in any
way. Bugs may be reported to [EMAIL PROTECTED] and patches submitted
to [EMAIL PROTECTED] Before repo
On Mon, Dec 03, 2001 at 02:11:33PM +0100, Daniel Polombo wrote:
> Alan Hourihane wrote:
>
>
> >Sounds like your kernel driver isn't uptodate.
> >
> >If you type 'dmesg' to look at the kernel messages the r128 kernel
> >module should identify itself as version 2.1.6.
>
> Looks good to me :
>
>
On Mon, 2001-12-03 at 14:11, Daniel Polombo wrote:
> Alan Hourihane wrote:
>
>
> > Sounds like your kernel driver isn't uptodate.
> >
> > If you type 'dmesg' to look at the kernel messages the r128 kernel
> > module should identify itself as version 2.1.6.
>
> Looks good to me :
>
>ambre
Alan Hourihane wrote:
> Sounds like your kernel driver isn't uptodate.
>
> If you type 'dmesg' to look at the kernel messages the r128 kernel
> module should identify itself as version 2.1.6.
Looks good to me :
ambre:~$ dmesg | grep -i r128
[drm] Initialized r128 2.1.6 20010405 on mino
On Mon, Dec 03, 2001 at 01:40:12PM +0100, Daniel Polombo wrote:
> Michel Dänzer wrote:
>
>
> >The X server and its modules are in xserver-xfree86. If reinstalling
> >that doesn't fix this, you have a non-distribution X which is picked up.
>
>
> There was indeed an X11R6-DRI in which some thing
Michel Dänzer wrote:
> The X server and its modules are in xserver-xfree86. If reinstalling
> that doesn't fix this, you have a non-distribution X which is picked up.
There was indeed an X11R6-DRI in which some things were picked up, including
the wrong XFree86. I fixed that, and now the X se
I've been testing the mach64-0-02-branch on my laptop (ATI Mobility 4Mb)
and in Unreal a semi-transparent garbled sprite appears on the middle of
the screen - it's the hw cursor that wasn't properly erased because this
behavior disappears when the X server is started with the 'sw_cursor'.
This ap
On Mon, 2001-12-03 at 12:27, Daniel Polombo wrote:
> XFree86 Version 4.0.99.3 / X Window System
> (protocol Version 11, revision 0, vendor release 6510)
> Release Date: 26 April 2001
>
> (II) Loading /usr/X11R6/lib/modules/extensions/libdri.a
> (II) Module dri: vendor="The XFree86 Proj
Michel Dänzer wrote:
> What's the kernel message printed when loading the module, in particular
> the version? The only thing I could think of is that you're using an
> Alan Cox kernel and have configured it for the wrong XFree86 version or
> something.
I've tried with 2.4.9-ac11, but the DRI
>
>I've manualy imported the fix in mesa-4-0-branch
>and it works fine without fbdev. Radeonfb is buggy, so I didn't try
>that yet.
I submited Michel patch along with another fix for UseFBDev mode
with readeon to the XFree main CVS yesterday. It works fine if you
have the latest bug fixed radeon
30 matches
Mail list logo