Re: [gentoo-user] [SOLVED] eselect-opengl Blockage (with a capital "B") problem
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 :-) :-)
Re: [gentoo-user] [SOLVED] eselect-opengl Blockage (with a capital "B") problem
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
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
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
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 :-) :-)
Re: [gentoo-user] [SOLVED] eselect-opengl Blockage (with a capital "B") problem
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 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
Re: [gentoo-user] [SOLVED] eselect-opengl Blockage (with a capital "B") problem
J. Roeleveld wrote:
> On 20 May 2020 05:44:58 CEST, Walter Dnes 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
Re: [gentoo-user] [SOLVED] eselect-opengl Blockage (with a capital "B") problem
On 20 May 2020 05:44:58 CEST, Walter Dnes 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
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 signature.asc Description: PGP signature
Re: [gentoo-user] [SOLVED] eselect-opengl Blockage (with a capital "B") problem
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 I don't run "desktop environments"; I run useful applications
Re: [gentoo-user] [SOLVED] eselect-opengl Blockage (with a capital "B") problem
On 18 May 2020 20:35:18 CEST, Walter Dnes 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.
[gentoo-user] [SOLVED] eselect-opengl Blockage (with a capital "B") problem
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 I don't run "desktop environments"; I run useful applications
