You forgot to add
Option "ModeValidation" "NoExtendedGpuCapabilitiesCheck"
You will need this due to a driver bug.
When you can see the scaling modes in nvidia-settings, can you switch to them there?
When you used
xrandr --output DP-0 --scale 2x2
where you using the nvidia-driver or nouveau?
I can switch to these modes and with adding the Option line it accept this mode.
But inside of KDE it’s still 3840x2160 active. So the screen its setting to 1920x1080 but I only see part of the desk so I need to move with the mouse to get access to menu for instance… strange behaviour…
I have two nvme-SSDs original in raid - but linux was unable to install on a software raid. So I set them as two single SSDs. On that are two different test-systems (Mageia, and Openmandriva, one with nvidia 382.22 and one with 378 driver line) and on main harddisk is rosalinux. The main system was unable to install on nvme-SSDs. I will at first have stable settings before I try it wih my main system, who runs actually with the nouveau-driver.
Maybe try to replace
Option "ModeValidation" "NoExtendedGpuCapabilitiesCheck"
with
Option "ModeValidation" "NoExtendedGpuCapabilitiesCheck; AllowNonEdidModes"
Thank you for your answer. Unfortunately it’s changes nothing.
What I not understand - how can the nouveau driver recognise everything correctly and the native driver of nvidia not. It’s there maybe a way to export the correct modes from the nvidia-windowsdriver which is working correctly? Or maybe the linux-kernel can send the modes to nvidia-driver in a way?
Can you please add Option “ModeDebug” “true” again and post another xorg.log with the new option?
The background is, the EDID data of your display cantains the setting “Supports Continuous Frequency: No”. This means, it tells the driver it can handle only one display resolution. So all other modes either VESA, XServer or user defined ones get rejected so you simply can’t add any modes. You can see that in the logs: “Mode is rejected: Only EDID-provided modes are allowed”. The nvidia driver handles this strict, the nouveau driver more relaxed, at least from my observation. Simply put, nouveau allows you to bomb your CRT, nvidia not (easily). It was an attempt to change it with allownonedidmodes. It might be interesting to run the nouveau driver with option modedebug true to see how it handles modes differently.
Another question is why the metamodes of the nvidia driver don’t work or at least are useless. Maybe something to start a new thread.
Another way would be to make a custom edid and load that.
I add the Option “ModeDebug” “true” again and post the xorg.log with the new option.
To, your answer… I understand that the nouveau driver handles it not so strict. But the nvidia-driver in windows must be than also strict like under linux… or he get the information from the driver-CD from the producer (msi)?
Xorg.0.log.txt (140 KB)
As I thought, now the modes are rejected because they’re not inside the hsync/vrefresh values the display is advertising. While it is possible to override this I think you should leave it alone. Your display just don’t want to scale so it possibly simply can’t.
I’ve taken a glance at the nouveau kms code and the secret is not that nouveau is more relaxed but it’s using implicit gpu scaling for non-edid modes through drm/kms.
The binary nvidia-driver also provides a minimal drm kms implementation but I don’t know if those kind of things are implemented. Worth a try: add
nvidia-drm.modeset=1
to your kernel parameters. (might be different depending on distro). You can check if it’s activated with
dmesg |grep drm
Among others, this should give you the two lines
[drm] [nvidia-drm] [GPU ID 0x00000700] Loading driver
[drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
Afterward, check with
xrandr --prop
if the nvidia kms supports scaling modes.
It should talk about scaling mode:
scaling mode: Full aspect
supported: None, Full, Center, Full aspect
If not, it’s not implemented.
Another possibility if gpu scaling doesn’t work is to use PRIME, since then the intel gpu is responsible for modesetting and scaling.
Enable only nvidia gpu. Backup your xorg.conf file. Simply running nvidia-xconfig and startx won’t start X ? How did you get xrandr output in first place. Please provide nvidia bug report as soon as issue hit? The nvidia-bug-report.sh will collect information about your system and create the file ‘nvidia-bug-report.log.gz’ in the current directory. Did you made and custom setting in SBIOS or display related that is triggering this issue? Also please share url showing specs of your laptop? Is SSDs have anything to do with this issue?
@ generix:
I add on the kernel nvidia-drm.modeset=1, and additional like on NVIDIA - ArchWiki
in modules file: nvidia, nvidia_modeset, nvidia_uvm and nvidia_drm
so:
lsmod |grep nvidia
nvidia_drm 45056 1
drm_kms_helper 135168 1 nvidia_drm
drm 335872 4 nvidia_drm,drm_kms_helper
nvidia_uvm 626688 0
nvidia_modeset 811008 13 nvidia_drm
nvidia 11542528 390 nvidia_modeset,nvidia_uvm
dmesg |grep drm
dmesg | grep drm
[ 0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-4.9.32-desktop-1.mga6 root=UUID=7caf7e8a-c89b-4bc7-88ef-a569f929daa1 ro splash quiet nvidia-drm.modeset=1 resume=UUID=ef9e6dba-7858-4648-8329-cfb2dbe85393 audit=0
[ 0.000000] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.9.32-desktop-1.mga6 root=UUID=7caf7e8a-c89b-4bc7-88ef-a569f929daa1 ro splash quiet nvidia-drm.modeset=1 resume=UUID=ef9e6dba-7858-4648-8329-cfb2dbe85393 audit=0
[ 3.792861] [drm] Initialized
[ 3.800230] [drm] [nvidia-drm] [GPU ID 0x00000100] Loading driver
[ 4.898794] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[ 4.898794] [drm] No driver support for vblank timestamp query.
xrandr --prop
Screen 0: minimum 8 x 8, current 3840 x 2160, maximum 16384 x 16384
DP-0 connected primary 1920x1080+0+67 (normal left inverted right x axis y axis) 382mm x 214mm panning 3840x2160+0+0
CscMatrix: 65536 0 0 0 0 65536 0 0 0 0 65536 0
Backlight: 100
range: (0, 100)
EDID:
00ffffffffffff0006af9b1000000000
00190104a5261578022425a85036b626
0e505400000001010101010101010101
01010101010166d000a0f0703e803020
35007ed6100000180000000f00000000
00000000000000000020000000fe0041
554f0a202020202020202020000000fe
00423137335a414e30312e30200a003b
BorderDimensions: 4
supported: 4
Border: 0 0 0 0
range: (0, 65535)
SignalFormat: DisplayPort
supported: DisplayPort
ConnectorType: Panel
ConnectorNumber: 6
_ConnectorLocation: 6
3840x2160 60.02*+
I see an interesting detail: It’s just like before, but when I go to nvidia-settings and activiate an other scaling mode, for instance 1920x1200 (it’s with scrolling too) and back to 1920x1080 it’s working correctly - without scrolling. But only until next booting.
edit: this is only working on Mageia system with self compiled 381.22 drivers, not with Openmandriva and 375.66 rpms.
I can activate only one gpu at same time, because I have an hardware switch button.
If I simply run only nvidia-xconfig, x won’t start. I have necessary to add Option “ModeValidation” “NoExtendedGpuCapabilitiesCheck” - only with it the x-server is starting.
xrandr output with nouveau driver is:
Screen 0: minimum 320 x 200, current 3840 x 2160, maximum 16384 x 16384
DP-1 disconnected (normal left inverted right x axis y axis)
DP-2 disconnected (normal left inverted right x axis y axis)
eDP-1 connected primary 3840x2160+0+0 (normal left inverted right x axis y axis) 382mm x 214mm
3840x2160 60.02*+
2048x1536 60.00
1920x1440 60.00
1856x1392 60.01
1792x1344 60.01
1920x1200 59.95
1920x1080 60.00
1600x1200 60.00 59.95
1680x1050 60.00
1400x1050 59.98 60.00
1280x1024 59.95 60.02
1280x960 60.00 59.99
1152x864 59.97
1024x768 60.04 60.00 59.95
960x720 60.00
928x696 60.05
896x672 60.01
800x600 60.00 60.32 59.96 56.25
700x525 59.98
640x512 60.02
640x480 60.00 59.94 59.94
720x400 59.97
640x400 59.96
640x350 59.84
512x384 60.00
400x300 60.32 56.34
320x240 60.05
HDMI-1 disconnected (normal left inverted right x axis y axis)
and with nvidia(normally):
Screen 0: minimum 8 x 8, current 3840 x 2160, maximum 16384 x 16384
HDMI-0 disconnected (normal left inverted right x axis y axis)
DP-0 connected primary 3840x2160+0+0 (normal left inverted right x axis y axis) 382mm x 214mm
3840x2160 60.02*+
DP-1 disconnected (normal left inverted right x axis y axis)
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)
with this double nvidia-settings trick( as described before)
Screen 0: minimum 8 x 8, current 1920 x 1080, maximum 16384 x 16384
HDMI-0 disconnected (normal left inverted right x axis y axis)
DP-0 connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 382mm x 214mm
3840x2160 60.02*+
DP-1 disconnected (normal left inverted right x axis y axis)
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)
In Bios there is not possible to set anything about graphic card.
The SSD’s have nothing to do with this topic, on the usual harddisc there is an linux system too, with same problems.
The specs of my laptop is showing here:
Thank you,
Tomas
nvidia-bug-report.log.gz (277 KB)
The problem with distro packaged drivers is that they often rename the driver, e.g. nvidia_drm_375 instead of nvidi-drm. Use lsmod to see how they named the driver and change nvidia-drm.modeset=1 accordingly.
One thing you missed previously is to run
xrandr -q1
and see if the metamodes are there then. Those should be settable with
xrandr --size 1920x1080
This uses xrandr V1 screen size commands.
Yes, these modes are showing and settable. It’s seams that is exactly what nvidia-settings do.
xrandr --q1
SZ: Pixels Physical Refresh
*0 1920 x 1080 ( 381mm x 211mm ) *50
1 3840 x 2160 ( 762mm x 422mm ) 51
2 2560 x 1600 ( 508mm x 312mm ) 52
3 2560 x 1440 ( 508mm x 281mm ) 53
4 1920 x 1200 ( 381mm x 234mm ) 54
5 1680 x 1050 ( 333mm x 205mm ) 55
6 1600 x 1200 ( 317mm x 234mm ) 56
7 1440 x 900 ( 285mm x 175mm ) 57
8 1366 x 768 ( 271mm x 150mm ) 58
9 1280 x 1024 ( 254mm x 200mm ) 59
10 1280 x 800 ( 254mm x 156mm ) 60
11 1280 x 720 ( 254mm x 140mm ) 61
12 1024 x 768 ( 203mm x 150mm ) 62
13 800 x 600 ( 158mm x 117mm ) 63
14 640 x 480 ( 127mm x 93mm ) 64
Current rotation - normal
Current reflection - none
Rotations possible - normal left inverted right
Reflections possible - X Axis Y Axis
But it’s the scrolling mode, So I try:
xrandr --size 1920x1080
And it works. But after next booting is still the same problem with scrolling.
It’s there a way to auto start “xrandr --size 1920x1080” before starting the xserver ?
Worth a try would be to add
Virtual 1920 1080
to the display subsection of the screen section. According to the logs the driver is setting this but you never now.
Other than that, you can of course use an autostart entry depending on your desktop environment. E.g. in ~/.config/autostart or /etc/xdg/autostart as a workaround. The login manager probably uses its own autostart directory, e.g. gdm in /usr/share/gdm/greeter/autostart/.
Thank you very much!
The Virtual 1920 1080 in screen section not helps, but after that I create a xrandr.desktop in my ~/.config/autostart with Exec=xrandr --size 1920x1080
And now, thanks to you, I have workaround. For now it’s a big step forward for me, so I can begin to migrate my main system.
If there are new versions of the driver I can try out if there are other possibilities too, but for now I am satisfied.
Best Regards,
Tomas
Thought so, the Virtual setting is mostly ignored with modern DEs, they are setting up the screen on its own. Nvidia metamodes implementation is quite outdated as it seems, badly interacting with newer randr implementations. I hope they’re working on something better with their KMS implementation. Needs some renovation badly.
Hi Tomas, We would like to investigate if this is bug. Just create xorg.conf file with debug mode option, start X and run nvidia-bug-report. Please don’t add any other xorg.conf options. We want to see why all modes are skipping. Please test with latest nvidia driver also from Index of /XFree86/Linux-x86_64 . Please share repro steps if there any difference.
Hi Sandip, thank you very much for your offer!
I would be very happy if you find a way out of it.
I have already downloaded and installed the last driver, Version 381.22
As you propose I create the xorg.conf with --mode-debug - I add the file, as well as the xorg.0.log and finally the nvidia-bug-report
Oh … I see that he use my xorg.conf file as base of his configuration…
So I again do it without an xorg.conf. – all called .2.txt or 2.gz
xorg.conf.txt (2.31 KB)
Xorg.0.log.txt (166 KB)
nvidia-bug-report.log.gz (285 KB)
xorg.conf.2.txt (1.48 KB)
Xorg.0.log.2.txt (123 KB)
nvidia-bug-report.log.gz.2.gz (223 KB)
We are tracking this issue under 200326861 . Test with 384.47 (beta) too. https://devtalk.nvidia.com/default/topic/1016125 . Also earlier driver versions worked on your setup?
Hi tomek12, I think you have workaround for this issue. We tried with custom edid but not able to reproduce this issue. I think we need exact notebook or panel to trigger this issue.