Try the attatched patch, this changes the matroxfb kernel driver to use LittleEndian register access instead of big, thus maintaining conformity with the majority of other fbdev drivers (and not having to make changes to the X driver most importantly).
This should fix all your 16 and 24 depth problems. I didn't try the "UseFBDev" option but you should be fine without it. I'll see to it this time the matroxfb maintiner gets this. ani On Fri, 19 Oct 2001, Romain Dolbeau wrote: > Romain Dolbeau wrote: > > > I've trouble getting a Millenium (2064W) to work on linux/ppc. The board > > is a regular PC millenium flashed with the latest Mac BIOS ; it works in > > MacOS and properly register in OpenFirmare (/proc/device-tree). > > I forgot to mention that I was using 4.1.0 from Debian Woody (labeled in > Debian as 4.1.0-7, so there's some additional fixes I suppose). > > I tried again, this time from a serial console, with two differents > kernels, one without (as before) and one with the matrox framebuffer > driver. result : > > 1) no FB support, NoAccel : 8 bits has 4 pixels columns mirrored, 24 > bits seems fine. > > 2) FB support, NoAccel : 8 bits seems fine, 24 bits is yellow > > 3) Accel, with or without FB: nothing is displayed except HW cursor, X > enter a busy loop (100% cpu). Connection from client are OK but nothing > is displayed. > > 4) FB support, with UseFBDev and NoAccel : second try lock-up hard the > box > > The only suspicious thing to me in the log is one line that read > something like "(==) MGA(0) Using AGP 1x mode" - but the box doesn't > have AGP, and the chipset mga2064W was never used on AGP, only PCI. It > seems related to DRI (correctly disabled in the log), is it just a > spurious message ? > > I can supply the config file and log file(s) if necessary. > > Any help/comments/advices/status of the Matrox cards on big-endian > systems welcome. > > -- > DOLBEAU Romain | Brothers of Metal will always be there > ENS Cachan / Ker Lann | Standing together with hands in the air > Thesard IRISA / CAPS | -- Manowar, > [EMAIL PROTECTED] | 'Brothers of Metal' > _______________________________________________ > Xpert mailing list > [EMAIL PROTECTED] > http://XFree86.Org/mailman/listinfo/xpert >
--- matrox.orig/matroxfb_base.h Fri Oct 19 14:27:58 2001 +++ matrox/matroxfb_base.h Fri Oct 19 14:43:13 2001 @@ -108,12 +108,11 @@ #endif #endif -#if defined(__alpha__) || defined(__m68k__) +#if defined(__alpha__) || defined(__m68k__) || defined(__powerpc__) #define READx_WORKS #define MEMCPYTOIO_WORKS #else #define READx_FAILS -/* recheck __ppc__, maybe that __ppc__ needs MEMCPYTOIO_WRITEL */ /* I benchmarked PII/350MHz with G200... MEMCPY, MEMCPYTOIO and WRITEL are on same speed ( <2% diff) */ /* so that means that G200 speed (or AGP speed?) is our limit... I do not have benchmark to test, how */ /* much of PCI bandwidth is used during transfers... */ @@ -765,7 +764,12 @@ #define M_OPMODE_32BPP (M_OPMODE_DMA_LE | M_OPMODE_DIR_LE | M_OPMODE_DMA_BLIT) #else #ifdef __BIG_ENDIAN +#if defined(__powerpc__) +/* we use little endian register access on ppc, but big endian framebuffer */ +#define MX_OPTION_BSWAP 0x00000000 +#else #define MX_OPTION_BSWAP 0x80000000 +#endif #define M_OPMODE_4BPP (M_OPMODE_DMA_LE | M_OPMODE_DIR_LE | M_OPMODE_DMA_BLIT) /* TODO */ #define M_OPMODE_8BPP (M_OPMODE_DMA_BE_8BPP | M_OPMODE_DIR_BE_8BPP | M_OPMODE_DMA_BLIT)
