[SOLVED] Fewer, lower resolutions allowed for 1 monitor after upgrade

Gallaecio · 2024-03-02 11:52:59

I upgraded my system today (2024-03-02), last upgrade was last week (2024-02-24):

$ cat /var/log/pacman.log | grep -- -Syu | tail -n 3
[2024-02-24T16:26:35+0100] [PACMAN] Running 'pacman -Syu'
[2024-03-02T11:19:00+0100] [PACMAN] Running 'pacman -Syu'
[2024-03-02T11:30:44+0100] [PACMAN] Running 'pacman -Syu'

After reboot, one of my 2 screens had switched from 1920×1080 to 800×600, which is now the maximum resolution KDE allows me to set for that screen.

I sounds like https://bbs.archlinux.org/viewtopic.php?id=293180 (timing seems to match), but I don’t think their solutions works for me, although I am not completely sure if I actually applied them.

My Xorg logs are at https://invent.kde.org/-/snippets/3028, but I am not sure how to properly read them. I can tell DFP-0 is the screen stuck at 800×600, while DFP-2 is the one still at 1920×1080, and I guess that’s exactly what the final lines confirm:

[    15.767] (II) NVIDIA(0): Setting mode "HDMI-0: nvidia-auto-select @1920x1080 +0+0 {ViewPortIn=1920x1080, ViewPortOut=1920x1080+0+0}, DP-0: nvidia-auto-select @800x600 +0+0 {ViewPortIn=800x600, ViewPortOut=800x600+0+0}"
[    15.900] (II) NVIDIA(0): Setting mode "HDMI-0: nvidia-auto-select @1920x1080 +1920+0 {ViewPortIn=1920x1080, ViewPortOut=1920x1080+0+0}, DP-0: nvidia-auto-select @800x600 +0+0 {ViewPortIn=800x600, ViewPortOut=800x600+0+0}"

Based on feedback from https://bbs.archlinux.org/viewtopic.php?id=293180:

But most likely that's the simpledrm device, enable https://wiki.archlinux.org/title/NVIDIA … de_setting - use the "nvidia_drm.modeset=1" kernel parameter (modprobe.conf won't do!)

Based on the linked docs, I run:

# cat /sys/module/nvidia_drm/parameters/modeset
Y

Which I assume it means that the “DRM kernel mode setting” is already enabled in my system and there is nothing I need to do.

The feedback there also says:

stay away from fbdev=1 until nvidia has fixed that.

I am not 100% sure, but I think the following output confirms I am using efifb instead:

# journalctl -b | grep fbdev
# journalctl -b | grep efifb
Mar 02 12:19:17 vento kernel: pci 0000:2d:00.0: BAR 3: assigned to efifb
Mar 02 12:19:17 vento kernel: efifb: probing for efifb
Mar 02 12:19:17 vento kernel: efifb: showing boot graphics
Mar 02 12:19:17 vento kernel: efifb: framebuffer at 0xf1000000, using 8128k, total 8128k
Mar 02 12:19:17 vento kernel: efifb: mode is 1920x1080x32, linelength=7680, pages=1
Mar 02 12:19:17 vento kernel: efifb: scrolling: redraw
Mar 02 12:19:17 vento kernel: efifb: Truecolor: size=8:8:8:8, shift=24:16:8:0
# journalctl -b | grep vesafb

If xrandr shows one of your monitors is called "None-1" or so, it's the simpledrm device.

Not my case:

# xrandr 
Screen 0: minimum 8 x 8, current 3840 x 1080, maximum 32767 x 32767
DP-0 connected primary 800x600+0+0 (normal left inverted right x axis y axis) 530mm x 300mm
   800x600       75.00*+  60.32  
   720x576       50.00  
   720x480       59.94  
   640x480       99.99    75.00    59.94    59.93  
DP-1 disconnected (normal left inverted right x axis y axis)
HDMI-0 connected 1920x1080+1920+0 (normal left inverted right x axis y axis) 531mm x 298mm
   1920x1080     60.00*+  59.94    50.00  
   1680x1050     59.95  
   1600x900      60.00  
   1280x1024     75.02    60.02  
   1280x800      59.81  
   1280x720      60.00    59.94    50.00  
   1024x768      75.03    60.00  
   800x600       75.00    60.32  
   720x576       50.00  
   720x480       59.94  
   640x480       75.00    59.94    59.93  
DP-2 disconnected (normal left inverted right x axis y axis)
DP-3 disconnected (normal left inverted right x axis y axis)
DP-4 disconnected (normal left inverted right x axis y axis)
DP-5 disconnected (normal left inverted right x axis y axis)

If you've an nvidia GPU, enabling kms is between a very good idea and mandatory at this point.

I assume this is my case based on earlier output of “cat /sys/module/nvidia_drm/parameters/modeset”.

Make sure the nvidia kernel module loads at all!
(lsmod | grep nvidia)

Seems so:

# lsmod | grep nvidia
nvidia_drm            118784  19
nvidia_uvm           3477504  0
nvidia_modeset       1585152  45 nvidia_drm
nvidia              62402560  725 nvidia_uvm,nvidia_modeset
video                  77824  1 nvidia_modeset
i2c_nvidia_gpu         12288  0

Any tips?

So far I have tried:

