XFree86 on mips cleanup patch

2001-07-25 Thread Guido Guenther

Hi,
the attached patch removes some previous workarounds by adding proper
functions to compiler.h for mips(el). This obsoletes the disabling of
the ati driver on mips(351) and the int10 module(350) on mipsel as well
as the mem_barrier patch(353). I've also attached the newport range fix
for completeness - both are against pre5. So these should be the only
patches needed to get XFree86 going on mips/mipsel for now.
 -- Guido


--- xc/programs/Xserver/hw/xfree86/common/compiler.h.orig   Tue Jul 24 22:33:42 
2001
+++ xc/programs/Xserver/hw/xfree86/common/compiler.hTue Jul 24 22:37:37 2001
@@ -862,6 +862,67 @@
return r1;
 }
 
+#ifdef linux   /* don't mess with other OSs */
+
+/*
+ * EGCS 1.1 knows about arbitrary unaligned loads (and we don't support older
+ * versions anyway. Define some packed structures to talk about such things
+ * with.
+ */
+
+struct __una_u32 { unsigned int   x __attribute__((packed)); };
+struct __una_u16 { unsigned short x __attribute__((packed)); };
+
+static __inline__ void stw_u(unsigned long val, unsigned short *p)
+{
+   struct __una_u16 *ptr = (struct __una_u16 *) p;
+   ptr-x = val;
+}
+
+static __inline__ void stl_u(unsigned long val, unsigned int *p)
+{
+   struct __una_u32 *ptr = (struct __una_u32 *) p;
+   ptr-x = val;
+}
+
+#if X_BYTE_ORDER == X_BIG_ENDIAN
+static __inline__ unsigned int
+xf86ReadMmio32Be(__volatile__ void *base, const unsigned long offset)
+{
+   unsigned long addr = ((unsigned long)base) + offset;
+   unsigned int ret;
+
+   __asm__ __volatile__(lw %0, 0(%1)
+: =r (ret)
+: r (addr));
+   return ret;
+}
+
+static __inline__ void
+xf86WriteMmio32Be(__volatile__ void *base, const unsigned long offset,
+ const unsigned int val)
+{
+   unsigned long addr = ((unsigned long)base) + offset;
+
+   __asm__ __volatile__(sw %0, 0(%1)
+: /* No outputs */
+: r (val), r (addr));
+}
+#endif
+
+#define mem_barrier() \
+__asm__ __volatile__(  \
+   # prevent instructions being moved around\n\t \
+   .set\tnoreorder\n\t   \
+   # 8 nops to fool the R4400 pipeline\n\t   \
+   nop;nop;nop;nop;nop;nop;nop;nop\n\t   \
+   .set\treorder \
+   : /* no output */   \
+   : /* no input */\
+   : memory)
+#define write_mem_barrier() mem_barrier()
+
+#else  /* !linux */
 #define stq_u(v,p) stl_u(v,p)
 #define stl_u(v,p) (*(unsigned char *)(p)) = (v); \
(*(unsigned char *)(p)+1) = ((v)  8);  \
@@ -872,6 +934,7 @@
(*(unsigned char *)(p)+1) = ((v)  8)
 
 #define mem_barrier()   /* NOP */
+#endif /* !linux */
 #endif /* __mips__ */
 
 #if defined(__arm32__)


--- xc/programs/Xserver/hw/xfree86/drivers/newport/newport_driver.c.origThu 
Jul 19 14:53:15 2001
+++ xc/programs/Xserver/hw/xfree86/drivers/newport/newport_driver.c Thu Jul 19 
+14:53:29 2001
@@ -247,7 +247,7 @@
entity = xf86ClaimIsaSlot(drv, 0, dev, TRUE);
base = (NEWPORT_BASE_ADDR0 + busID * 
NEWPORT_BASE_OFFSET);
RANGE(range[0], base, base + 
sizeof(NewportRegs),\
-   ResExcMemBlock);
+   ResExcMemBlock,0);
pScrn = xf86ConfigIsaEntity(pScrn, 0, entity, 
NULL, range, \
NULL, NULL, NULL, NULL);
/* Allocate a ScrnInfoRec */



