Re: Fix nvidia-like ports, help needed
-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. Doug - -- This .signature sanitized for your protection -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (FreeBSD) iQEcBAEBCAAGBQJPUJQUAAoJEFzGhvEaGryEoIYIANJ0DHtcxIRCCY85rKB/2ENQ p8iSPhkuA99eGsbBukzhBpyivNskm10/W5XnhLy+VzuyX6UmxRfa1w+hxp7tej75 zZHrSnByb3j3iYG9MgiE/Doeo1Iwg8qknhr+W6JhVVTZQH0jM4Y3uPd4xxlLc8lT GDhtbPWPeQMggzJdjiajQSUJBLZMMoFzXGiaetr0yyz4HwEv8IjcUSTdkZ/ixHB5 5GoVODLr5RuGCErYWLTzR2DytZ9MroJwH+iRcWNuY5w7aAG6SF5Wqytsq3RgYqga bWUBVCtozaAah+clGR8dkyL0IC+RZxSRdoR3JqlXtfAbhZBnHuo9VYOlhLtPMIA= =+RmT -END PGP SIGNATURE- ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Fix nvidia-like ports, help needed
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. 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 BTW, besides libGL.so.1, another conflicting file is /usr/local/lib/xorg/modules/extensions/libglx.so. pgpas3pLEG6Sa.pgp Description: PGP signature
Re: Fix nvidia-like ports, help needed
On Fri, Mar 02, 2012 at 11:47:10AM +0200, 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. 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 BTW, besides libGL.so.1, another conflicting file is /usr/local/lib/xorg/modules/extensions/libglx.so. This was my first idea, the symlink to be able to switch though the alternative script, but this seems to be rejected, that is why I tried to fixed it using the libmap.conf, but libmap.conf won't solve the libglx.so solution as it is opened from its path iirc. regards, Bapt pgpAxUDtvPyGw.pgp Description: PGP signature
Re: Fix nvidia-like ports, help needed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 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. 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 BTW, besides libGL.so.1, another conflicting file is /usr/local/lib/xorg/modules/extensions/libglx.so. 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. Doug - -- This .signature sanitized for your protection -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (FreeBSD) iQEcBAEBCAAGBQJPURM8AAoJEFzGhvEaGryE1k0IAIk3Ah/29qsu43ivE0Twycc0 Mmv66FpgmVSxlBBuySpWhw+zHhGBVU9wN5X/fYSG1r70oYInq/lnFP65hBt/hyXj /Cpua4x/RtfWj7RCszz39FyAe7sY8F3qGVgzxYBr5k8+7q/TDh5ezQdKbb++zZZF 5VbyITwCI8+f3P8UL1kidUu8J8GEPSbYWv7O7nDlddeyv0rR4Sc7WtF+84hJIqlX XXzFCi64/5cC1tYstbUA4j8bMdEUYIAgCa07Ugs7OnLNiZVnnnxuuNqclEZBe5/w XRnda183Jbf+9zin9FTckNxjdZE9CH74VwW+cSCuNWPYmfuUvfg5ve8qx676Gs8= =oeZG -END PGP SIGNATURE- ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Fix nvidia-like ports, help needed
On Fri, Mar 02, 2012 at 10:36:44AM -0800, Doug Barton wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 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. 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 BTW, besides libGL.so.1, another conflicting file is /usr/local/lib/xorg/modules/extensions/libglx.so. 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. pgp00NxSj9hTe.pgp Description: PGP signature
Re: Fix nvidia-like ports, help needed
On Fri, Mar 2, 2012 at 10:49 AM, Konstantin Belousov kostik...@gmail.com wrote: 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. Ah, but splitting the GL bits out into slave ports would fix that. :) -- Freddie Cash fjwc...@gmail.com ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Fix nvidia-like ports, help needed
On Fri, Mar 02, 2012 at 10:54:46AM -0800, Freddie Cash wrote: On Fri, Mar 2, 2012 at 10:49 AM, Konstantin Belousov kostik...@gmail.com wrote: 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. Ah, but splitting the GL bits out into slave ports would fix that. :) No, it moves the moment of problem from mesa/nvidia update to mesa-libGL and nvidia-libGL update. And, libGl.so.1 from Mesa is already in the separate port, FWIW. pgpAExzofdBch.pgp Description: PGP signature
Re: Fix nvidia-like ports, help needed
On Fri, Mar 2, 2012 at 11:02 AM, Konstantin Belousov kostik...@gmail.com wrote: On Fri, Mar 02, 2012 at 10:54:46AM -0800, Freddie Cash wrote: On Fri, Mar 2, 2012 at 10:49 AM, Konstantin Belousov kostik...@gmail.com wrote: 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. Ah, but splitting the GL bits out into slave ports would fix that. :) No, it moves the moment of problem from mesa/nvidia update to mesa-libGL and nvidia-libGL update. And, libGl.so.1 from Mesa is already in the separate port, FWIW. How? Unless the ports include the creation of the symlink (which they shouldn't), then there is no problem anymore. You install nvidia-gl port, you get libGL-nvidia.so installed. You install mesa-gl port, you get libGL-mesa.so installed. You run the alternatives script to create the symlink (or manually create it, or tweak a knob somewhere to create it), and then never touch it again. Update nvidia-gl port, only libGL-nvidia.so gets updated. The symlink doesn't change. Update mesa-gl port, only libGL-mesa.so gets updated. The symlink doesn't change. Where's the problem? -- Freddie Cash fjwc...@gmail.com ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Fix nvidia-like ports, help needed
On Fri, Mar 02, 2012 at 11:10:06AM -0800, Freddie Cash wrote: On Fri, Mar 2, 2012 at 11:02 AM, Konstantin Belousov kostik...@gmail.com wrote: On Fri, Mar 02, 2012 at 10:54:46AM -0800, Freddie Cash wrote: On Fri, Mar 2, 2012 at 10:49 AM, Konstantin Belousov kostik...@gmail.com wrote: 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. Ah, but splitting the GL bits out into slave ports would fix that. :) No, it moves the moment of problem from mesa/nvidia update to mesa-libGL and nvidia-libGL update. And, libGl.so.1 from Mesa is already in the separate port, FWIW. How? Unless the ports include the creation of the symlink (which they shouldn't), then there is no problem anymore. You install nvidia-gl port, you get libGL-nvidia.so installed. So nvidia-something port needs to install libGL-nvidia.so.1, and not libGL.so.1. You install mesa-gl port, you get libGL-mesa.so installed. You run the alternatives script to create the symlink (or manually create it, or tweak a knob somewhere to create it), and then never touch it again. Update nvidia-gl port, only libGL-nvidia.so gets updated. The symlink doesn't change. Update mesa-gl port, only libGL-mesa.so gets updated. The symlink doesn't change. Where's the problem? Should I repeat what I said already, or can I just point to my other message ? The renames of the libGL.so inside the packages are orthohonal to package splits. The issue is that libGL.so.1 installed by both packages (graphics/libGL and x11/nvidia-driver). And not that the nvidia-driver contains some other stuff. pgpIOaZYI48Jp.pgp Description: PGP signature
Re: Fix nvidia-like ports, help needed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 03/02/2012 11:21, Konstantin Belousov wrote: The renames of the libGL.so inside the packages are orthohonal to package splits. The issue is that libGL.so.1 installed by both packages (graphics/libGL and x11/nvidia-driver). And not that the nvidia-driver contains some other stuff. Right, I see your point. If the symlink solution is used, slave ports are likely unnecessary. Another question that occurred to me, has anyone tested that ports built against one version of the GL stuff can safely be run if the other version suddenly appears at runtime? - -- This .signature sanitized for your protection -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (FreeBSD) iQEcBAEBCAAGBQJPUSEOAAoJEFzGhvEaGryE7rUIAJTF/d/aPffPT/4crdMDxYlo 8rQnDoZq+bE2Ona9jg3jZT1ZR3EmU8i8x2nubTUkd2r2y2+kEyZEy4VxWREaXN/t z0fqUFR9vmTl4DzxSNpHyNeFau9OU59B8CiLuUCDkHt/ypELmEyXvpqBjFI9aAHq 84wCYFrW6iOgVWLhefyKgAUbhFrJRp52v6TqNFQ7CmSW7AVgGqaNjb5m2d3nuUGH J0gtvifPdShnRorKIVDQ+3dRiry5LSRQTn6YeZBqkpOjJh3XO4AQhu9vmqOFp0wv tG1sknVt8R93FfPMa6wh7FP/W4JroGZNqVRmjdPkGLl6KrHuLTlApgs2BzVXe6k= =KVee -END PGP SIGNATURE- ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Fix nvidia-like ports, help needed
On Fri, Mar 02, 2012 at 11:35:42AM -0800, Doug Barton wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 03/02/2012 11:21, Konstantin Belousov wrote: The renames of the libGL.so inside the packages are orthohonal to package splits. The issue is that libGL.so.1 installed by both packages (graphics/libGL and x11/nvidia-driver). And not that the nvidia-driver contains some other stuff. Right, I see your point. If the symlink solution is used, slave ports are likely unnecessary. Another question that occurred to me, has anyone tested that ports built against one version of the GL stuff can safely be run if the other version suddenly appears at runtime? The different libGL.so versions should be ABI-compatible. The OpenGL extension mechanism assumes that OpenGL consumers test the presence of the optional features at runtime and adapts. You do not link directly to the new symbol in libGL, but call a function to get the function pointer for extension. On other systems, different OpenGL providers support different versions of OpenGL standard, and this usually not cause much problem for applications. Sure, there may be bugs (and usually there are). pgprWTqwCFhsJ.pgp Description: PGP signature
Re: Fix nvidia-like ports, help needed
On Thu, Feb 23, 2012 at 04:18:25PM -0800, Ade Lovett wrote:
On 2/23/2012 13:14, Baptiste Daroussin wrote:
Another solution could be to add an entry (and drop it in deinstallation to
libmap.conf) when installing the nvidia driver, in that case installing it
ad
libGL-nvidia.so.1 and adding:
libGL.so.1 libGL-nvidia.so.1
or something like that.
Going that route is likely to be messy given the current monolithic
/etc/libmap{,32}.conf
You'd most likely want ${LOCALBASE}/etc/libmap.conf.d/* (in a similar
manner to etc/periodic, etc/rc.d and so on). Whether the code that
currently handles libmap.conf is itself extended to use this directory
structure is open for discussion. An alternate method could perhaps be
a 'genlibmap' command which takes /etc/libmap.conf and this directory
structure to create a /var/run/libmap.conf which is actually used by rtld.
Having potentially multiple ports dinking _directly_ with
/etc/libmap.conf will result in considerable foot shooting.
-aDe
Here is a patch to add support for includedir keyword to libmap.conf so that we
can add:
includedir /usr/local/etc/libmap.d
into libmap.conf and then nvidia driver could add a
${LOCALBASE}/etc/libmap.d/nvidia
containing:
libGL.so.1 libGL-nvidia.so.1
http://people.freebsd.org/~bapt/libmap-support-includedir.diff
Any remarks?
regards,
Bapt
pgpOGhu7zp1D3.pgp
Description: PGP signature
Re: Fix nvidia-like ports, help needed
The problem is when tools like portmaster notice x11/nvidia-driver (not installed) has a newer version number than x11/nvidia-driver-173 (installed), and the mesa/dri/drm ports have updates available, and then builds/installs them in the wrong order such that the x11/nvidia-driver port is installed first, the x11/nvidia-driver-173 port is removed, and then the x11/meda/dri/drm ports are installed, leaving you with a broken mess. You get an nvidia.ko that doesn't support the video card installed in the machine, an nvidia X11 driver that links against the wrong libGL.so, and thus a broken X11 setup that can lead to a lot of frustration, gnashing of teeth, and tearing of sackcloth to get sorted out. :( There are three issues here (at least for me, although it's really only the last one that's the topic of this thread): - the fact that portmaster sees nvidia-driver instead of nvidia-driver-173 as the port name and installs the wrong port - the fact that portmaster installs nvidia-driver before the x11/mesa/dri/drm ports - the fact that both the nvidia-driver* and x11/mesa/dri/drm ports install libGL.so, and the wrong one is installed last The combination of those three means that any upgrade of nvidia/x11 ports requires a lot of manual hand-holding to make sure things are installed in the right order, and that the correct ports are installed (thank god of -i). That last option is the one that causes all the issues. Two ports install the same file, but they aren't listed as CONFLICTS of each other, so it's up to the end-user to make it work. Ideally, the best solution would be to fix those ports such that they don't install the same file, and that they are listed as CONFLICTS of each other. A nice solution would be, as you suggested, separating out the libGL bits into slave ports and only installing one of them (and getting the versioning right so that updates only occur in the right port). The other issues are slightly annoying, although not really sure how to fix them permanently, and they're outside the scope of this thread. (This issue is making me regret installing an nVidia video card into my home desktop. Life was so much simpler with Ati and Intel.) ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Fix nvidia-like ports, help needed
On Tue, 28 Feb 2012 13:36:26 -0800 Freddie Cash articulated: (This issue is making me regret installing an nVidia video card into my home desktop. Life was so much simpler with Ati and Intel.) Except that neither of them seem to work as well; at least not the ATI cards that I have tried. By the way, portmanager does not have the problems you were attributing to postmaster. Whether that is by design or just dumb luck I cannot attest to. That is why I still use it although most other users have abandoned it. -- Jerry ♔ Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. __ Reality always seems harsher in the early morning. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Fix nvidia-like ports, help needed
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. regards, Bapt pgpHkBZYzvQPX.pgp Description: PGP signature
Re: Fix nvidia-like ports, help needed
On Tue, 28 Feb 2012 13:36:26 -0800 Freddie Cash wrote: The problem is when tools like portmaster notice x11/nvidia-driver (not installed) has a newer version number than x11/nvidia-driver-173 (installed), and the mesa/dri/drm ports have updates available, and then builds/installs them in the wrong order such that the x11/nvidia-driver port is installed first, the x11/nvidia-driver-173 port is removed, and then the x11/meda/dri/drm ports are installed, leaving you with a broken mess. This sounds like it's a portmaster bug to me - it didn't happen with portupgrade or portmanager when I used nvidia-driver-173. The consequences of merely building the ports out of order are pretty minor in my experience. You lose OpenGL 3d hardware acceleration for wobbly windows, games etc, and it's easily fixed by forcing an nvidia-driver rebuild. The key reasons for choosing nVidia, vdpau video acceleration and general performance aren't affected. If you want to stay with portmaster, I'd suggest you configure it to ignore nvidia-driver-173, and handle it manually. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Fix nvidia-like ports, help needed
On Thu, Feb 23, 2012 at 04:18:25PM -0800, Ade Lovett wrote:
On 2/23/2012 13:14, Baptiste Daroussin wrote:
Another solution could be to add an entry (and drop it in deinstallation to
libmap.conf) when installing the nvidia driver, in that case installing it
ad
libGL-nvidia.so.1 and adding:
libGL.so.1 libGL-nvidia.so.1
or something like that.
Going that route is likely to be messy given the current monolithic
/etc/libmap{,32}.conf
You'd most likely want ${LOCALBASE}/etc/libmap.conf.d/* (in a similar
manner to etc/periodic, etc/rc.d and so on). Whether the code that
currently handles libmap.conf is itself extended to use this directory
structure is open for discussion. An alternate method could perhaps be
a 'genlibmap' command which takes /etc/libmap.conf and this directory
structure to create a /var/run/libmap.conf which is actually used by rtld.
Having potentially multiple ports dinking _directly_ with
/etc/libmap.conf will result in considerable foot shooting.
-aDe
I agree with that, currently we can have LIBMAP env variable to append antoher
libmap.conf file to the /etc/libmap.conf,
So we have two option, convert the LIBMAP variable to a PATH-like variable,
(don't like this very much) or add an includedir keyword to libmap.conf then
the code will go thought the includedir and parse all the .conf files available
in that directory.
the second seems pretty easy, I'll write a PoC for it as soon as I can
regards,
Bapt
pgpoog99I2jIh.pgp
Description: PGP signature
Re: Fix nvidia-like ports, help needed
On Thursday 23 February 2012 08:21:33 Baptiste Daroussin wrote: Why not but which package will provide the libGL.so file? in all case the users might need to be able to switch the libGL.so file from the nvidia one to the mesa one, what would a user have to do for that, in particular a user using only binary packages where a file can't belong to 2 different packages without conflicting? Something like splitting libGL.so and making a mesa-libgl-whatever port? Then mark CONFLICTS, and replacing that with nvidia-driver will be easy. Won't it? -- Alberto Villa, FreeBSD committer avi...@freebsd.org http://people.FreeBSD.org/~avilla Dear Lord: I just want *_o_n_e* one-armed manager so I never have to hear On the other hand, again. signature.asc Description: This is a digitally signed message part.
Re: Fix nvidia-like ports, help needed
On 23.02.2012 08:34, Alexander Leidinger wrote: Quoting Baptiste Daroussin b...@freebsd.org (from Thu, 23 Feb 2012 08:21:33 +0100): On Thu, Feb 23, 2012 at 01:35:02AM +, Alexey Dokuchaev wrote: On Wed, Feb 22, 2012 at 04:36:08PM -0700, John Hein wrote: One of the issues with 'alternatives' implementations is that they are not selectable per-user (including non superuser). In this particular case (libGL), also what about the native X server vs. virtual X servers that support using the mesa lib (per-application selection)? In addition to something like alternatives, another option is to allow installation of conflicting files (like libGL.so in this case) to separate directories and specify which to use using a path (like LD_LIBRARY_PATH or rpath at compile time). That can help with the aforementioned per-user and per-application variation. Personally, I prefer the path method over something like alternative sym links (e.g., debian/redhat alternatives). There can still be a front-end tool to get at the alternates configuration information, but I like the ability to set a path rather than a sym link. I tend to agree. While I currently do not see clearly the best solution to the problem, when I see etc/alternative.d I want to unsee it ASAP. For nvidia driver, it might be easier to simply provide a knob in xorg-server and libGL and perhaps register a dependency on nvidia-driver; no need to invent some cumbersome framework. Why not but which package will provide the libGL.so file? in all case the users might need to be able to switch the libGL.so file from the nvidia one to the mesa one, what would a user have to do for that, in particular a user using only binary packages where a file can't belong to 2 different packages without conflicting? if someone have a better solution than a framework for that I'm open but no the knob is not a solution for package people. Do you havea list of packages which overzrite something, respectively do you have a list of files which are overwriten? If we just talk about the nvidia lib, installing the mesa and nvidia ones into subdirectories and asking to add (or adding automatically/optionally) ldconfig_paths=$ldconfig_paths /usr/local/lib/port-gl/ to rc.conf could be an option. Bye, Alexander. Currently, no I don't have a list of packages that overwrite things, anyway way I do really like this kind of solution, I don't know yet how this can be automated, it really looks the right way. regards, Bapt ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Fix nvidia-like ports, help needed
Quoting Baptiste Daroussin b...@freebsd.org (from Thu, 23 Feb 2012 08:21:33 +0100): On Thu, Feb 23, 2012 at 01:35:02AM +, Alexey Dokuchaev wrote: On Wed, Feb 22, 2012 at 04:36:08PM -0700, John Hein wrote: One of the issues with 'alternatives' implementations is that they are not selectable per-user (including non superuser). In this particular case (libGL), also what about the native X server vs. virtual X servers that support using the mesa lib (per-application selection)? In addition to something like alternatives, another option is to allow installation of conflicting files (like libGL.so in this case) to separate directories and specify which to use using a path (like LD_LIBRARY_PATH or rpath at compile time). That can help with the aforementioned per-user and per-application variation. Personally, I prefer the path method over something like alternative sym links (e.g., debian/redhat alternatives). There can still be a front-end tool to get at the alternates configuration information, but I like the ability to set a path rather than a sym link. I tend to agree. While I currently do not see clearly the best solution to the problem, when I see etc/alternative.d I want to unsee it ASAP. For nvidia driver, it might be easier to simply provide a knob in xorg-server and libGL and perhaps register a dependency on nvidia-driver; no need to invent some cumbersome framework. Why not but which package will provide the libGL.so file? in all case the users might need to be able to switch the libGL.so file from the nvidia one to the mesa one, what would a user have to do for that, in particular a user using only binary packages where a file can't belong to 2 different packages without conflicting? if someone have a better solution than a framework for that I'm open but no the knob is not a solution for package people. Do you havea list of packages which overzrite something, respectively do you have a list of files which are overwriten? If we just talk about the nvidia lib, installing the mesa and nvidia ones into subdirectories and asking to add (or adding automatically/optionally) ldconfig_paths=$ldconfig_paths /usr/local/lib/port-gl/ to rc.conf could be an option. Bye, Alexander. -- What we cannot speak about we must pass over in silence. -- Wittgenstein http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Fix nvidia-like ports, help needed
Baptiste Daroussin wrote at 11:28 + on Feb 23, 2012: On 23.02.2012 08:34, Alexander Leidinger wrote: Do you havea list of packages which overzrite something, respectively do you have a list of files which are overwriten? If we just talk about the nvidia lib, installing the mesa and nvidia ones into subdirectories and asking to add (or adding automatically/optionally) ldconfig_paths=$ldconfig_paths /usr/local/lib/port-gl/ to rc.conf could be an option. Currently, no I don't have a list of packages that overwrite things, anyway way I do really like this kind of solution, I don't know yet how this can be automated, it really looks the right way. If the nvidia libGL can be dynamically linked with, say, a vnc server, and have it be a drop in replacement for the mesa libGL, then ldconfig_paths would be fine. If not, then those apps which need the mesa libGL would need to link with -rpath perhaps to point at the right libGL (or pass appropriate path info to those apps that might use dlopen(3)). ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Fix nvidia-like ports, help needed
On Thu, Feb 23, 2012 at 12:56:22PM -0700, John Hein wrote: Baptiste Daroussin wrote at 11:28 + on Feb 23, 2012: On 23.02.2012 08:34, Alexander Leidinger wrote: Do you havea list of packages which overzrite something, respectively do you have a list of files which are overwriten? If we just talk about the nvidia lib, installing the mesa and nvidia ones into subdirectories and asking to add (or adding automatically/optionally) ldconfig_paths=$ldconfig_paths /usr/local/lib/port-gl/ to rc.conf could be an option. Currently, no I don't have a list of packages that overwrite things, anyway way I do really like this kind of solution, I don't know yet how this can be automated, it really looks the right way. If the nvidia libGL can be dynamically linked with, say, a vnc server, and have it be a drop in replacement for the mesa libGL, then ldconfig_paths would be fine. If not, then those apps which need the mesa libGL would need to link with -rpath perhaps to point at the right libGL (or pass appropriate path info to those apps that might use dlopen(3)). ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org Another solution could be to add an entry (and drop it in deinstallation to libmap.conf) when installing the nvidia driver, in that case installing it ad libGL-nvidia.so.1 and adding: libGL.so.1 libGL-nvidia.so.1 or something like that. regards, Bapt pgpkk4DzWAqw6.pgp Description: PGP signature
Re: Fix nvidia-like ports, help needed
On 2/23/2012 13:14, Baptiste Daroussin wrote:
Another solution could be to add an entry (and drop it in deinstallation to
libmap.conf) when installing the nvidia driver, in that case installing it ad
libGL-nvidia.so.1 and adding:
libGL.so.1 libGL-nvidia.so.1
or something like that.
Going that route is likely to be messy given the current monolithic
/etc/libmap{,32}.conf
You'd most likely want ${LOCALBASE}/etc/libmap.conf.d/* (in a similar
manner to etc/periodic, etc/rc.d and so on). Whether the code that
currently handles libmap.conf is itself extended to use this directory
structure is open for discussion. An alternate method could perhaps be
a 'genlibmap' command which takes /etc/libmap.conf and this directory
structure to create a /var/run/libmap.conf which is actually used by rtld.
Having potentially multiple ports dinking _directly_ with
/etc/libmap.conf will result in considerable foot shooting.
-aDe
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Fix nvidia-like ports, help needed
On Wed, Feb 22, 2012 at 04:36:08PM -0700, John Hein wrote: One of the issues with 'alternatives' implementations is that they are not selectable per-user (including non superuser). In this particular case (libGL), also what about the native X server vs. virtual X servers that support using the mesa lib (per-application selection)? In addition to something like alternatives, another option is to allow installation of conflicting files (like libGL.so in this case) to separate directories and specify which to use using a path (like LD_LIBRARY_PATH or rpath at compile time). That can help with the aforementioned per-user and per-application variation. Personally, I prefer the path method over something like alternative sym links (e.g., debian/redhat alternatives). There can still be a front-end tool to get at the alternates configuration information, but I like the ability to set a path rather than a sym link. I tend to agree. While I currently do not see clearly the best solution to the problem, when I see etc/alternative.d I want to unsee it ASAP. For nvidia driver, it might be easier to simply provide a knob in xorg-server and libGL and perhaps register a dependency on nvidia-driver; no need to invent some cumbersome framework. ./danfe ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Fix nvidia-like ports, help needed
On 2/23/2012 02:35, Alexey Dokuchaev wrote: On Wed, Feb 22, 2012 at 04:36:08PM -0700, John Hein wrote: One of the issues with 'alternatives' implementations is that they are not selectable per-user (including non superuser). In this particular case (libGL), also what about the native X server vs. virtual X servers that support using the mesa lib (per-application selection)? In addition to something like alternatives, another option is to allow installation of conflicting files (like libGL.so in this case) to separate directories and specify which to use using a path (like LD_LIBRARY_PATH or rpath at compile time). That can help with the aforementioned per-user and per-application variation. Personally, I prefer the path method over something like alternative sym links (e.g., debian/redhat alternatives). There can still be a front-end tool to get at the alternates configuration information, but I like the ability to set a path rather than a sym link. I tend to agree. While I currently do not see clearly the best solution to the problem, when I see etc/alternative.d I want to unsee it ASAP. For nvidia driver, it might be easier to simply provide a knob in xorg-server and libGL and perhaps register a dependency on nvidia-driver; no need to invent some cumbersome framework. Years ago, I suggested to have nvidia-driver conflict with Mesa libGL and select nvidia through WITH_NVIDIA_GL knob. At the time the consensus was that end users shouldn't be left with a non-working system if they uninstall the driver. So maybe the solution it to have a restore mechanism in place (/usr/local/lib/pkg/restore?) that puts replaced files back. This is essentially what nvidia-driver is doing, not just with libGL. The challenge will to update the pkg that it replaced files for and to know that it should not install the files that are replaced in case of an upgrade of that package. This will also make things easier for users, because the current situation is that after an upgrade of Mesa, users will need to forcibly reinstall nvidia-driver to overwrite the libGL. -- Mel ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Fix nvidia-like ports, help needed
On Thu, Feb 23, 2012 at 01:35:02AM +, Alexey Dokuchaev wrote: On Wed, Feb 22, 2012 at 04:36:08PM -0700, John Hein wrote: One of the issues with 'alternatives' implementations is that they are not selectable per-user (including non superuser). In this particular case (libGL), also what about the native X server vs. virtual X servers that support using the mesa lib (per-application selection)? In addition to something like alternatives, another option is to allow installation of conflicting files (like libGL.so in this case) to separate directories and specify which to use using a path (like LD_LIBRARY_PATH or rpath at compile time). That can help with the aforementioned per-user and per-application variation. Personally, I prefer the path method over something like alternative sym links (e.g., debian/redhat alternatives). There can still be a front-end tool to get at the alternates configuration information, but I like the ability to set a path rather than a sym link. I tend to agree. While I currently do not see clearly the best solution to the problem, when I see etc/alternative.d I want to unsee it ASAP. For nvidia driver, it might be easier to simply provide a knob in xorg-server and libGL and perhaps register a dependency on nvidia-driver; no need to invent some cumbersome framework. Why not but which package will provide the libGL.so file? in all case the users might need to be able to switch the libGL.so file from the nvidia one to the mesa one, what would a user have to do for that, in particular a user using only binary packages where a file can't belong to 2 different packages without conflicting? if someone have a better solution than a framework for that I'm open but no the knob is not a solution for package people. regards, Bapt pgpOWDHIyIvYZ.pgp Description: PGP signature
