From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.43) id 1E30xO-00022Q-Lf for garchives@archives.gentoo.org; Thu, 11 Aug 2005 00:30:03 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.4/8.13.4) with SMTP id j7B0Scvn022595; Thu, 11 Aug 2005 00:28:38 GMT Received: from smtp.gentoo.org (smtp.gentoo.org [134.68.220.30]) by robin.gentoo.org (8.13.4/8.13.4) with ESMTP id j7B0QMMr000303 for ; Thu, 11 Aug 2005 00:26:22 GMT Received: from [209.249.182.18] (helo=ferris.dsl.patriot.net) by smtp.gentoo.org with esmtpa (Exim 4.43) id 1E30uE-0004m1-Dz; Thu, 11 Aug 2005 00:26:46 +0000 Date: Thu, 11 Aug 2005 00:26:40 +0000 (UTC) From: Ferris McCormick X-X-Sender: fmccor@terciopelo.krait.us To: Donnie Berkholz cc: gentoo-dev@lists.gentoo.org, sparc@gentoo.org Subject: Re: [gentoo-dev] Modular X plans In-Reply-To: <42FA8319.3040801@gentoo.org> Message-ID: References: <42EE8C03.3040904@gentoo.org> <42EF0D9A.4070304@gentoo.org> <42F6C8AC.2070307@gentoo.org> <42F712E3.6070708@gentoo.org> <42F8F314.8040902@gentoo.org> <20050810020425.GB8183@lion.gg3.net> <42F9690F.5040903@gentoo.org> <1123677997.8614.33.camel@polylepis.inforead.com> <1123687081.8608.50.camel@polylepis.inforead.com> <42FA3F12.4080506@gentoo.org> <1123706165.8614.61.camel@polylepis.inforead.com> <42FA5A58.3090008@gentoo.org> <42FA8319.3040801@gentoo.org> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Archives-Salt: 481544a9-e25c-44d9-982a-0ad9b7b9dbdb X-Archives-Hash: 599aca4f68337f50623572e003ee68bf -----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) 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@gentoo.org mailing list