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 1E31Gx-000134-IP for garchives@archives.gentoo.org; Thu, 11 Aug 2005 00:50:15 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.4/8.13.4) with SMTP id j7B0mpS1007679; Thu, 11 Aug 2005 00:48:51 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 j7B0lCuv024064 for ; Thu, 11 Aug 2005 00:47:13 GMT Received: from als2077-router1.science.oregonstate.edu ([128.193.220.20] helo=[192.168.123.189]) by smtp.gentoo.org with esmtpa (Exim 4.43) id 1E31EU-0000um-75; Thu, 11 Aug 2005 00:47:42 +0000 Message-ID: <42FA9FE7.7050702@gentoo.org> Date: Wed, 10 Aug 2005 17:46:31 -0700 From: Donnie Berkholz User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050722) X-Accept-Language: en-us, en 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 To: gentoo-dev@lists.gentoo.org CC: sparc@gentoo.org Subject: Re: [gentoo-dev] Modular X plans 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> In-Reply-To: X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Archives-Salt: 4cc2ca0e-d2c9-432c-9fc8-6f7ebbb95103 X-Archives-Hash: e5d03e0fc1888d91596ebf452c3ed424 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ferris McCormick wrote: | 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. I don't see why mesa should have a glx USE flag, unless you're referring to a flag in xorg-server? | 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. I still don't understand why they wouldn't just build a glx-using libGL instead of an Xlib-using libGL. This would mean setting a blank DRI_DIRS and keeping DRIVER_DIRS = mesa. I can understand, however, that one might like to avoid building the DRI drivers with a USE=dri flag. In fact, you've actually convinced me that the glx USE flag as a whole is probably a bad idea and I should always force it on in xorg-server too. Thanks, Donnie -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC+p/nXVaO67S1rtsRAtX2AKC0tCW1WwHURu1ZYGdoTiu3dOwEVACg1ueW tYBYd/QFC8xbf5mSE8sJymg= =O7eX -----END PGP SIGNATURE----- -- gentoo-dev@gentoo.org mailing list