Re: XFree86 on mips cleanup patch

2001-07-25 Thread Ben Collins

On Wed, Jul 25, 2001 at 09:38:13PM +0200, Guido Guenther wrote:
 Hi,
 the attached patch removes some previous workarounds by adding proper
 functions to compiler.h for mips(el). This obsoletes the disabling of
 the ati driver on mips(351) and the int10 module(350) on mipsel as well
 as the mem_barrier patch(353). I've also attached the newport range fix
 for completeness - both are against pre5. So these should be the only
 patches needed to get XFree86 going on mips/mipsel for now.
  -- Guido

Are the below asm functions going to affect other architectures? I don't
see them wrapped in any sort of arch specific defines.

 +#if X_BYTE_ORDER == X_BIG_ENDIAN
 +static __inline__ unsigned int
 +xf86ReadMmio32Be(__volatile__ void *base, const unsigned long offset)
 +{
 + unsigned long addr = ((unsigned long)base) + offset;
 + unsigned int ret;
 +
 + __asm__ __volatile__(lw %0, 0(%1)
 +  : =r (ret)
 +  : r (addr));
 + return ret;
 +}
 +
 +static __inline__ void
 +xf86WriteMmio32Be(__volatile__ void *base, const unsigned long offset,
 +   const unsigned int val)
 +{
 + unsigned long addr = ((unsigned long)base) + offset;
 +
 + __asm__ __volatile__(sw %0, 0(%1)
 +  : /* No outputs */
 +  : r (val), r (addr));
 +}
 +#endif


 +__asm__ __volatile__(\
 + # prevent instructions being moved around\n\t \
 + .set\tnoreorder\n\t   \
 + # 8 nops to fool the R4400 pipeline\n\t   \
 + nop;nop;nop;nop;nop;nop;nop;nop\n\t   \
 + .set\treorder \
 + : /* no output */   \
 + : /* no input */\
 + : memory)
 +#define write_mem_barrier() mem_barrier()


-- 
 ---===-=-==-=---==-=--
/  Ben Collins  --  ...on that fantastic voyage...  --  Debian GNU/Linux   \
`  [EMAIL PROTECTED]  --  [EMAIL PROTECTED]  --  [EMAIL PROTECTED]  '
 `---=--===-=-=-=-===-==---=--=---'


--  
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]




Re: XFree86 on mips cleanup patch

2001-07-25 Thread Branden Robinson

On Wed, Jul 25, 2001 at 05:51:00PM -0400, Ben Collins wrote:
 Are the below asm functions going to affect other architectures?

No.

 I don't see them wrapped in any sort of arch specific defines.

Because this patch is already inside just such an #if.

See c. line 787 of xc/programs/Xserver/hw/xfree86/common/compiler.h in your
local unpacked source tree.

-- 
G. Branden Robinson|  Somebody once asked me if I thought sex
Debian GNU/Linux   |  was dirty.  I said, It is if you're
[EMAIL PROTECTED] |  doing it right.
http://people.debian.org/~branden/ |  -- Woody Allen

 PGP signature


Re: XFree86 on mips cleanup patch

2001-07-25 Thread Stephen Frost

* Ben Collins ([EMAIL PROTECTED]) wrote:
 On Wed, Jul 25, 2001 at 09:38:13PM +0200, Guido Guenther wrote:
  Hi,
  the attached patch removes some previous workarounds by adding proper
  functions to compiler.h for mips(el). This obsoletes the disabling of
  the ati driver on mips(351) and the int10 module(350) on mipsel as well
  as the mem_barrier patch(353). I've also attached the newport range fix
  for completeness - both are against pre5. So these should be the only
  patches needed to get XFree86 going on mips/mipsel for now.
   -- Guido
 
 Are the below asm functions going to affect other architectures? I don't
 see them wrapped in any sort of arch specific defines.


+#endif /* !linux */
 #endif /* __mips__ */


Stephen

 PGP signature


Re: XFree86 on mips cleanup patch

2001-07-25 Thread Ben Collins

