[gentoo-user] eselect-opengl Blockage (with a capital "B") problem

[gentoo-user] eselect-opengl Blockage (with a capital "B") problem

[Walter Dnes]

[-- Attachment #1: Type: text/plain, Size: 458 bytes --]

  The output from...

emerge -pv --changed-use --deep --update @world > log.txt 2>&1

...is attached, gzipped.  Problems with "Block".  My secondary machine
is about to undergo the python 3.6 to 3.7 upgrade if that means
anything.  I've tried the usual trick of unmerging eselect-opengl but
that didn't help.  A similar update went OK on my main machine.

-- 
Walter Dnes <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications

[-- Attachment #2: log.txt.gz --]
[-- Type: application/octet-stream, Size: 9218 bytes --]

Re: [gentoo-user] eselect-opengl Blockage (with a capital "B") problem

[Ashley Dixon]

[-- Attachment #1: Type: text/plain, Size: 903 bytes --]

On Mon, May 18, 2020 at 01:53:19PM -0400, Walter Dnes wrote:
>   The output from...
> emerge -pv --changed-use --deep --update @world > log.txt 2>&1
> 
> ...is attached, gzipped.  Problems with "Block".  My secondary machine
> is about to undergo the python 3.6 to 3.7 upgrade if that means
> anything.  I've tried the usual trick of unmerging eselect-opengl but
> that didn't help.  A similar update went OK on my main machine.

The mesa ebuild blocks eselect-opengl if the libglvnd USE-flag is set.   If  you
want eselect-opengl, remove the libglvnd flag.

        libglvnd? (
                >=media-libs/libglvnd-1.2.0-r1[X?,${MULTILIB_USEDEP}]
                !app-eselect/eselect-opengl
        )
        !libglvnd? (
                >=app-eselect/eselect-opengl-1.3.0
        )


-- 

Ashley Dixon
suugaku.co.uk

2A9A 4117
DA96 D18A
8A7B B0D2
A30E BF25
F290 A8AA


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] eselect-opengl Blockage (with a capital "B") problem

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 756 bytes --]

On Mon, 18 May 2020 13:53:19 -0400, Walter Dnes wrote:

> emerge -pv --changed-use --deep --update @world > log.txt 2>&1
> 
> ...is attached, gzipped. 

What a lot of updates! I'd emerge @system first, which will either give
the error with fewer other packages around, or proceed smoothly means
@world has less clutter.

> Problems with "Block".  My secondary machine
> is about to undergo the python 3.6 to 3.7 upgrade if that means
> anything.  I've tried the usual trick of unmerging eselect-opengl but
> that didn't help.  A similar update went OK on my main machine.

It looks like xorg-server is demanding the newer version, try adding
--exclude xorg-server.


-- 
Neil Bothwick

Windows Error #09: Game Over. Exiting Windows.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] eselect-opengl Blockage (with a capital "B") problem

[Ashley Dixon]

[-- Attachment #1: Type: text/plain, Size: 847 bytes --]

On Mon, May 18, 2020 at 07:09:13PM +0100, Neil Bothwick wrote:
> It looks like xorg-server is demanding the newer version, try adding
> --exclude xorg-server.

That will not help; mesa is providing libglvnd, not xorg-server.

[ebuild  N     ] media-libs/libglvnd-1.3.1::gentoo  USE="X -test" 698 KiB
[ebuild     U  ] media-libs/mesa-19.3.5::gentoo [19.2.8::gentoo] USE="X classic dri3 egl gbm gles2 libglvnd* -d3d9 -debug -gallium -gles1 -llvm -lm-sensors -opencl -osmesa -pax_kernel (-selinux) -test -unwind -vaapi -valgrind -vdpau -vulkan -vulkan-overlay -wayland -xa -xvmc" VIDEO_CARDS="i965 intel (-freedreno) -i915 -iris (-lima) -nouveau (-panfrost) -r100 -r200 -r300 -r600 -radeon -radeonsi (-vc4) -virgl (-vivante) -vmware" 11,783 KiB

-- 

Ashley Dixon
suugaku.co.uk

2A9A 4117
DA96 D18A
8A7B B0D2
A30E BF25
F290 A8AA


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[gentoo-user] [SOLVED] eselect-opengl Blockage (with a capital "B") problem

[Walter Dnes]

On Mon, May 18, 2020 at 07:07:32PM +0100, Ashley Dixon wrote
> On Mon, May 18, 2020 at 01:53:19PM -0400, Walter Dnes wrote:
> > 
> > ...is attached, gzipped.  Problems with "Block".  My secondary machine
> > is about to undergo the python 3.6 to 3.7 upgrade if that means
> > anything.  I've tried the usual trick of unmerging eselect-opengl but
> > that didn't help.  A similar update went OK on my main machine.
> 
> The mesa ebuild blocks eselect-opengl if the libglvnd USE-flag is set.
> If you want eselect-opengl, remove the libglvnd flag.

  Thank you very much.  I've got the update (156 packages) running now.
I had set "-libglvnd" in make.conf on my main machine, but only against
xorg-server on my secondary machine.  Setting "-libglvnd" in make.conf
solves the problem.

-- 
Walter Dnes <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications

Re: [gentoo-user] [SOLVED] eselect-opengl Blockage (with a capital "B") problem

[J. Roeleveld]

On 18 May 2020 20:35:18 CEST, Walter Dnes <waltdnes@waltdnes.org> wrote:
>On Mon, May 18, 2020 at 07:07:32PM +0100, Ashley Dixon wrote
>> On Mon, May 18, 2020 at 01:53:19PM -0400, Walter Dnes wrote:
>> > 
>> > ...is attached, gzipped.  Problems with "Block".  My secondary
>machine
>> > is about to undergo the python 3.6 to 3.7 upgrade if that means
>> > anything.  I've tried the usual trick of unmerging eselect-opengl
>but
>> > that didn't help.  A similar update went OK on my main machine.
>> 
>> The mesa ebuild blocks eselect-opengl if the libglvnd USE-flag is
>set.
>> If you want eselect-opengl, remove the libglvnd flag.
>
>  Thank you very much.  I've got the update (156 packages) running now.
>I had set "-libglvnd" in make.conf on my main machine, but only against
>xorg-server on my secondary machine.  Setting "-libglvnd" in make.conf
>solves the problem.

Only for now.
"Libglvnd" is scheduled to be removed as a USE flag.
I would definitely suggest to switch to having that one on before it becomes mandatory.

It has a lot of benefits over the eselect hack to be able to have multiple opengl implementations running.

--
Joost
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: [gentoo-user] [SOLVED] eselect-opengl Blockage (with a capital "B") problem

[Walter Dnes]

On Tue, May 19, 2020 at 03:14:03PM +0200, J. Roeleveld wrote
> >> On Mon, May 18, 2020 at 01:53:19PM -0400, Walter Dnes wrote:
> >
> >  Thank you very much.  I've got the update (156 packages) running now.
> >I had set "-libglvnd" in make.conf on my main machine, but only against
> >xorg-server on my secondary machine.  Setting "-libglvnd" in make.conf
> >solves the problem.
> 
> Only for now.
> "Libglvnd" is scheduled to be removed as a USE flag.  I would
> definitely suggest to switch to having that one on before it becomes
> mandatory.
> 
> It has a lot of benefits over the eselect hack to be able to have
> multiple opengl implementations running.

  The reason I had originally turned it off was because when it first
showed up as a flag, I checked Google to find out what it was.  Almost
every hit on webforums was like...

Person 1 - Help; my "update world" dies
Person 2 - Turn off "libglvnd" in make.conf
Person 1 - Thank you; my update works fine now

  Add me to the list.  If this is to be a new default config setup, I'd
appreciate a news item about it, like the python 3.6 to 3.7 switchover.

-- 
Walter Dnes <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications

Re: [gentoo-user] [SOLVED] eselect-opengl Blockage (with a capital "B") problem

[Ashley Dixon]

[-- Attachment #1: Type: text/plain, Size: 1394 bytes --]

On Tue, May 19, 2020 at 11:44:58PM -0400, Walter Dnes wrote:
>   The reason I had originally turned it off was because when it first
> showed up as a flag, I checked Google to find out what it was.  Almost
> every hit on webforums was like...
> 
> Person 1 - Help; my "update world" dies
> Person 2 - Turn off "libglvnd" in make.conf
> Person 1 - Thank you; my update works fine now

Even if it  didn't  break  block  eselect-opengl  with  mesa,  it  is  generally
extraneous for most non-NVIDIA users. From [1]:

        libglvnd is a vendor-neutral dispatch layer for arbitrating  OpenGL  API
        calls  between  multiple  vendors.   It  allows  multiple  drivers  from
        different vendors to coexist on  the  same  filesystem,  and  determines
        which vendor to dispatch each API call to at runtime.

See bug [2] and commit  [3]  for  details  regarding  the  breakages  in  X  for
modern-NVIDIA users without libglvnd.

(Video drivers do not actually require an X server to be present, as unless  the
`nomodesetting` parameter is given to the kernel, they can be initialised  pre-X
to provide high-resolution TTYs.)

[1] https://github.com/NVIDIA/libglvnd
[2] https://bugs.gentoo.org/711780
[3] cb625716155c239585d752e7c19d113afdeb91af on gentoo.git

-- 

Ashley Dixon
suugaku.co.uk

2A9A 4117
DA96 D18A
8A7B B0D2
A30E BF25
F290 A8AA


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] [SOLVED] eselect-opengl Blockage (with a capital "B") problem

[J. Roeleveld]

On 20 May 2020 05:44:58 CEST, Walter Dnes <waltdnes@waltdnes.org> wrote:
>On Tue, May 19, 2020 at 03:14:03PM +0200, J. Roeleveld wrote
>> >> On Mon, May 18, 2020 at 01:53:19PM -0400, Walter Dnes wrote:
>> >
>> >  Thank you very much.  I've got the update (156 packages) running
>now.
>> >I had set "-libglvnd" in make.conf on my main machine, but only
>against
>> >xorg-server on my secondary machine.  Setting "-libglvnd" in
>make.conf
>> >solves the problem.
>> 
>> Only for now.
>> "Libglvnd" is scheduled to be removed as a USE flag.  I would
>> definitely suggest to switch to having that one on before it becomes
>> mandatory.
>> 
>> It has a lot of benefits over the eselect hack to be able to have
>> multiple opengl implementations running.
>
>  The reason I had originally turned it off was because when it first
>showed up as a flag, I checked Google to find out what it was.  Almost
>every hit on webforums was like...
>
>Person 1 - Help; my "update world" dies
>Person 2 - Turn off "libglvnd" in make.conf
>Person 1 - Thank you; my update works fine now
>
>  Add me to the list.  If this is to be a new default config setup, I'd
>appreciate a news item about it, like the python 3.6 to 3.7 switchover.

I actually had to enable this on my new laptop before it became stable to get the Nvidia chip and my external displays working.
I am actually happy with this as I don't have to keep changing the opengl setting anymore when I need 3D performance.

--
Joost
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: [gentoo-user] [SOLVED] eselect-opengl Blockage (with a capital "B") problem

[Dale]

[-- Attachment #1: Type: text/plain, Size: 4188 bytes --]

J. Roeleveld wrote:
> On 20 May 2020 05:44:58 CEST, Walter Dnes <waltdnes@waltdnes.org> wrote:
>> On Tue, May 19, 2020 at 03:14:03PM +0200, J. Roeleveld wrote
>>>>> On Mon, May 18, 2020 at 01:53:19PM -0400, Walter Dnes wrote:
>>>>  Thank you very much.  I've got the update (156 packages) running
>> now.
>>>> I had set "-libglvnd" in make.conf on my main machine, but only
>> against
>>>> xorg-server on my secondary machine.  Setting "-libglvnd" in
>> make.conf
>>>> solves the problem.
>>> Only for now.
>>> "Libglvnd" is scheduled to be removed as a USE flag.  I would
>>> definitely suggest to switch to having that one on before it becomes
>>> mandatory.
>>>
>>> It has a lot of benefits over the eselect hack to be able to have
>>> multiple opengl implementations running.
>>  The reason I had originally turned it off was because when it first
>> showed up as a flag, I checked Google to find out what it was.  Almost
>> every hit on webforums was like...
>>
>> Person 1 - Help; my "update world" dies
>> Person 2 - Turn off "libglvnd" in make.conf
>> Person 1 - Thank you; my update works fine now
>>
>>  Add me to the list.  If this is to be a new default config setup, I'd
>> appreciate a news item about it, like the python 3.6 to 3.7 switchover.
> I actually had to enable this on my new laptop before it became stable to get the Nvidia chip and my external displays working.
> I am actually happy with this as I don't have to keep changing the opengl setting anymore when I need 3D performance.
>
> --
> Joost


Reading this thread, I checked and I to have this USE flag turned
off/disabled/whatever.  I removed it from make.conf and commented out
everything else I found in /etc/portage and am checking to see what all
had to be rebuilt.  I figure I may as well change now while I have a
otherwise stable system, except for the sddm-helper chewing memory
problem, and get ahead of the curve.  ;-)  Using that grep -r trick
comes in handy.  Learned that from this list too. 

It's odd how following a thread that may not even affect you ends up
doing so.  :/

Just in case, this is what emerge spit out on my screen. 


Calculating dependencies... done!
[ebuild   R    ] sys-libs/libblockdev-2.23-r1::gentoo  USE="cryptsetup
lvm tools -bcache -device-mapper -dmraid -escrow -gtk-doc -introspection
-kbd -test -vdo" PYTHON_SINGLE_TARGET="python3_7 -python3_6
(-python3_8)" 0 KiB
[ebuild   R    ] media-libs/libdvdnav-6.0.0::gentoo  USE="-static-libs"
ABI_X86="(64) -32 (-x32)" 0 KiB
[ebuild  N     ] media-libs/libglvnd-1.3.1::gentoo  USE="X -test"
ABI_X86="32 (64) (-x32)" 698 KiB
[ebuild   R   ~] media-libs/mesa-20.0.4-r1::gentoo  USE="X classic dri3
egl gallium gbm gles2 libglvnd* llvm wayland zstd -d3d9 -debug -gles1
-lm-sensors -opencl -osmesa (-selinux) -test -unwind -vaapi -valgrind
-vdpau -vulkan -vulkan-overlay -xa -xvmc" ABI_X86="32 (64) (-x32)"
VIDEO_CARDS="(-freedreno) -i915 -i965 -intel -iris (-lima) -nouveau
(-panfrost) -r100 -r200 -r300 -r600 -radeon -radeonsi (-vc4) -virgl
(-vivante) -vmware" 0 KiB
[blocks b      ] media-libs/mesa[-libglvnd(-)]
("media-libs/mesa[-libglvnd(-)]" is blocking media-libs/libglvnd-1.3.1)
[ebuild   R    ] sys-libs/libcap-2.26-r2::gentoo  USE="pam (split-usr)
-static-libs" ABI_X86="32 (64) (-x32)" 0 KiB
[ebuild   R    ] x11-drivers/nvidia-drivers-440.82:0/440::gentoo  USE="X
acpi driver gtk3 kms libglvnd* multilib tools -compat -static-libs -uvm
-wayland" ABI_X86="32 (64) (-x32)" 0 KiB
[ebuild   R    ] x11-base/xorg-server-1.20.7:0/1.20.7::gentoo 
USE="elogind ipv6 libglvnd* suid udev xorg -debug -dmx -doc -kdrive
-libressl -minimal (-selinux) -static-libs -systemd -unwind -wayland
-xcsecurity -xephyr -xnest -xvfb" 0 KiB
[uninstall     ] app-eselect/eselect-opengl-1.3.1-r4::gentoo
[blocks b      ] app-eselect/eselect-opengl
("app-eselect/eselect-opengl" is blocking
x11-drivers/nvidia-drivers-440.82, x11-base/xorg-server-1.20.7,
media-libs/mesa-20.0.4-r1)



Now let us pray to the portage gods for a happy outcome.  o_O

Dale

:-)  :-) 

