Fix nvidia-like ports, help needed

[Konstantin Belousov]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-ports/attachments/20120302/9bc2b931/attachment.pgp