On Wed, Jul 25, 2001 at 06:38:58PM -0400, Stephen Frost wrote:
 * Ben Collins ([EMAIL PROTECTED]) wrote:
  On Wed, Jul 25, 2001 at 09:38:13PM +0200, Guido Guenther wrote:
   Hi,
   the attached patch removes some previous workarounds by adding proper
   functions to compiler.h for mips(el). This obsoletes the disabling of
   the ati driver on mips(351) and the int10 module(350) on mipsel as well
   as the mem_barrier patch(353). I've also attached the newport range fix
   for completeness - both are against pre5. So these should be the only
   patches needed to get XFree86 going on mips/mipsel for now.
-- Guido
  
  Are the below asm functions going to affect other architectures? I don't
  see them wrapped in any sort of arch specific defines.
 
 
 +#endif /* !linux */
  #endif /* __mips__ */
 

Ok, smack me with the blind stick. Sorry.

Ben

-- 
 ---===-=-==-=---==-=--
/  Ben Collins  --  ...on that fantastic voyage...  --  Debian GNU/Linux   \
`  [EMAIL PROTECTED]  --  [EMAIL PROTECTED]  --  [EMAIL PROTECTED]  '
 `---=--===-=-=-=-===-==---=--=---'


--  
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]




Re: Bug in Xgalaga?

2001-07-25 Thread Manuel Bilderbeek
Hi people,

Yesterday I installed kernel 2.4.6 (I used 2.2.17) and now Xgalaga does NOT
crash anymore! Also, a problem I had with XMMS (it did some fast-forwarding,
irratically) seems to be solved now.

An other problem with sound is the following: I only get sound when I do
this:
rmmod i810_audio
modprobe i810_audio

If I don't do this, I don't get errors, but I can't hear any sound...
With the previous kernel I had something similar, but then I got an error
(no such device) when playing with mpg123 for example. This was also solved
by removing and installing the module.

About X, I still can't get X to run on 1280x1024. In the XF86Config-4, I
deleted almost all modes, except 1280x1024 and it STILL switches to
1024x768. It should be possible to use that mode though (it works in Win2k
too (dual boot machine) and I have collegues with the same kind of hardware
(intel i810E chipset) on which it also works).

As Branden requested I am adding the contents of the requested files on the
bottom of this e-mail.

Grtjs, Manuel

PS: MSX 4 ever! (Questions? FAQ: http://www.faq.msxnet.org/ )
PPS: Visit my homepage: http://bilderbeek.cjb.net/

- Original Message -
From: Branden Robinson [EMAIL PROTECTED]
To: debian-x@lists.debian.org; [EMAIL PROTECTED]
Sent: Tuesday, July 24, 2001 4:19 PM
Subject: Re: Bug in Xgalaga?

On Tue, Jul 24, 2001 at 10:00:51AM +0200, Manuel Bilderbeek wrote:
  Well that's pretty suprising -- xgalaga is just a plain jane X app, and

Well, it's probably not *truly* plain jane, it probably uses some protocol
extensions.  :)

  it should not be able to hang the X server. This probably points to a
  bug in the X server or perhaps a hardware problem with your system.
  Perhaps the people on this list can help..

 Could be, I had some very troubling troubles getting X running. In fact,
 this was the reason I moved to Woody. I have an onboard Intel i810 chipset
 and I couldn't get Potato to work with it. So now I am running Xfree86
4.0.1
 with the i810 module. Maybe a bug in it, indeed?

 ANother problem is that I can't get it to work on 1280x1024... The X
server
 insists on going to 1024x768 ARGH...

 Does anyone have any hints to get this working?
 If so, please mail me privately, I'm not subscribed to the mailinglist.

Please email debian-user@lists.debian.org with the contents of the following
files:

/etc/X11/XF86Config-4
/var/log/XFree86.0.log

--
HERE COME THE FILES:
--
# XF86Config-4 (XFree86 server configuration file) generated by Dexconf, the
# Debian X Configuration tool, using values from the debconf database.
#
# Edit this file with caution, and see the XF86Config manual page.
# (Type man XF86Config at the shell prompt.)