P. S. Between this and finding that weird The Black Bird movie from
1975, I'm having a good day.  ROFL

[-- Attachment #2: Type: text/html, Size: 5808 bytes --]

Re: [gentoo-user] [SOLVED] eselect-opengl Blockage (with a capital "B") problem

[Victor Ivanov]

[-- Attachment #1.1: Type: text/plain, Size: 5357 bytes --]

When the lbglvnd flag was introduced I remember I solved this issue by:

    # emerge --unmerge eselect-opengl
    # emerge -1qv mesa

After that, a simple update of @world rebuilt everything else on its own.

Personally, I had been waiting for libglvnd support for _a long time_.
This - and I mean GLVND in general - is something that should have come
to Linux many years ago, along with NVIDIAs PRIME render offloading.

10y ago I used to have an Optimus laptop with an Nvidia GPU and it was
an absolute hell to get it running, I remember writing tonnes of scripts
using VirtualGL and a dummy X server running on the Nvidia GPU. This was
before bumblebee.

Today, I still need this with an external GPU.

But now it takes 1 environment variable to offload to the other GPU!
GLVND literally made my Linux work experience a million times better.
I'm extatic.

- V

On 20/05/2020 07:07, Dale wrote:
> J. Roeleveld wrote:
>> On 20 May 2020 05:44:58 CEST, Walter Dnes <waltdnes@waltdnes.org> wrote:
>>> On Tue, May 19, 2020 at 03:14:03PM +0200, J. Roeleveld wrote
>>>>>> On Mon, May 18, 2020 at 01:53:19PM -0400, Walter Dnes wrote:
>>>>>  Thank you very much.  I've got the update (156 packages) running
>>> now.
>>>>> I had set "-libglvnd" in make.conf on my main machine, but only
>>> against
>>>>> xorg-server on my secondary machine.  Setting "-libglvnd" in
>>> make.conf
>>>>> solves the problem.
>>>> Only for now.
>>>> "Libglvnd" is scheduled to be removed as a USE flag.  I would
>>>> definitely suggest to switch to having that one on before it becomes
>>>> mandatory.
>>>>
>>>> It has a lot of benefits over the eselect hack to be able to have
>>>> multiple opengl implementations running.
>>>  The reason I had originally turned it off was because when it first
>>> showed up as a flag, I checked Google to find out what it was.  Almost
>>> every hit on webforums was like...
>>>
>>> Person 1 - Help; my "update world" dies
>>> Person 2 - Turn off "libglvnd" in make.conf
>>> Person 1 - Thank you; my update works fine now
>>>
>>>  Add me to the list.  If this is to be a new default config setup, I'd
>>> appreciate a news item about it, like the python 3.6 to 3.7 switchover.
>> I actually had to enable this on my new laptop before it became stable to get the Nvidia chip and my external displays working.
>> I am actually happy with this as I don't have to keep changing the opengl setting anymore when I need 3D performance.
>>
>> --
>> Joost
> 
> 
> Reading this thread, I checked and I to have this USE flag turned
> off/disabled/whatever.  I removed it from make.conf and commented out
> everything else I found in /etc/portage and am checking to see what all
> had to be rebuilt.  I figure I may as well change now while I have a
> otherwise stable system, except for the sddm-helper chewing memory
> problem, and get ahead of the curve.  ;-)  Using that grep -r trick
> comes in handy.  Learned that from this list too. 
> 
> It's odd how following a thread that may not even affect you ends up
> doing so.  :/
> 
> Just in case, this is what emerge spit out on my screen. 
> 
> 
> Calculating dependencies... done!
> [ebuild   R    ] sys-libs/libblockdev-2.23-r1::gentoo  USE="cryptsetup
> lvm tools -bcache -device-mapper -dmraid -escrow -gtk-doc -introspection
> -kbd -test -vdo" PYTHON_SINGLE_TARGET="python3_7 -python3_6
> (-python3_8)" 0 KiB
> [ebuild   R    ] media-libs/libdvdnav-6.0.0::gentoo  USE="-static-libs"
> ABI_X86="(64) -32 (-x32)" 0 KiB
> [ebuild  N     ] media-libs/libglvnd-1.3.1::gentoo  USE="X -test"
> ABI_X86="32 (64) (-x32)" 698 KiB
> [ebuild   R   ~] media-libs/mesa-20.0.4-r1::gentoo  USE="X classic dri3
> egl gallium gbm gles2 libglvnd* llvm wayland zstd -d3d9 -debug -gles1
> -lm-sensors -opencl -osmesa (-selinux) -test -unwind -vaapi -valgrind
> -vdpau -vulkan -vulkan-overlay -xa -xvmc" ABI_X86="32 (64) (-x32)"
> VIDEO_CARDS="(-freedreno) -i915 -i965 -intel -iris (-lima) -nouveau
> (-panfrost) -r100 -r200 -r300 -r600 -radeon -radeonsi (-vc4) -virgl
> (-vivante) -vmware" 0 KiB
> [blocks b      ] media-libs/mesa[-libglvnd(-)]
> ("media-libs/mesa[-libglvnd(-)]" is blocking media-libs/libglvnd-1.3.1)
> [ebuild   R    ] sys-libs/libcap-2.26-r2::gentoo  USE="pam (split-usr)
> -static-libs" ABI_X86="32 (64) (-x32)" 0 KiB
> [ebuild   R    ] x11-drivers/nvidia-drivers-440.82:0/440::gentoo  USE="X
> acpi driver gtk3 kms libglvnd* multilib tools -compat -static-libs -uvm
> -wayland" ABI_X86="32 (64) (-x32)" 0 KiB
> [ebuild   R    ] x11-base/xorg-server-1.20.7:0/1.20.7::gentoo 
> USE="elogind ipv6 libglvnd* suid udev xorg -debug -dmx -doc -kdrive
> -libressl -minimal (-selinux) -static-libs -systemd -unwind -wayland
> -xcsecurity -xephyr -xnest -xvfb" 0 KiB
> [uninstall     ] app-eselect/eselect-opengl-1.3.1-r4::gentoo
> [blocks b      ] app-eselect/eselect-opengl
> ("app-eselect/eselect-opengl" is blocking
> x11-drivers/nvidia-drivers-440.82, x11-base/xorg-server-1.20.7,
> media-libs/mesa-20.0.4-r1)
> 
> 
> 
> Now let us pray to the portage gods for a happy outcome.  o_O
> 
> Dale
> 
> :-)  :-) 
> 
> P. S. Between this and finding that weird The Black Bird movie from
> 1975, I'm having a good day.  ROFL


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] [SOLVED] eselect-opengl Blockage (with a capital "B") problem