Installing nvidia-dkms 550.54.14-3 from extra-testing (without actually switching to testing repos, or also installing any other package like the matching nvidia-utils one).
Rebuilding and installing nvidia-dkms 545.29.06-4 from https://gitlab.archlinux.org/archlinux/ … 8b0918805b (without also installing any other package like the matching nvidia-utils one), which I assume based on the commit dates that is a version that was working before for me (but I might be wrong).
Suspected linux-firmware, but the last update date is prior to my previous system update.
Tried https://askubuntu.com/a/413294 (commands at the bottom) replacing VGA-0 with DP-0, but the second command failed (X Error of failed request: BadMatch (invalid parameter attributes)).
Tried https://wiki.archlinux.org/title/xrandr … esolutions, however xrandr --newmode failed (X Error of failed request: BadName (named color or font does not exist)).

At this point I am thinking that either nvidia-dkms is not the issue, or that some other packages also need to change. But I am hesitant to experiment further blindly, and I am a bit afraid about doing a full switch to testing on this PC (I use it for work), something failing really bad, and not being able to get it back to work by Monday.

Last edited by Gallaecio (2024-03-03 09:17:05)

Gallaecio · 2024-03-02 12:37:37

I found out about https://wiki.archlinux.org/title/Arch_Linux_Archive through https://linuxconfig.org/how-to-rollback … arch-linux, and I reverted to package versions from 2024-02-23 with the following steps:

```
sudo cp /etc/pacman.d/mirrorlist{,~}
```

sudo nano /etc/pacman.d/mirrorlist

and set the content to

Server = https://archive.archlinux.org/repos/2024/02/23/$repo/os/$arch

```
sudo pacman --overwrite \* -Syyuu
```

After rebooting, I was again able to set the right resolution.

I will now upgrade day-by-day, see which day (and packages) triggered the issue.

Gallaecio · 2024-03-02 13:06:23

Damn, I did not see that coming.

The culprit is linux-zen, this partial upgrade re-introduces the issue:

[2024-03-02T14:02:09+0100] [ALPM] transaction started
[2024-03-02T14:02:10+0100] [ALPM] upgraded linux-zen (6.7.6.zen1-1 -> 6.7.6.zen1-2)
[2024-03-02T14:02:12+0100] [ALPM] upgraded linux-zen-headers (6.7.6.zen1-1 -> 6.7.6.zen1-2)
[2024-03-02T14:02:12+0100] [ALPM] transaction completed

Gallaecio · 2024-03-02 13:27:16

I got it wrong. The problem is mesa, but it only manifest after you reinstall the kernel, I’m guessing because of some of the pacman hooks.

Gallaecio · 2024-03-02 13:37:17

I have tried upgrading everything, then installing an earlier mesa from https://gitlab.archlinux.org/archlinux/ … f637106e0b with makepkg, and then reinistalling the linux-zen package to trigger its pacman hooks, but things still don’t work.

So it is clear to me that the new packages from 2024-03-01 caused the issue, but I am not exactly sure which one or how.

I’ll downgrade back to 2024-02-29 for now, and try upgrading again next week to see if things change.

Last edited by Gallaecio (2024-03-02 13:37:41)

seth · 2024-03-02 15:46:31

Please don't bump, just edit your previous post if nobody has yet replied.

If you have, post systme journal and xorg log of an affected boot.
nb. that

seth wrote:

But most likely that's the simpledrm device, enable https://wiki.archlinux.org/title/NVIDIA … de_setting - use the "nvidia_drm.modeset=1" kernel parameter (modprobe.conf won't do!)

checking the module parameter is meaningless.

sudo journalctl -b | grep -i simpledrm

Gallaecio · 2024-03-03 09:15:53

Upgrading today worked fine.

For the sake of it, I downgraded to 2024-03-02, and confirmed that with packages from yesterday it would remain broken.

At a broken state, the output of the command you suggested had the same output as with the working 2024-02-29 packages, though:

$ sudo journalctl -b | grep -i simpledrm
Mar 03 10:09:33 vento kernel: The simpledrm driver will not be probed

The re-upgrading to the latest from today, which made the following upgrades:

libadwaita-1:1.4.4-1  libfontenc-1.1.8-1  libunibreak-6.1-1  linux-zen-6.7.7.zen1-1 linux-zen-headers-6.7.7.zen1-1  mdadm-4.3-1  pahole-1:1.26-1

Got things working as expected. (the simpledrm command still outputs the same, though)

Arch Linux

#1 2024-03-02 11:52:59

[SOLVED] Fewer, lower resolutions allowed for 1 monitor after upgrade

#2 2024-03-02 12:37:37

Re: [SOLVED] Fewer, lower resolutions allowed for 1 monitor after upgrade

#3 2024-03-02 13:06:23

Re: [SOLVED] Fewer, lower resolutions allowed for 1 monitor after upgrade

#4 2024-03-02 13:27:16

Re: [SOLVED] Fewer, lower resolutions allowed for 1 monitor after upgrade

#5 2024-03-02 13:37:17

Re: [SOLVED] Fewer, lower resolutions allowed for 1 monitor after upgrade

#6 2024-03-02 15:46:31

Re: [SOLVED] Fewer, lower resolutions allowed for 1 monitor after upgrade

#7 2024-03-03 09:15:53

Re: [SOLVED] Fewer, lower resolutions allowed for 1 monitor after upgrade

Board footer