Section Files
 FontPath unix/:7100   # local font server
 # if the local font server has problems, we can fall back on these
 FontPath /usr/lib/X11/fonts/misc
 FontPath /usr/lib/X11/fonts/cyrillic
 FontPath /usr/lib/X11/fonts/100dpi/:unscaled
 FontPath /usr/lib/X11/fonts/75dpi/:unscaled
 FontPath /usr/lib/X11/fonts/Type1
 FontPath /usr/lib/X11/fonts/Speedo
 FontPath /usr/lib/X11/fonts/100dpi
 FontPath /usr/lib/X11/fonts/75dpi
EndSection

Section ServerFlags
EndSection

Section Module
 Load ddc
 Load GLcore
 Load dbe
 Load dri
 Load extmod
 Load glx
 Load pex5
 Load record
 Load xie
 Load bitmap
 Load freetype
 Load speedo
 Load type1
 Load vbe
 Load int10
EndSection

Section InputDevice
 Identifier Generic Keyboard
 Driver  keyboard
 Option  CoreKeyboard
 Option  XkbRules xfree86
 Option  XkbModel pc104
 Option  XkbLayout us
EndSection

Section InputDevice
 Identifier Configured Mouse
 Driver  mouse
 Option  CorePointer
Option  Device  /dev/psaux
Option  Protocol  PS/2
 Option  Emulate3Buttons true
 Option  ZAxisMapping  4 5
EndSection

Section InputDevice
 Identifier Generic Mouse
 Driver  mouse
 Option  SendCoreEvents true
 Option  Device  /dev/input/mice
 Option  Protocol  ImPS/2
 Option  Emulate3Buttons true
 Option  ZAxisMapping  4 5
EndSection

Section Device
 Identifier Intel i810E
 Driver  i810
 VideoRam 4096
EndSection

Section Monitor
 Identifier Eizo
 HorizSync 30-96
 VertRefresh 50-160
 Option  DPMS
EndSection

Section Screen
 Identifier Default Screen
 Device  Intel i810E
 Monitor  Eizo
 DefaultDepth 24
Subsection Display
Depth   8
Modes   640x480 800x600 1024x768 1280x1024
ViewPort0 0
EndSubsection
Subsection Display
Depth   16
Modes   1280x1024
ViewPort0 0
EndSubsection
Subsection Display
Depth   24
Modes   1280x1024
 ViewPort0 0
EndSubsection
Subsection Display
Depth   32
Modes   640x480 800x600 1024x768
ViewPort0 0
EndSubsection
EndSection

Section ServerLayout
 Identifier Default Layout
 Screen  Default Screen
 InputDevice Generic Keyboard
 InputDevice Configured Mouse
 InputDevice Generic 

Re: Bug in Xgalaga?

2001-07-25 Thread Juliusz Chroboczek
MB Yesterday I installed kernel 2.4.6 (I used 2.2.17) and now Xgalaga does NOT
MB crash anymore!

Pity, twere good if we could debug this problem.  But it may simply be
a DRI version problem.

MB About X, I still can't get X to run on 1280x1024

[...]

MB (II) I810(0): Clock range:  12.00 to 136.00 MHz

[...]

MB (WW) I810(0): Default mode 1280x1024 deleted (bad mode 
clock/interlace/doublescan)

What it's telling you is that the mode you requested (called
1280x1024) uses a dot clock that is outside the clock range of your
video card.  There are two ways to get around the problem.

One would be simply to overclock your chip, i.e. tell the server to
disable its sanity checks.  This is dangerous, though, and judging
from what I know about the i810, is not very likely to give any results.

The other solution is to use a different mode, one which achieves the
same resolution with a lower dot clock either by reducing the refresh
frequency (horizontal or vertical), or by reducing the synch ranges.
Assuming you have a decent monitor, there is little or no possibility
of you doing any damage to it (this advice is given in good fait but
with no guarantee of any kind).  I suggest reading the
XFree86-Video-Timings-HOWTO, which will tell you everything you need
to know on the subject.