[Dale]

[-- Attachment #1: Type: text/plain, Size: 1665 bytes --]

Victor Ivanov wrote:
> When the lbglvnd flag was introduced I remember I solved this issue by:
>
>     # emerge --unmerge eselect-opengl
>     # emerge -1qv mesa
>
> After that, a simple update of @world rebuilt everything else on its own.
>
> Personally, I had been waiting for libglvnd support for _a long time_.
> This - and I mean GLVND in general - is something that should have come
> to Linux many years ago, along with NVIDIAs PRIME render offloading.
>
> 10y ago I used to have an Optimus laptop with an Nvidia GPU and it was
> an absolute hell to get it running, I remember writing tonnes of scripts
> using VirtualGL and a dummy X server running on the Nvidia GPU. This was
> before bumblebee.
>
> Today, I still need this with an external GPU.
>
> But now it takes 1 environment variable to offload to the other GPU!
> GLVND literally made my Linux work experience a million times better.
> I'm extatic.
>
> - V
>

My change went quite well here.  I removed the flag entry everywhere and
then did a emerge world, with the correct options of course.  I then
logged out, went to boot runlevel, reloaded the video drivers, went back
to default and logged in.  I can't tell any difference here video wise
tho. 

I did notice that my sddm problem is worse now.  It's worse now than it
was when it first started.  In just a few hours it is consuming over
4GBs of memory.  That is ridiculous to me.  It using more than Firefox,
both profiles, and any other software I have running.  I'm thinking
about looking for a alternative to sddm.  I switched to it a while back
but I don't like this memory hungry thing behaving this way. 

Dale

:-)  :-) 

