Re: [gentoo-dev] Modular X plans

[Ferris McCormick]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, 10 Aug 2005, Donnie Berkholz wrote:

> --[PinePGP]--------------------------------------------------[begin]--
> Ferris McCormick wrote:
> |  I wrote the note very fast, and it was not too clear.  With sunffb, the
> |  kernel code for current 2.6.x (x > 6) is broken, and davem has taken dri
> |  support out of the xorg sunffb driver (to paraphrase him, you can't do
> |  both drm and correct font rendering).
>
> OK, it might be nice to bring alanh in on this conversation since he
> recently fixed up the ffb DRI code, also to retest with the new code.
>

Probably.  Kernel seems to be changing so quickly now that as soon as the 
ffb DRI code gets fixed, the kernel changes out from under it.  So when we 
get to 2.6.13-rcxx, I have problems building it and have nothing to test 
it on.  (I am really not interested in kernel-2.4.30+, because one of 
these days davem really will fix kernel-2.6.82 (or something) for sparc, 
and we can start burying the 2.4.xx series.  I am speaking for myself, 
here, but I don't think sparc is hanging on to kernel-2.4.xx because we 
are in love with it.)

> And as far as davem taking out DRI from the DDX code, that seems
easy
> enough to re-enable and test again -- just #if 0 changed back to XF86DRI.
>
> donnie@supernova
> /usr/local/share/xorg/modular/driver/xf86-video-sunffb/src $ grep -i
> xf86dri *
> ffb_dri.c:#define _XF86DRI_SERVER_
> ffb_driver.c:/*#ifdef XF86DRI*/
> ffb_driver.c:#if 0 /*def XF86DRI*/
> ffb_driver.c:#if 0 /*def XF86DRI*/
> ffb_driver.c:#if 0 /*def XF86DRI*/
> ffb.h:#ifdef XF86DRI
> ffb.h:#ifdef XF86DRI
> ffb.h:#ifdef XF86DRI
> ffb.h:#ifdef XF86DRI
>

Yes, it's easy enough to re-enable.  I haven't tried it yet, though, 
because I have figured davem had a good reason to disable it, and I 
generally trust his knowledge on such matters.  So discovering what
that reason is has been pretty low priority.  (I don't know if anyone
else has tested or not.  The question comes up every now and then,
and so far my response has been (tongue in cheek) along the 
lines of your observation along with a request "If you try this, we'd all 
like to know how it goes.")

> |  With mach64, the problem on sparc has been the hardware itself, if I
> |  remember correctly.  That is, kernel, xorg are fine, but the mach64 card
> |  used on U5/U10 is memory-deficient.  Someone who has looked at it more
> |  recently than I have will correct this.  (There is a mach64-based sparc
> |  frame buffer which should be OK for DRI, but I've never seen one.  I'll
> |  chase it down in the framebuffer handbook a little later.)
>
> My u5 works just fine with DRI at 800x600 resolution, 16-bit color. Any
> higher than this and you're right, not enough memory.

That is new information for me;  I had been led to believe otherwise, and 
I have not been in a position to verify for myself.  Thanks.

>
> |  Changing DRI_DIRS is exactly what I did.
>
> Not really...
>
> DRIVER_DIRS != DRI_DIRS
>

Yes.  I answered you without reading carefully.

> e.g., DRIVER_DIRS = dri, DRI_DIRS = mach64 ffb
>

You are correct, of course.  Actually, there should probably be a 
corresponding dri driver for each sparc-enabled frame buffer, which makes 
it something like "mach64 ffb savage ..."

The actual ebuild will have to be a bit more subtle than my immediate 
patch-to-enable-assembly+get-to-testable for the following reason:

It always makes sense to enable glx (Mesa) whether there is DRI support or 
not; some applications can run adequately well using the Mesa-indirect 
approach, and some graphics cards --- e.g., Elite == afb --- don't allow 
dri at all.  That is what (for sparc, at least) USE=glx should control.
On some systems, however, like your U5+mach64, it is beneficial to build 
the xxxx_dri.so module.  That is what the USE=dri flag (on sparc) 
should control.  So, USE=dri without also USE=glx does not make any sense 
on sparc, but USE="glx -dri" is required for, say, Elite-graphics systems 
for which one does want libGL built (Like my SB1000+afb system, which is 
fast enough to do reasonable glx-like things (e.g., blender), but can't do 
dri at all).  Further, there is no way for the ebuild to determine for 
itself just what case it is addressing.

So, ultimately, the mesa ebuild should work as you have it if it is given 
USE="dri glx", but it should build sparc-specific modules.  However, it it 
gets USE="-dri glx", it should arrange to build libGL stand-alone, because 
the user is saying in effect "I do want mesa/openGL installed, but I am 
unable to support DRI", and mesa can be built that way.  This requires, I 
think, the ebuild to determine the HOSTCONFIG for sparc based on whether 
or not it has USE=dri, and to go on and set a sensible DRI_DIRS for the 
USE=dri case.  In all cases, the CFLAGS, SPARC_ASM, etc. should be set up 
as they are now.

I hope this isn't too incoherent; this has been a hectic day.
Regards,
Ferris

- --
Ferris McCormick (P44646, MI) <fmccor@g.o>
Developer, Gentoo Linux (sparc, devrel)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFC+ptFQa6M3+I///cRAja3AJ93r592HPu8k9riqsvhJEDGz+ZntACgjqOv
Q13+BsRVaZ2v4xoa4Pvi/B0=
=nCQQ
-----END PGP SIGNATURE-----
-- 
gentoo-dev@g.o mailing list