From owner-freebsd-ports@FreeBSD.ORG Fri Mar 2 18:51:12 2012 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 91A59106564A; Fri, 2 Mar 2012 18:51:12 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 1DD6B8FC15; Fri, 2 Mar 2012 18:51:11 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q22InWXX000598; Fri, 2 Mar 2012 20:49:32 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q22InW1S084235; Fri, 2 Mar 2012 20:49:32 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q22InV27084234; Fri, 2 Mar 2012 20:49:31 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 2 Mar 2012 20:49:31 +0200 From: Konstantin Belousov To: Doug Barton Message-ID: <20120302184931.GM75778@deviant.kiev.zoral.com.ua> References: <20294.39398.620930.217619@gromit.timing.com> <20120223211406.GA14803@azathoth.lan> <4F46D751.2090100@FreeBSD.org> <20120228211513.GD99283@azathoth.lan> <4F4D44F0.9060901@FreeBSD.org> <20120228223656.GF99283@azathoth.lan> <4F509414.3070605@FreeBSD.org> <20120302094710.GD75778@deviant.kiev.zoral.com.ua> <4F51133C.7030902@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="8c07nsHwQobhlezh" Content-Disposition: inline In-Reply-To: <4F51133C.7030902@FreeBSD.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: Baptiste Daroussin , Ade Lovett , freebsd-ports@freebsd.org Subject: Re: Fix nvidia-like ports, help needed X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 18:51:12 -0000 --8c07nsHwQobhlezh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Mar 02, 2012 at 10:36:44AM -0800, Doug Barton wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 >=20 > On 03/02/2012 01:47, Konstantin Belousov wrote: > > On Fri, Mar 02, 2012 at 01:34:12AM -0800, Doug Barton wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- > >> Hash: SHA256 > >> > >> On 02/28/2012 14:36, Baptiste Daroussin wrote: > >>> On Tue, Feb 28, 2012 at 01:19:44PM -0800, Doug Barton wrote: > >>>> On 2/28/2012 1:15 PM, Baptiste Daroussin wrote: > >>>>> Here is a patch to add support for includedir keyword to > >>>>> libmap.conf so that we > >>>> > >>>> I think this is overly complicated, and not generally useful. It > >>>> also delays the utility of the solution until this gets into the > >>>> base. > >>>> > >>>> What I would do instead is to incorporate an nvidia option into > >>>> the xorg meta-port, and separate the GL libs into a separate > >>>> port. If the nvidia option is checked the GL libs come from an > >>>> nvidia slave port. If not, they come from an xorg-server slave > >>>> port. > >>>> > >>>> Or, we just keep doing what we're doing now, since it works. I'm > >>>> still not sure what problem we're trying to solve. :) > >>>> > >>>> > >>>> Doug > >>> > >>> the problem we are trying to solve is to avoid having the nvidia > >>> drivers overwritting libGL.so.1 which break the package database > >>> consistency. > >> > >> In that case the solution I outlined above would work, and it's hard > >> for me to see why it wouldn't be the best solution. > > > > There are hybrid machines which have both Intel and NVidia GPUs. > > Depending on a switch position, you may activate one of the GPU. > > Usually, on-CPU GPU gives power efficiency, while discrete one provdes > > a performance. > >=20 > > For such machines, it is _very_ useful to have both libGL.so.1 installed > > and somehow switched around. It would be best to have Mesa and NVidia > > libGL.so.1 installed under other names, like libGL-mesa.so.1. and > > ligGL-nvidia.so.1, and provide a symlink for libGL.so.1 > >=20 > > BTW, besides libGL.so.1, another conflicting file is > > /usr/local/lib/xorg/modules/extensions/libglx.so. >=20 > For us to support that would actually require a script of some sort, but > it's not impossible. If the switch you're referring to provides a devd > event it could even be automated, although (AFAIK) you'd have to restart > X. I'm not opposed to what you're proposing, install both libs and > symlink one or the other ... but that situation is still most easily > handled by having the GL components of both xorg-server and > nvidia-driver being split out into separate slave ports. Well, the switch only works sometime, and for FreeBSD, you need to reboot the OS (basically, BIOS shall reprogram the video commutator and activate/deactivate PCI devices). Linux does have some alpha-stage support for switching GPUs on fly, but you are required to use the Nouveau. NVidia optimus (the newest variation of the dual-GPU systems) does not have commutator, and video signal is generated by on-CPU GPU always. I think that packaging libGL.so variants into separate packages from the nvidia driver/mesa has nothing to do with names/symlink issue. And yes, I use a script that checks PCI devices on boot and symlinks libGL.so.1 and libglx.so to appropriate implementations. The only trouble right now is that reinstall of libGL or nvidia driver ports requires manual fixing of the .so. --8c07nsHwQobhlezh Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk9RFjsACgkQC3+MBN1Mb4jyigCgz4KCd/inXvPfuA1LyLEoVz7+ M0QAoN10u3OM5HKyjjupJkPQ5Cf1Bce0 =zcNC -----END PGP SIGNATURE----- --8c07nsHwQobhlezh--