From: Petr Vandrovec <hidden> Date: 2001-01-24 20:44:49
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/
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/
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 :(
quoted
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/
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/
From: Michel D�nzer <hidden> Date: 2001-01-25 13:02:30
Kostas Gewrgiou wrote:
On Thu, 25 Jan 2001, Geert Uytterhoeven wrote:
quoted
On Thu, 25 Jan 2001, Kostas Gewrgiou wrote:
quoted
quoted
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/