Re: [linux-fbdev] Matrox and XFree86 4.0.2 update

Re: [linux-fbdev] Matrox and XFree86 4.0.2 update

[Petr Vandrovec]

On 24 Jan 01 at 11:11, Ani Joshi wrote:

> 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 was causing problems with the engine, perhaps some DMA
> issue although the dma BE bits are on.

Using big-endian on PPC was required by PPC users for compatibility with
existing XF[86][68]_FBDev servers. Are you sure that there are no problems
otherwise, and that it works correctly on all PReP/CHRP/???? architectures?

And I think that matroxfb should return current driver's endianess to
userspace... Do we have some spare bits in fb_fix_info?
                                            Thanks,
                                                Petr Vandrovec
                                                vandrove@vc.cvut.cz


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: [linux-fbdev] Matrox and XFree86 4.0.2 update

[Kostas Gewrgiou]

On Wed, 24 Jan 2001, Petr Vandrovec wrote:

>
> On 24 Jan 01 at 11:11, Ani Joshi wrote:
>
> > 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 was causing problems with the engine, perhaps some DMA
> > issue although the dma BE bits are on.
>
> Using big-endian on PPC was required by PPC users for compatibility with
> existing XF[86][68]_FBDev servers. Are you sure that there are no problems
> otherwise, and that it works correctly on all PReP/CHRP/???? architectures?

Nope it won't cause any problems, none of the XF[86][68]_FBDev servers where
accelerated for matrox, other libs (SDL etc) that have accel for matroxfb
don't work correctly for ppc either.

Changing the endian to little is the *right* thing, big-endian mode doesn't
offer us anything beyond problems in matroxfb 8/16 bit accesses become a
nightmare there...

  Kostas


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: [linux-fbdev] Matrox and XFree86 4.0.2 update

[Geert Uytterhoeven]

On Thu, 25 Jan 2001, Kostas Gewrgiou wrote:
> On Wed, 24 Jan 2001, Petr Vandrovec wrote:
> > On 24 Jan 01 at 11:11, Ani Joshi wrote:
> > > 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 was causing problems with the engine, perhaps some DMA
> > > issue although the dma BE bits are on.
> >
> > Using big-endian on PPC was required by PPC users for compatibility with
> > existing XF[86][68]_FBDev servers. Are you sure that there are no problems
> > otherwise, and that it works correctly on all PReP/CHRP/???? architectures?
>
> Nope it won't cause any problems, none of the XF[86][68]_FBDev servers where
> accelerated for matrox, other libs (SDL etc) that have accel for matroxfb
> don't work correctly for ppc either.

XF68_FBDev is accelerated for matroxfb, at least on the PPC platform.

> Changing the endian to little is the *right* thing, big-endian mode doesn't
> offer us anything beyond problems in matroxfb 8/16 bit accesses become a
> nightmare there...

8/16 bit accesses? I assume you're talking about the frame buffer, not about
the register accesses?

Currently XF68_FBDev needs a big-endian frame buffer on big-endian machines.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: [linux-fbdev] Matrox and XFree86 4.0.2 update

[Kostas Gewrgiou]

On Thu, 25 Jan 2001, Geert Uytterhoeven wrote:

> On Thu, 25 Jan 2001, Kostas Gewrgiou wrote:
> > On Wed, 24 Jan 2001, Petr Vandrovec wrote:
> >
> > Nope it won't cause any problems, none of the XF[86][68]_FBDev servers where
> > accelerated for matrox, other libs (SDL etc) that have accel for matroxfb
> > don't work correctly for ppc either.
>
> XF68_FBDev is accelerated for matroxfb, at least on the PPC platform.

Ops i forgot about it, it will be easy to change it though, although
backwards compatibility will be a nightmare :(

> > Changing the endian to little is the *right* thing, big-endian mode doesn't
> > offer us anything beyond problems in matroxfb 8/16 bit accesses become a
> > nightmare there...
>
> 8/16 bit accesses? I assume you're talking about the frame buffer, not about
> the register accesses?

No i am talking about register accesses, for example
the mga driver in xfree86 uses
 #define MGAISBUSY() (INREG8(MGAREG_Status + 2) & 0x01)
SDL uses
 #define mga_wait(space)  {                                             \
        while ( mga_in8(MGAREG_FIFOSTATUS) < space );                   \
 }