[-- Attachment #2: Type: text/html, Size: 2075 bytes --]

Re: [gentoo-user] [SOLVED] eselect-opengl Blockage (with a capital "B") problem

[J. Roeleveld]

Please don't top-post.

On Wednesday, May 20, 2020 1:37:45 PM CEST Victor Ivanov wrote:
> When the lbglvnd flag was introduced I remember I solved this issue by:
> 
>     # emerge --unmerge eselect-opengl
>     # emerge -1qv mesa
> 
> After that, a simple update of @world rebuilt everything else on its own.
> 
> Personally, I had been waiting for libglvnd support for _a long time_.
> This - and I mean GLVND in general - is something that should have come
> to Linux many years ago, along with NVIDIAs PRIME render offloading.
> 
> 10y ago I used to have an Optimus laptop with an Nvidia GPU and it was
> an absolute hell to get it running, I remember writing tonnes of scripts
> using VirtualGL and a dummy X server running on the Nvidia GPU. This was
> before bumblebee.
> 
> Today, I still need this with an external GPU.
> 
> But now it takes 1 environment variable to offload to the other GPU!
> GLVND literally made my Linux work experience a million times better.
> I'm extatic.
> 
> - V
> 

It is precisely why I had to implement GLVND before it became stable (using 
external overlays even and manually adding patches)

My new laptop doesn't work at all with bumblebee, because the external display 
ports are connected to the nvidia-chip and not to the intel-chip.
If reverse-PRIME would be supported, I would be able to disable the nvidia-
chip during 80% of the time and only enable it when playing games.

--
Joost

Re: [gentoo-user] [SOLVED] eselect-opengl Blockage (with a capital "B") problem

[J. Roeleveld]

On Wednesday, May 20, 2020 2:10:14 PM CEST Dale wrote:
> Victor Ivanov wrote:
> > When the lbglvnd flag was introduced I remember I solved this issue by:
> >     # emerge --unmerge eselect-opengl
> >     # emerge -1qv mesa
> > 
> > After that, a simple update of @world rebuilt everything else on its own.
> > 
> > Personally, I had been waiting for libglvnd support for _a long time_.
> > This - and I mean GLVND in general - is something that should have come
> > to Linux many years ago, along with NVIDIAs PRIME render offloading.
> > 
> > 10y ago I used to have an Optimus laptop with an Nvidia GPU and it was
> > an absolute hell to get it running, I remember writing tonnes of scripts
> > using VirtualGL and a dummy X server running on the Nvidia GPU. This was
> > before bumblebee.
> > 
> > Today, I still need this with an external GPU.
> > 
> > But now it takes 1 environment variable to offload to the other GPU!
> > GLVND literally made my Linux work experience a million times better.
> > I'm extatic.
> > 
> > - V
> 
> My change went quite well here.  I removed the flag entry everywhere and
> then did a emerge world, with the correct options of course.  I then
> logged out, went to boot runlevel, reloaded the video drivers, went back
> to default and logged in.  I can't tell any difference here video wise
> tho. 
> 
> I did notice that my sddm problem is worse now.  It's worse now than it
> was when it first started.  In just a few hours it is consuming over
> 4GBs of memory.  That is ridiculous to me.  It using more than Firefox,
> both profiles, and any other software I have running.  I'm thinking
> about looking for a alternative to sddm.  I switched to it a while back
> but I don't like this memory hungry thing behaving this way. 

I missed the whole thing you are having with sddm, I just checked it on my 
laptop and not seeing anything like that.
Will reply further in the sddm-thread if I have any ideas.

--
Joost

Re: [gentoo-user] [SOLVED] eselect-opengl Blockage (with a capital "B") problem

[Dr Rainer Woitok]

Dale,

On Wednesday, 2020-05-20 07:10:14 -0500, you wrote:

> ...
> I did notice that my sddm problem is worse now.  It's worse now than it
> was when it first started.

Ever tried "x11-misc/lightdm"?  Runs like a charm here ...

Sincerely,
  Rainer

Re: [gentoo-user] [SOLVED] eselect-opengl Blockage (with a capital "B") problem

[Dale]

[-- Attachment #1: Type: text/plain, Size: 765 bytes --]

Dr Rainer Woitok wrote:
> Dale,
>
> On Wednesday, 2020-05-20 07:10:14 -0500, you wrote:
>
>> ...
>> I did notice that my sddm problem is worse now.  It's worse now than it
>> was when it first started.
> Ever tried "x11-misc/lightdm"?  Runs like a charm here ...
>
> Sincerely,
>   Rainer
>


I googled and found it as a alternative.  It was next on my list.  It
might have been a temporary switch but the logging out and back in as
getting on my nerve.  My puter stays to busy for that sort of thing. 
Once a week after updates is plenty for me. 

Thanks for the idea tho.  It's my backup plan.  So far tho, sddm using
the exact same amount of memory it was when I first logged in. From ps:

root     23338  0.0  0.0  54528 14400

Dale

:-)  :-) 

[-- Attachment #2: Type: text/html, Size: 1291 bytes --]