Note, by the way, that you did not specify a Modeline for 1280x1024,
so the server used one of its built-in ones.  Here are the ones that
concern you; they may be a useful starting point.

  # 1280x1024 @ 60Hz (VESA) hsync: 64.0kHz
  ModeLine 1280x1024 108.0 1280 1328 1440 1688   1024 1025 1028 1066 +hsync 
+vsync

  # 1280x1024 @ 75Hz (VESA) hsync: 80.0kHz
  ModeLine 1280x1024 135.0 1280 1296 1440 1688   1024 1025 1028 1066 +hsync 
+vsync

  # 1280x1024 @ 85Hz (VESA) hsync: 91.1kHz
  ModeLine 1280x1024 157.5 1280 1344 1504 1728   1024 1025 1028 1072 +hsync 
+vsync

Regards,

Juliusz




sparc X mozilla crash: negative sized edge and beziers this big

2001-07-25 Thread Adam Di Carlo

On sparc using the new(ish?) xserver-xfree86 4.1.0-0pre1v5, running
both skipstone and mozilla both result in X server crashes.

Skipstone reports:

  Fatal server error:
  Beziers this big not yet supported

Mozilla reports:

  Fatal server error:
  negative sized edge?

Is this a mozilla bug?  The fact that both browsers hit this make me
think so.

Other notes:

This only seems to cause problems on SPARC; same versions more or less
on i386 or PowerPC works fine.

This is not new to xserver-xfree86 4.1.0 -- I remember getting it with
much older servers as well.


Relevant versions:

ii  xserver-common 4.1.0-0pre1v5  files and utilities common to all X servers
ii  xserver-xfree8 4.1.0-0pre1v5  the XFree86 X server
ii  mozilla-browse 0.9.1-4Mozilla Web Browser - core and browser
ii  skipstone  0.7.3-1Web Browser based on mozilla's embed compone


-- 
.Adam Di [EMAIL PROTECTED]URL:http://www.onshored.com/



XFree86 on mips cleanup patch

2001-07-25 Thread Guido Guenther
Hi,
the attached patch removes some previous workarounds by adding proper
functions to compiler.h for mips(el). This obsoletes the disabling of
the ati driver on mips(351) and the int10 module(350) on mipsel as well
as the mem_barrier patch(353). I've also attached the newport range fix
for completeness - both are against pre5. So these should be the only
patches needed to get XFree86 going on mips/mipsel for now.
 -- Guido
--- xc/programs/Xserver/hw/xfree86/common/compiler.h.orig   Tue Jul 24 
22:33:42 2001
+++ xc/programs/Xserver/hw/xfree86/common/compiler.hTue Jul 24 22:37:37 2001
@@ -862,6 +862,67 @@
return r1;
 }
 
+#ifdef linux   /* don't mess with other OSs */
+
+/*
+ * EGCS 1.1 knows about arbitrary unaligned loads (and we don't support older
+ * versions anyway. Define some packed structures to talk about such things
+ * with.
+ */
+
+struct __una_u32 { unsigned int   x __attribute__((packed)); };
+struct __una_u16 { unsigned short x __attribute__((packed)); };
+
+static __inline__ void stw_u(unsigned long val, unsigned short *p)
+{
+   struct __una_u16 *ptr = (struct __una_u16 *) p;
+   ptr-x = val;
+}
+
+static __inline__ void stl_u(unsigned long val, unsigned int *p)
+{
+   struct __una_u32 *ptr = (struct __una_u32 *) p;
+   ptr-x = val;
+}
+
+#if X_BYTE_ORDER == X_BIG_ENDIAN
+static __inline__ unsigned int
+xf86ReadMmio32Be(__volatile__ void *base, const unsigned long offset)
+{
+   unsigned long addr = ((unsigned long)base) + offset;
+   unsigned int ret;
+
+   __asm__ __volatile__(lw %0, 0(%1)
+: =r (ret)
+: r (addr));
+   return ret;
+}
+
+static __inline__ void
+xf86WriteMmio32Be(__volatile__ void *base, const unsigned long offset,
+ const unsigned int val)
+{
+   unsigned long addr = ((unsigned long)base) + offset;
+
+   __asm__ __volatile__(sw %0, 0(%1)
+: /* No outputs */
+: r (val), r (addr));
+}
+#endif
+
+#define mem_barrier() \
+__asm__ __volatile__(  \
+   # prevent instructions being moved around\n\t \
+   .set\tnoreorder\n\t   \
+   # 8 nops to fool the R4400 pipeline\n\t   \
+   nop;nop;nop;nop;nop;nop;nop;nop\n\t   \
+   .set\treorder \
+   : /* no output */   \
+   : /* no input */\
+   : memory)
+#define write_mem_barrier() mem_barrier()
+
+#else  /* !linux */
 #define stq_u(v,p) stl_u(v,p)
 #define stl_u(v,p) (*(unsigned char *)(p)) = (v); \