Both will fail under big-endian mode in PPC, the addressing is changed
so you have to use something like *(addr + (3-addr%4) to get the right
byte (i hope i got it right, its still early here)

> Currently XF68_FBDev needs a big-endian frame buffer on big-endian machines.

And i don't expect it to change ;P

 Kostas


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: [linux-fbdev] Matrox and XFree86 4.0.2 update

[Michel Dänzer]

Kostas Gewrgiou wrote:
>
> On Thu, 25 Jan 2001, Geert Uytterhoeven wrote:
>
> > On Thu, 25 Jan 2001, Kostas Gewrgiou wrote:
>
> > > Changing the endian to little is the *right* thing, big-endian mode
> > > doesn't offer us anything beyond problems in matroxfb 8/16 bit accesses
> > > become a nightmare there...
> >
> > 8/16 bit accesses? I assume you're talking about the frame buffer, not
> > about the register accesses?
>
> No i am talking about register accesses, for example
> the mga driver in xfree86 uses
>  #define MGAISBUSY() (INREG8(MGAREG_Status + 2) & 0x01)
> SDL uses
>  #define mga_wait(space)  {                                             \
>         while ( mga_in8(MGAREG_FIFOSTATUS) < space );                   \
>  }
>
> Both will fail under big-endian mode in PPC, the addressing is changed
> so you have to use something like *(addr + (3-addr%4) to get the right
> byte (i hope i got it right, its still early here)

What about adapting the macros then?


Michel


--
Earthling Michel Dänzer (MrCooper)    \   Debian GNU/Linux (powerpc) developer
CS student, Free Software enthusiast   \        XFree86 and DRI project member

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: [linux-fbdev] Matrox and XFree86 4.0.2 update

[Tom Rini]

On Thu, Jan 25, 2001 at 12:38:25PM +0100, Geert Uytterhoeven wrote:
> On Thu, 25 Jan 2001, Kostas Gewrgiou wrote:
> > On Wed, 24 Jan 2001, Petr Vandrovec wrote:
> > > On 24 Jan 01 at 11:11, Ani Joshi wrote:
> > > > 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 was causing problems with the engine, perhaps some DMA
> > > > issue although the dma BE bits are on.
> > >
> > > Using big-endian on PPC was required by PPC users for compatibility with
> > > existing XF[86][68]_FBDev servers. Are you sure that there are no problems
> > > otherwise, and that it works correctly on all PReP/CHRP/???? architectures?
> >
> > Nope it won't cause any problems, none of the XF[86][68]_FBDev servers where
> > accelerated for matrox, other libs (SDL etc) that have accel for matroxfb
> > don't work correctly for ppc either.
>
> XF68_FBDev is accelerated for matroxfb, at least on the PPC platform.

Er, it is?  I thought only Xpmac was...

> > Changing the endian to little is the *right* thing, big-endian mode doesn't
> > offer us anything beyond problems in matroxfb 8/16 bit accesses become a
> > nightmare there...

Just my thoughts on this, but the matrox+ppc camp is relativly small (Yes, I
know some chrps which now work have 'em) and since I'm guessing (Ani, can you
benchmark some of this? :)) XF4 is faster than Xpmac, putting this in now,
with a toggle bit for people that really don't wanna upgrade to X4, and removing
the toggle in 2.5..  It should be an overall win.

--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: [linux-fbdev] Matrox and XFree86 4.0.2 update

[Geert Uytterhoeven]

On Thu, 25 Jan 2001, Tom Rini wrote:
> On Thu, Jan 25, 2001 at 12:38:25PM +0100, Geert Uytterhoeven wrote:
> > On Thu, 25 Jan 2001, Kostas Gewrgiou wrote:
> > > On Wed, 24 Jan 2001, Petr Vandrovec wrote:
> > > > On 24 Jan 01 at 11:11, Ani Joshi wrote:
> > > > > 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 was causing problems with the engine, perhaps some DMA
> > > > > issue although the dma BE bits are on.
> > > >
> > > > Using big-endian on PPC was required by PPC users for compatibility with
> > > > existing XF[86][68]_FBDev servers. Are you sure that there are no problems
> > > > otherwise, and that it works correctly on all PReP/CHRP/???? architectures?
> > >
> > > Nope it won't cause any problems, none of the XF[86][68]_FBDev servers where
> > > accelerated for matrox, other libs (SDL etc) that have accel for matroxfb
> > > don't work correctly for ppc either.
> >
> > XF68_FBDev is accelerated for matroxfb, at least on the PPC platform.
>
> Er, it is?  I thought only Xpmac was...

I just checked the Debian binary, and indeed it isn't. IIRC patches existed a
few years ago.

Hmmm, I just noticed I'm not using the potato XF68_FBDev but some other special
3.3.4 version called XF68_FBDev.15bppOK (dated aug 1999), which I probably
compiled myself. It works with `DefaultColorDepth 15', while the Debian 3.3.6
variant doesn't work in depth 15, only in depth 16.

In other words: it looks like the fixes to make depth 15 (which is correct, bpp
is 16) work never made it into the official release...

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: [linux-fbdev] Matrox and XFree86 4.0.2 update

[Tom Rini]

On Fri, Jan 26, 2001 at 09:21:59AM +0100, Geert Uytterhoeven wrote:

> I just checked the Debian binary, and indeed it isn't. IIRC patches existed a
> few years ago.

They did/do exist, but were never completed.  Same person who did the matrox
accel for Xpmac (and who's name slips my mind right now..)

So can we "break" matroxfb and me it use LE?  (And, just a thought, this
could be dependant on Xpmac compat or not, because Xpmac will choke on
an LE matrox I'm gonna guess...

--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/