Re: New XFree86-3DLabs-3.3.6 RPM available!

On Mon, 2003-02-24 at 08:21, T. Ribbrock wrote:
> Hi all,
> 
> ok, my quest to get the Raptor GFX8P/PGX32 working has lead to the
> production of new RPMs for the 3DLabs server (which is needed for this card).
> The original 3.3.6 server RPM had several problems:
> 
> - a patch to glint.c was needed to get the card to be recognized
> - the package had a dependency on XFree86-compat-modules, which is
>   missing in Aurora and doesn't seem to be needed, either
> - the included Xserver wouldn't run without being made SUID root,
>   which is not recommended. The Xwrapper program that works around
>   this e.g. on RHL6.2 was not included in any RPM as far as I could
>   see
> 
> I've built new RPMs that fix these problems. They're available as
> follows (the usual disclaimer applies: YMMV, if it breaks you get to
> keep the pieces, etc.pp.):

So, the Raptor is a TI produced card? This is very much a sledgehammer
fix (although, its the right fix).

Does the Raptor have a PCI_CHIP entry that differs from the TI_PERMEDIA,
or is it using the TI_PERMEDIA? If it (the PCI_CHIP entry) is not
unique, then the attached patch is a more appropriate fix (and yes, I'm
being semantic on a dead branch of XFree86 that we're dragging along
instead of doing driver ports ;)

The fix that you've proposed effectively forks XFree86 3.3.6, which is
something I'm hesitant to do. If XFree86 3.3.6 was current, we'd be
dragging our own branch forward, since they'd never take this patch (it
undoubtedly breaks the Permedia 2). The patch I've attached would be
likely be accepted, since it would only affect Linux/SPARC builds of
XFree86 3.3.6.

Please, don't misconstrue this response as harsh. I'm very impressed
that you were able to resolve this issue, and you will see the results
included in the next build of Aurora. Every patch I get for Aurora makes
me happy beyond belief. :) It is just vital to remember (and if you look
at Anaconda, you know I'm guilty of this as well) that we need to always
consider whether the patch can go back upstream and work on other
arches, or if it makes the code tree only work properly on sparc.

The compat-modules dep was something I assumed was erroneous anyways on
sparc (since it exploded in about 200 places trying to build), your spec
fix looks fine.

~spot
---
Tom "spot" Callaway <tcallawa(a)redhat*com> (SAIR LCA, RHCE)
GPG: D786 8B22 D9DB 1F8B 4AB7  448E 3C5E 99AD 9305 4260
Red Hat Field Sales Engineer :: http://www.redhat.com
Aurora SPARC Linux Project Leader :: http://www.auroralinux.org

The words and opinions reflected in this message do not necessarily
reflect those of my employer, Red Hat, or my project, Aurora 
SPARC Linux and belong solely to me.

--- xc/programs/Xserver/hw/xfree86/accel/glint/glint.c.BAD	2003-02-24 08:55:01.000000000 -0600
+++ xc/programs/Xserver/hw/xfree86/accel/glint/glint.c	2003-02-24 09:01:31.000000000 -0600
@@ -582,7 +582,10 @@
 	}
     }
     else if ((pcrp->_vendor == PCI_VENDOR_TI) && /* TI is producing the PM2 */
+/* this breaks the Raptor GFX8P/PGX32 on sparclinux, so we disable it */
+#if defined(__linux__) && !defined(__sparc__)
 	     (pcrp->_command & PCI_CMD_IO_ENABLE) &&
+#endif     
 	     (pcrp->_command & PCI_CMD_MEM_ENABLE))
     {
         switch (pcrp->_device)