[Testing Update] 2022-01-03 - OpenSearch 1.2.3, Nvidia 495.46, Wine 7.0-rc3, LibAdwaita 1.0, Mesa 21.3.3

Announcements Testing Updates
,
23

Thanks a lot for that update. This now seems to go to 495.46. Unfortunately, that version seems to be incompatible with kernel 5.16 yet:

==> dkms install --no-depmod nvidia/495.46 -k 5.16.0-1-MANJARO
Error! Bad return status for module build on kernel: 5.16.0-1-MANJARO (x86_64)
Consult /var/lib/dkms/nvidia/495.46/build/make.log for more information.
==> WARNING: `dkms install --no-depmod nvidia/495.46 -k 5.16.0-1-MANJARO' exited 10

UPDATE: For this problem, it looks like there is already a solution.
See mm/migrate.c: remove MIGRATE_PFN_LOCKED · torvalds/linux@ab09243 · GitHub for details.

As described there, the driver needs a small patch:

--- a/kernel/nvidia-uvm/uvm_migrate_pageable.c	2022-01-08 21:51:32.672454683 +0100
+++ b/kernel/nvidia-uvm/uvm_migrate_pageable.c	2022-01-08 21:51:52.298644944 +0100
@@ -406,7 +406,7 @@
         uvm_push_set_flag(&push, UVM_PUSH_FLAG_CE_NEXT_MEMBAR_NONE);
         copying_gpu->parent->ce_hal->memset_8(&push, dst_address, 0, PAGE_SIZE);
 
-        dst[i] = migrate_pfn(page_to_pfn(dst_page)) | MIGRATE_PFN_LOCKED;
+        dst[i] = migrate_pfn(page_to_pfn(dst_page));
     }
 
     if (copying_gpu) {
@@ -490,7 +490,7 @@
         uvm_push_set_flag(&push, UVM_PUSH_FLAG_CE_NEXT_MEMBAR_NONE);
         copying_gpu->parent->ce_hal->memcopy(&push, dst_address, src_address, PAGE_SIZE);
 
-        dst[i] = migrate_pfn(page_to_pfn(dst_page)) | MIGRATE_PFN_LOCKED;
+        dst[i] = migrate_pfn(page_to_pfn(dst_page));
     }
 
     // TODO: Bug 1766424: If the destination is a GPU and the copy was done by

But, with 496.46, the screen, especially in the terminal, starts to flicker, and sometimes, the terminal output even jumps up and down by one line, rendering the terminal almost unusable.

UPDATE This seems to be connected to the compositor. I am using picom here - as soon as I kill it, that jumping and flickering disappears.

And, my second screen gets disabled on every start.
Also, in contrast to former versions, I now have to start nvidia-settings with sudo to be able to apply any changes to display settings.
Unfortunately, even when I request the changes to be saved in the X configuration file, they do not survive a reboot - the second screen then gets disabled again.

Saving the nvidia-settings configuration and running nvidia-settings --load-config-only on login does not help - it looks like it is doing nothing.

24

Using EndeavourOS, 495.46 kept me from logging in, just returned me to the display manager. I ended up using the downgrade command to revert back to 495.44. Did this happen to anyone?

25

Are you lost? :thinking:

1 Like
26

yes to having to downgrade, though my issue was not that severe

27

I’m with Yochanan, are you lost?

1 Like
28

oldrocker99’s point could be to compare driver work under couple different OS environments. So I think they has at least that point.
Sometimes somebody get lost, sometimes others lacks to get payload idea of question. Payload for Manjaro could be comparison of work under another OS and oldrocker99 and

clarifies for us that it is a broad problem, not only Manjaro.
I think it is good to have such feedback also - to know is it a distros wide issue or Manjaro only: that info could point any user/dev to a possible issue solution which was applied under another environment to fix possible issues or to realize that it could be a package problem on GNU/Linux (or Arch-family distros).

1 Like
29

For me, with Nvidia driver 495.46, the second screen is always disabled after the system was started.
No matter what I tried, including “Save to X configuration file” in nvidia-settings, running nvidia-settings --load-config-only on login, nothing worked.

Currently, I have to enter something like

nvidia-settings --assign CurrentMetaMode="DVI-I-1: nvidia-auto-select +0+0 {ForceCompositionPipeline=On, ForceFullCompositionPipeline=On}, DVI-D-0: nvidia-auto-select +1920+0 {ForceCompositionPipeline=On, ForceFullCompositionPipeline=On};"

in a terminal after the desktop appeared.
Interestingly, this command doesn’t seem to do anything if included in .xinitrc, startxfce4 or in the list of programs running on startup.
Only if entered in a terminal on the first screen once the desktop has been fully drawn, the above command activates my second screen.

UPDATE

Seems that xfce4 is interfering here. After entering the command

nvidia-settings --assign CurrentMetaMode="DVI-I-1: nvidia-auto-select +0+0 {ForceCompositionPipeline=On, ForceFullCompositionPipeline=On}, DVI-D-0: nvidia-auto-select +1920+0 {ForceCompositionPipeline=On, ForceFullCompositionPipeline=On};"

I had to go to Settings, Display, choose my primary screen, set it to primary, and click Apply. Afterwards, I had to go to the second screen, and had to click Apply as well. Apparently, this now made my dual screen setup persistent.
A bit strange, though, as I do not remember having to do that before.

30

I couldn’t build vhba module for kernel 5.16 from this site:

https://gitlab.manjaro.org/packages/extra/linux516-extramodules/vhba-module

So i changed first sha sum in PKGBUILD file to:

72c5a8c1c452805e4cef8cafefcecc2d25ce197ae4c67383082802e5adcd77b6

just like in PKGBUILD file for vhba module for kernel 5.15 and it worked! :laughing: Well, i am too nooby to tell if this is how i should act but i feel kinda like a developer now XDDD

31

Everything went fine with the update and as far I can tell, all seems to be working as usual.

However, I have a question. I noticed info about pipewire:

I checked and I have it installed. However, I’m not sure if it’s enabled or doing something. Should I issue that command or not? I’m afraid I will mess up something and enable pipewire if it’s inactive, and then I won’t know how to reverse it. How can I find out if pipewire is active, and I use it (unknowingly)?

My system installation is quite old, probably near to 7 years, and I don’t remember all the things I’ve done so many years ago ;). It’s possible that I wanted to do something with pipewire but in the end I did nothing, so I’m not sure what it is doing (or not doing) in the system.

32

you can try inxi -Fza and look for

Sound Server-1: ALSA v: k5.16.0-1-MANJARO running: yes
Sound Server-2: JACK v: 1.9.19 running: no
Sound Server-3: PulseAudio v: 15.0 running: no
Sound Server-4: PipeWire v: 0.3.42 running: yes
33

Or straight to the point:

inxi -A | grep "Sound Server"

:wink:

1 Like
34

On Plasma with pulseaudio still in use inxi is getting:

$ inxi -A | grep -i sound
  Sound Server-1: ALSA v: k5.15.15-1-MANJARO running: yes
  Sound Server-2: PulseAudio v: 15.0 running: yes

AFAIK installation of manjaro-pipewire (vs manjaro-pulse) package “marks” the switch to pipewire audio server:

$ LANG=C pacman -Qi manjaro-pipewire manjaro-pulse | grep -i name
error: package 'manjaro-pipewire' was not found
Name            : manjaro-pulse
35

Thanks. I have:


  Sound Server-1: ALSA v: k5.15.12-1-MANJARO running: yes
  Sound Server-2: sndio v: N/A running: no
  Sound Server-3: JACK v: 1.9.19 running: no
  Sound Server-4: PulseAudio v: 15.0 running: yes
  Sound Server-5: PipeWire v: 0.3.42 running: yes

This whole sound system in Linux is too complicated and confusing for me. What does it mean, really? Is my sound generated from which server if both ALSA/Pulseaudio and Pipewire work? Which is default, how to switch forth and back? What happens if I use the recommended command for pipewire? Is it worth to use it instead of Pulseaudio? Are there any downsizes?

36

Manjaro KDE defaults to using manjaro-pulse (aka Pulse Audio), but you will see pipewire listed in the servers as well because a part of it is installed as a dependency of xdg-desktop-portal, which is installed as a dependency of manjaro-kde-settings.

If you want to “clean up” your audio servers there really is only one path that would not uninstall required dependencies (uninstalling pipewire would uninstall too many other important things) and that’s to install manjaro-pipewire which will replace manjaro-pulse.

Or you can leave things as is; the way the Manjaro team has developed the default.

37

Thanks, so what about the recommended command? Is it really needed. Will it change anything?

I know from experience, that sound system in Linux is not an easy thing, and tampering with it could have serious consequences.

So what enabling this service will do to my current setup?

systemctl --user enable pipewire-media-session

Will it change anything? What this command is really for?

Basically, the problem is with the fact, that this is recommended for pipewire users and in theory, I am one (I have pipwire installed and running, is it doing anything is another matter), but running any command without understanding what it is doing, especially with sound system, which is extremely complicated and confusing, is not wise. Currently, I have sound, so do I really need it? Or maybe I will need it if I want to switch from Pulse to Pipewire?

38

If you choose to stick with the default manjaro-pulse, then that pipewire command means nothing to you.

If you decide to try switching to manjaro-pipewire, then that command will become important… basically it will create a required symlink (if I recall correctly).

I am not an audiophile, nor a composer who jacks in tones of audio sources that I want to patch in to record amazing audio soundtracks… so really I just want to hear audio through my speakers/headsets and for my headset mic to be picked up as an audio source. In the “normal user” use case I think you’ll be happy with Pulse Audio (manjaro-pulse), and probably find little to no difference if you were to switch to manjaro-pipewire; whereas an audio composer might prefer “JACK” over PA.

AFAIK, I keep hearing that one day pipewire will replace pulseaudio… and because my use case is “normal”, I decided to give manjaro-pipewire a try and haven’t been disappointed yet.

1 Like
39