(*(unsigned char *)(p)+1) = ((v)  8);  \
@@ -872,6 +934,7 @@
(*(unsigned char *)(p)+1) = ((v)  8)
 
 #define mem_barrier()   /* NOP */
+#endif /* !linux */
 #endif /* __mips__ */
 
 #if defined(__arm32__)
--- xc/programs/Xserver/hw/xfree86/drivers/newport/newport_driver.c.orig
Thu Jul 19 14:53:15 2001
+++ xc/programs/Xserver/hw/xfree86/drivers/newport/newport_driver.c Thu Jul 
19 14:53:29 2001
@@ -247,7 +247,7 @@
entity = xf86ClaimIsaSlot(drv, 0, dev, 
TRUE);
base = (NEWPORT_BASE_ADDR0 + busID * 
NEWPORT_BASE_OFFSET);
RANGE(range[0], base, base + 
sizeof(NewportRegs),\
-   ResExcMemBlock);
+   ResExcMemBlock,0);
pScrn = xf86ConfigIsaEntity(pScrn, 0, 
entity, NULL, range, \
NULL, NULL, NULL, NULL);
/* Allocate a ScrnInfoRec */


Re: XFree86 on mips cleanup patch

2001-07-25 Thread Branden Robinson
On Wed, Jul 25, 2001 at 09:38:13PM +0200, Guido Guenther wrote:
 the attached patch removes some previous workarounds by adding proper
 functions to compiler.h for mips(el). This obsoletes the disabling of
 the ati driver on mips(351) and the int10 module(350) on mipsel as well
 as the mem_barrier patch(353). I've also attached the newport range fix
 for completeness - both are against pre5. So these should be the only
 patches needed to get XFree86 going on mips/mipsel for now.

Thanks a lot!  I have applied these to pre7, which is building now and
(hopefully) also contains a fix for those architectures that must have PIC
symbols in static objects.

-- 
G. Branden Robinson|One man's theology is another man's
Debian GNU/Linux   |belly laugh.
[EMAIL PROTECTED] |-- Robert Heinlein
http://people.debian.org/~branden/ |


pgpZaIjNJmyJS.pgp
Description: PGP signature


Re: XFree86 on mips cleanup patch

2001-07-25 Thread Ben Collins
On Wed, Jul 25, 2001 at 09:38:13PM +0200, Guido Guenther wrote:
 Hi,
 the attached patch removes some previous workarounds by adding proper
 functions to compiler.h for mips(el). This obsoletes the disabling of
 the ati driver on mips(351) and the int10 module(350) on mipsel as well
 as the mem_barrier patch(353). I've also attached the newport range fix
 for completeness - both are against pre5. So these should be the only
 patches needed to get XFree86 going on mips/mipsel for now.
  -- Guido

