Below you will find test binaries for nVidia PowerPC Linux support. If
the files are not present in the directory, please try again later as it
may take some time for them to propogate throughout the mirrors.
Test kernel:
ftp://ftp.yellowdoglinux.com/pub/yellowdog/users/ajoshi/vmlinux-nv
Also... you may need to replace your
/usr/X11R6/lib/modules/drivers/radeon_drv.o with
http://www.unixbox.com/~ajoshi/radeon_drv.o.bz2
ani
On Mon, 21 Jan 2002, Ani Joshi wrote:
>
> For those interested in testing Radeon DRI, I've placed a patch located at
> http://www.unixb
For those interested in testing Radeon DRI, I've placed a patch located at
http://www.unixbox.com/~ajoshi/radeon-dri.diff which whould patch cleanly
against recent Ben H.'s kernel. You must turn on AGPgart support, PCIgart
isn't done yet.
Also, you will need to replace your
/usr/X11R6/lib/module
Attatched is a patch which should apply to any recent 2.4 tree's
drivers/video/riva directory. This adds ppc/general big-endian support
for nVidia boards, and supports the GeForce2 MX found in Apple's new
machines. The rivafb driver currently does not support the GeForce3 so if
you Mac has that
I've placed another test kernel named "vmlinux-nvidia2" which fixes a few
bugs in the old kernel, it can be found at:
ftp://ftp.yellowdoglinux.com/pub/yellowdog/software/nvidia-test
If the files are not present, then they have not propagated to the
mirrors, they will get there eventually.
There
On Thu, 21 Jun 2001, Michel [iso-8859-1] Dänzer wrote:
> Now, please enlighten me: Which Mac cards need to have the VGA mode saved?
All Mac Banshee, Voodoo3, and Voodoo5 boards for example.
> I beg to differ as everything works fine without it, but let's not start a
> fight about this.
I don'
Michel Danzer wrote:
> The problem is that the vgaHW layer now tries to do ISA I/O using a new
> syscall to get the iobase. Unfortunately, it doesn't seem to work on
> UniNorth
> machines. For now you'll have to either use Option "UseFBDev" or hack the
> syscall (something with sysconfig_iobase)
I've recently fixed the annoying Radeon engine init problem and placed a
patch against XFree86 4.1.0 radeon driver and a binary radeon_drv driver
at:
ftp://ftp.linuxppc.org/users/ajoshi/radeon
The binary driver can be unzipped and placed in
/usr/X11R6/lib/modules/drivers/ along with ati_drv.o.
Y
On Wed, 20 Jun 2001, Kostas Gewrgiou wrote:
> I think that the crash in vgaHW is because of isa mem accesses, if this is
> the case a better fix will be to mmap the right memory range for the
> machines that have one and to handle the lack of one in pmacs.
The crash is in readDacData, which rea
On Wed, 20 Jun 2001, Michel [iso-8859-1] Dänzer wrote:
> You're talking about the status quo, Kostas about the way it should be. Just
> because it's not like that now doesn't mean we don't have to care about it
> anymore.
If he's talking about "the way it should be", then totally removing all
f
On Wed, 20 Jun 2001, Kostas Gewrgiou wrote:
> The #ifdef __powerpc__ isn't right (and we can't use os specific
> code in the drivers) so the fix has to go in another layer,
> crippling another os to fix our problems isn't the right solution.
Well, that's not really true. There's already lots o
On Tue, 19 Jun 2001, Michel [iso-8859-1] Dänzer wrote:
>
> That would be nice, unfortunately it doesn't. For the record, here's the patch
> against xf-4_1-branch I tested:
Please try the attached patch. This fixes the problem on PCI machines and
could possibly fix yours too.
It is against th
Michel,
I looked into the situation and found out why its crashing on your
machine. The vgaHW pointer is not setting the IOBase, so when it tries to
read that it crashes. Do this in r128_driver.c:
after the hwrec is alloced (vgaHWGetHWRec())
{
vgaHWPtr hwp;
vgaHWGetIOBase(hw
On Sat, 2 Jun 2001, Michel [ISO-8859-1] Dänzer wrote:
> I might do that, but then is there any benefit of vgaHW working on a Mac? It
> seems to work fine without, so I might as well hack the syscall to fail.
Yes, vgaHW is very much indeed needed on Mac (or pretty much any
platform). For boards
On Fri, 1 Jun 2001, Kostas Gewrgiou wrote:
> > __NR_pciconfig_iobase
> >
> > Another approach might be to make it only return an ioBase for known working
> > configurations, is that feasible?
>
> We need a way to use multiple ioBases from inside xfree to fix the problem.
> The best solution will
Wrong, its not that I "can't" seem to get the modifications in the tree,
its because I haven't even submitted them yet. I'm waiting for feedback
from some users before I do that, and that will only happen before the
next release. I don't have time to keep updating my tree with CVS all day
to ple
I recently ran into an issue with the matroxfb driver and XFree86 4.0.2's
matrox driver. Sometime in the past someone decided to use BE
register access in matroxfb for BE machines, while this is probably The
Right Way, it produces problems in X. I can use BE register access
macro's in X but it w
I have recently updated my XFree86 tree to 4.0.2 with my updated
drivers. Here are some notes which will be usefull:
* Accelerated drivers which are now "ppc safe" in my tree include:
ATI Mach64
ATI Rage128/Pro/Mobility
3Dfx Banshee
3Dfx Voodoo3
3Dfx Voodoo
With XFree86 4.x development speeding up, I have placed an rsync tree of
my xfree86/ tree. This rsync tree can be grabbed with:
rsync -arvz penguinppc.org::xfree86-pmac .
This tree contains the 'bleeding edge' development server and drivers for
XFree86 4.x. Included are my development Mach64,
On Tue, 20 Jun 2000, Michael Schmitz wrote:
> > I don't know, I didn't have to apply any kernel patches for my machine.
>
> What kernel version do you run?
2.3.99pre9, and occasionaly 2.2.4, both had no problems with fbdev nor ati
driver.
ani
On Mon, 19 Jun 2000, Michel [iso-8859-1] Dänzer wrote:
> If you happen to have a 4.0b version of the driver (what version is the one in
> your FTP dir?), I'd be happy to make it available for people to test with my
> experimental tarballs.
The driver currently in my dir on devel is from a 4.0d
On Fri, 12 May 2000, Kevin Puetz wrote:
> (I don't know what kind of licenses you are bound by, if no say no).
> Especially nice would be to rebuild Michel Dänzer <[EMAIL PROTECTED]>'s
> debs from http://n.ethz.ch/student/daenzerm/download/XFree86/4.0/ with
> experimental mach64, but I'll ta
On Fri, 12 May 2000, Wilhelm Fitzpatrick wrote:
> How does XFree86 4.0 on the ct6555x chipset (aka PB2400/3400) stack up
> against Xpmac?
I have no clue, as I don't own any chips hardware. Stock 4.0 won't work
on PPC, but as I said a few messages ago in this thread, I'll try and hack
in ppc s
On Fri, 12 May 2000, Kevin Puetz wrote:
>
> [EMAIL PROTECTED] said:
> > No, everyone should *not* use 4.0 yet, at least those with Mach64
> > chipsets. the ATI driver in the stock 4.0 source does not work on
> > ppc, I have added PPC support and will get it into 4.01 if i get some
> > more fre
On Fri, 12 May 2000, Adam C Powell IV wrote:
> Really? I seem to be the only one having trouble with accel Xfb-atyfb in 3.3,
> and thought that the 4.0 fb backend does not yet have accel...
>
No, everyone should *not* use 4.0 yet, at least those with Mach64
chipsets. the ATI driver in the st
On Wed, 10 May 2000, Adam C Powell IV wrote:
>* clgenfb doesn't start on PPC, it oopses in vga16_init (after
> guessing the board has 32 MB RAM when it has 4). I've sent the
> ksymoops output to linux-fbdev, so the author is aware of the
> problem. Built as a module, insmod
26 matches
Mail list logo