Are the below asm functions going to affect other architectures? I don't
see them wrapped in any sort of arch specific defines.

 +#if X_BYTE_ORDER == X_BIG_ENDIAN
 +static __inline__ unsigned int
 +xf86ReadMmio32Be(__volatile__ void *base, const unsigned long offset)
 +{
 + unsigned long addr = ((unsigned long)base) + offset;
 + unsigned int ret;
 +
 + __asm__ __volatile__(lw %0, 0(%1)
 +  : =r (ret)
 +  : r (addr));
 + return ret;
 +}
 +
 +static __inline__ void
 +xf86WriteMmio32Be(__volatile__ void *base, const unsigned long offset,
 +   const unsigned int val)
 +{
 + unsigned long addr = ((unsigned long)base) + offset;
 +
 + __asm__ __volatile__(sw %0, 0(%1)
 +  : /* No outputs */
 +  : r (val), r (addr));
 +}
 +#endif


 +__asm__ __volatile__(\
 + # prevent instructions being moved around\n\t \
 + .set\tnoreorder\n\t   \
 + # 8 nops to fool the R4400 pipeline\n\t   \
 + nop;nop;nop;nop;nop;nop;nop;nop\n\t   \
 + .set\treorder \
 + : /* no output */   \
 + : /* no input */\
 + : memory)
 +#define write_mem_barrier() mem_barrier()


-- 
 ---===-=-==-=---==-=--
/  Ben Collins  --  ...on that fantastic voyage...  --  Debian GNU/Linux   \
`  [EMAIL PROTECTED]  --  [EMAIL PROTECTED]  --  [EMAIL PROTECTED]  '
 `---=--===-=-=-=-===-==---=--=---'



Re: XFree86 on mips cleanup patch

2001-07-25 Thread Branden Robinson
On Wed, Jul 25, 2001 at 05:51:00PM -0400, Ben Collins wrote:
 Are the below asm functions going to affect other architectures?

No.

 I don't see them wrapped in any sort of arch specific defines.

Because this patch is already inside just such an #if.

See c. line 787 of xc/programs/Xserver/hw/xfree86/common/compiler.h in your
local unpacked source tree.

-- 
G. Branden Robinson|  Somebody once asked me if I thought sex
Debian GNU/Linux   |  was dirty.  I said, It is if you're
[EMAIL PROTECTED] |  doing it right.
http://people.debian.org/~branden/ |  -- Woody Allen


pgpfCDSw1eNgb.pgp
Description: PGP signature


Re: XFree86 on mips cleanup patch

2001-07-25 Thread Stephen Frost
* Ben Collins ([EMAIL PROTECTED]) wrote:
 On Wed, Jul 25, 2001 at 09:38:13PM +0200, Guido Guenther wrote:
  Hi,
  the attached patch removes some previous workarounds by adding proper
  functions to compiler.h for mips(el). This obsoletes the disabling of
  the ati driver on mips(351) and the int10 module(350) on mipsel as well
  as the mem_barrier patch(353). I've also attached the newport range fix
  for completeness - both are against pre5. So these should be the only
  patches needed to get XFree86 going on mips/mipsel for now.
   -- Guido
 
 Are the below asm functions going to affect other architectures? I don't
 see them wrapped in any sort of arch specific defines.


+#endif /* !linux */
 #endif /* __mips__ */


Stephen


pgpW1qtjDgt8b.pgp
Description: PGP signature


Re: XFree86 on mips cleanup patch

2001-07-25 Thread Ben Collins
On Wed, Jul 25, 2001 at 06:38:58PM -0400, Stephen Frost wrote:
 * Ben Collins ([EMAIL PROTECTED]) wrote:
  On Wed, Jul 25, 2001 at 09:38:13PM +0200, Guido Guenther wrote:
   Hi,
   the attached patch removes some previous workarounds by adding proper
   functions to compiler.h for mips(el). This obsoletes the disabling of
   the ati driver on mips(351) and the int10 module(350) on mipsel as well
   as the mem_barrier patch(353). I've also attached the newport range fix
   for completeness - both are against pre5. So these should be the only
   patches needed to get XFree86 going on mips/mipsel for now.
-- Guido
  
  Are the below asm functions going to affect other architectures? I don't
  see them wrapped in any sort of arch specific defines.
 
 
 +#endif /* !linux */
  #endif /* __mips__ */
 

Ok, smack me with the blind stick. Sorry.

Ben

-- 
 ---===-=-==-=---==-=--
/  Ben Collins  --  ...on that fantastic voyage...  --  Debian GNU/Linux   \
`  [EMAIL PROTECTED]  --  [EMAIL PROTECTED]  --  [EMAIL PROTECTED]  '
 `---=--===-=-=-=-===-==---=--=---'