[SOLVED] Monitors sometimes recognized wrong

Tharbad · 2025-07-11 19:59:42

Hi,

For years now I have this problem.
Wrong means: Monitor is detected as generic nvidia monitor with 640x480 resolution. On rare occasion it might just turn that monitor off.

However in the last few weeks it got worse:

When a monitor isn't recognized I disconnect the problematic monitor/s (I've 3 monitors) and reconnect them and the problem is solved.
In the last few weeks however, disconnecting one monitor might cause another to be recognized wrong.

Log is here: https://pastebin.com/numKZZhg
(Filtered out non relevant parts)
This is the log from today return from hibernate.
Today one monitor was recognized fine. 2 were recognized as generic.
After the 2nd disconnect one screen turned off (but stayed recognized fine)

What I did in the last few years:
1 Changed 3 GPU. All nvidia.
2 Changed cables. At least once for each monitor. Also moved all of them from DVI to DP.
3 Changed CPU 3 times. MB 2 times.
4 Monitors never changed. => Yes. It could be the problem. Bought them in 2013/4.

Ideas? How to verify it's the monitors fault?

Solution:
Deleted all nvidia related config files (That was generated by nvidia driver).

Thanks

Last edited by Tharbad (2025-07-20 07:12:24)

seth · 2025-07-12 08:42:30

This is on X11?
Please post your Xorg log, https://wiki.archlinux.org/title/Xorg#General after this happens along "xrandr --verbose" when things are fine and when they're not.
Also

for OUT in /sys/class/drm/card*; do echo $OUT; edid-decode $OUT/edid; echo "================="; done

in both conditions.
You'll need https://archlinux.org/packages/extra/x86_64/v4l-utils/

Jul 11 15:43:40 <PC Name> org_kde_powerdevil[4974]:    Connector:    card0-DP-1
Jul 11 15:43:40 <PC Name> org_kde_powerdevil[4974]:       i2c_busno:    -1
Jul 11 15:43:40 <PC Name> org_kde_powerdevil[4974]:       connector_id: 92
Jul 11 15:43:40 <PC Name> org_kde_powerdevil[4974]:       name:         (null)
Jul 11 15:43:40 <PC Name> org_kde_powerdevil[4974]:       enabled:      disabled
Jul 11 15:43:40 <PC Name> org_kde_powerdevil[4974]:       status:       connected
Jul 11 15:43:40 <PC Name> org_kde_powerdevil[4974]:       edid:         None
Jul 11 15:43:40 <PC Name> org_kde_powerdevil[4974]:    Connector:    card0-DP-2
Jul 11 15:43:40 <PC Name> org_kde_powerdevil[4974]:       i2c_busno:    -1
Jul 11 15:43:40 <PC Name> org_kde_powerdevil[4974]:       connector_id: 99
Jul 11 15:43:40 <PC Name> org_kde_powerdevil[4974]:       name:         (null)
Jul 11 15:43:40 <PC Name> org_kde_powerdevil[4974]:       enabled:      disabled
Jul 11 15:43:40 <PC Name> org_kde_powerdevil[4974]:       status:       connected
Jul 11 15:43:40 <PC Name> org_kde_powerdevil[4974]:       edid:         None
Jul 11 15:43:40 <PC Name> org_kde_powerdevil[4974]:    Connector:    card0-DP-3
Jul 11 15:43:40 <PC Name> org_kde_powerdevil[4974]:       i2c_busno:    -1
Jul 11 15:43:40 <PC Name> org_kde_powerdevil[4974]:       connector_id: 103
Jul 11 15:43:40 <PC Name> org_kde_powerdevil[4974]:       name:         (null)
Jul 11 15:43:40 <PC Name> org_kde_powerdevil[4974]:       enabled:      disabled
Jul 11 15:43:40 <PC Name> org_kde_powerdevil[4974]:       status:       connected
Jul 11 15:43:40 <PC Name> org_kde_powerdevil[4974]:       edid:         None

At least powerdevil seems to thing that there are THREE connected outputs w/o an edid.

Ideas? How to verify it's the monitors fault?

Test a different monitor?

This is the log from today return from hibernate.

Hibernate (S4) or suspend to ram (S3/s2idle)?
Is there a parallel windows or does the HW config change in any way during the hibernation (you dis- and reconnect the output etc.)
How are the monitors connected? Directly to the GPU or is there a kvm/dock/adapter (cables that translate one protocol to a different one count as adapters) involved?

Tharbad · 2025-07-13 02:48:18

seth wrote:

This is on X11?
Please post your Xorg log, https://wiki.archlinux.org/title/Xorg#General after this happens along "xrandr --verbose" when things are fine and when they're not.
Also
for OUT in /sys/class/drm/card*; do echo $OUT; edid-decode $OUT/edid; echo "================="; done
in both conditions.
You'll need https://archlinux.org/packages/extra/x86_64/v4l-utils/

X11.

Will do next time it happens. For now, that's when everything is fine:

https://pastebin.com/2quU9VaP

for cmd:

/sys/class/drm/card0
/sys/class/drm/card0/edid: No such file or directory
=================
/sys/class/drm/card0-DP-1
EDID of '/sys/class/drm/card0-DP-1/edid' was empty.
=================
/sys/class/drm/card0-DP-2
EDID of '/sys/class/drm/card0-DP-2/edid' was empty.
=================
/sys/class/drm/card0-DP-3
EDID of '/sys/class/drm/card0-DP-3/edid' was empty.
=================
/sys/class/drm/card0-HDMI-A-1
EDID of '/sys/class/drm/card0-HDMI-A-1/edid' was empty.
=================
/sys/class/drm/card0-HDMI-A-2
EDID of '/sys/class/drm/card0-HDMI-A-2/edid' was empty.
=================

seth wrote:

Ideas? How to verify it's the monitors fault?
Test a different monitor?

Will try to locate one.

seth wrote:

This is the log from today return from hibernate.
Hibernate (S4) or suspend to ram (S3/s2idle)?
Is there a parallel windows or does the HW config change in any way during the hibernation (you dis- and reconnect the output etc.)
How are the monitors connected? Directly to the GPU or is there a kvm/dock/adapter (cables that translate one protocol to a different one count as adapters) involved?

Hibernate. But I switched to hibernate from suspend only in the last 6 months. So it happens in both and also after clean reboot.
No MS Windows.
I always turn off the monitors after I hibernate the pc. Tried without - same results.
no KVM or docks. Directly to GPU. DP on Monitors side, DP on GPU side.

seth · 2025-07-13 05:59:25

Note to future self: they're all three the same 'DELL U2412M' model.
Why, are the edid's not exposed to the drm subsystem? nvidia?
Add "nvidia_drm.modeset=1" to the https://wiki.archlinux.org/title/Kernel_parameters - notably if this isn't some 550xx or 565xx or later version where this became the default.

Tharbad · 2025-07-13 06:18:35

seth wrote:

Note to future self: they're all three the same 'DELL U2412M' model.
Why, are the edid's not exposed to the drm subsystem? nvidia?
Add "nvidia_drm.modeset=1" to the https://wiki.archlinux.org/title/Kernel_parameters - notably if this isn't some 550xx or 565xx or later version where this became the default.

550xx. It's there, thinking about removing it as it no longer needed.

Tried running the for with root, same result.

Forgot Xorg log:
https://pastebin.com/YG7rpNpB
If my translation of second to days is correct you'll see there:
- The boot stuff
- Yesterday return from hibernate as described before.
- Me disconnecting and reconnecting 2 monitors to fix problem.

Or maybe it's better to upload the entire log next time?

seth · 2025-07-13 06:55:20

Tried running the for with root, same result.

Don't. That's not the problem. Add the kernel parameter - I'd not be surprised if your problem comes down to that… except that

nvidia-drm.modeset=1

is in the xorg log??
What happens if you drop apparmor ?

Possibly unrelated.

[    41.474] (==) Using config file: "/etc/X11/xorg.conf"

Remove that file. It's complete cruft and will gloss over any server error.
If you care for

[    41.497] (**) NVIDIA(0): Option "MetaModes" "DVI-D-0: 1920x1200_60 +1920+0 {ForceCompositionPipeline=On, ForceFullCompositionPipeline=On}, DP-0: 1920x1200_60 +0+0 {ForceCompositionPipeline=On, ForceFullCompositionPipeline=On}, DP-2: 1920x1200_60 +3840+0 {ForceCompositionPipeline=On, ForceFullCompositionPipeline=On}"

/etc/X11/xorg.conf.d/20-nvidia.conf

   Section "Device"
   Identifier "nvidia"
   Driver "nvidia"
   Option "MetaModes" "DVI-D-0: 1920x1200_60 +1920+0 {ForceCompositionPipeline=On, ForceFullCompositionPipeline=On}, DP-0: 1920x1200_60 +0+0 {ForceCompositionPipeline=On, ForceFullCompositionPipeline=On}, DP-2: 1920x1200_60 +3840+0 {ForceCompositionPipeline=On, ForceFullCompositionPipeline=On}"
EndSection

The driver might be uber-picky and we'll have to move it to the screen section, we'll see (and in that case might just strip down your xorg.conf to the bare necessities)

Tharbad · 2025-07-13 13:37:10

seth wrote:

Tried running the for with root, same result.
Don't. That's not the problem. Add the kernel parameter - I'd not be surprised if your problem comes down to that… except that
nvidia-drm.modeset=1
is in the xorg log??
What happens if you drop apparmor ?
Possibly unrelated.
[    41.474] (==) Using config file: "/etc/X11/xorg.conf"
Remove that file. It's complete cruft and will gloss over any server error.
If you care for
[    41.497] (**) NVIDIA(0): Option "MetaModes" "DVI-D-0: 1920x1200_60 +1920+0 {ForceCompositionPipeline=On, ForceFullCompositionPipeline=On}, DP-0: 1920x1200_60 +0+0 {ForceCompositionPipeline=On, ForceFullCompositionPipeline=On}, DP-2: 1920x1200_60 +3840+0 {ForceCompositionPipeline=On, ForceFullCompositionPipeline=On}"
/etc/X11/xorg.conf.d/20-nvidia.conf
   Section "Device"
   Identifier "nvidia"
   Driver "nvidia"
   Option "MetaModes" "DVI-D-0: 1920x1200_60 +1920+0 {ForceCompositionPipeline=On, ForceFullCompositionPipeline=On}, DP-0: 1920x1200_60 +0+0 {ForceCompositionPipeline=On, ForceFullCompositionPipeline=On}, DP-2: 1920x1200_60 +3840+0 {ForceCompositionPipeline=On, ForceFullCompositionPipeline=On}"
EndSection
The driver might be uber-picky and we'll have to move it to the screen section, we'll see (and in that case might just strip down your xorg.conf to the bare necessities)

modset is now back

xrandr bad log:
https://pastebin.com/ByMLL43y
1 monitor detected as generic

apparmor is off
xorg.config is renamed

will report after reboot

seth · 2025-07-13 13:51:23

DP-0 is still connected but reads

edid-decode (hex):

00 ff ff ff ff ff ff 00 3a c4 00 00 00 00 00 00
00 00 01 04 95 00 00 78 ee 91 a3 54 4c 99 26 0f
50 54 00 20 00 00 01 01 01 01 01 01 01 01 01 01
01 01 01 01 01 01 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 92

----------------

Block 0, Base EDID:
  EDID Structure Version & Revision: 1.4
  Vendor & Product Identification:
    Manufacturer: NVD
    Model: 0
    Made in: 1990
  Basic Display Parameters & Features:
    Digital display
    Bits per primary color channel: 6
    DisplayPort interface
    Image size is variable
    Gamma: 2.20
    DPMS levels: Standby Suspend Off
    Supported color formats: RGB 4:4:4, YCrCb 4:4:4
    Default (sRGB) color space is primary color space
    First detailed timing includes the native pixel format and preferred refresh rate
  Color Characteristics:
    Red  : 0.3300, 0.2978
    Green: 0.5976, 0.1494
    Blue : 0.0605, 0.3144
    White: 0.3281, 0.0029
  Established Timings I & II:
    DMT 0x04:   640x480    59.940476 Hz   4:3     31.469 kHz     25.175000 MHz
  Standard Timings: none
  Detailed Timing Descriptors:
    Empty Descriptor
    Empty Descriptor
    Empty Descriptor
    Empty Descriptor
Checksum: 0x92

If nothing else helps, you'll probably want to inject an EDID, https://wiki.archlinux.org/title/Kernel … s_and_EDID - for only X11 you could also tell the nvidia driver in the 20-nvidia.conf

…
Option "CustomEDID" "DFP-1:/path/to/edid.bin"
…

You can straight up copy the "good" edid from… HOLD ON! there isn't even a /sys/class/drm/card0-DP-0 ??

Tharbad · 2025-07-13 14:02:05

After reboot: same. 1 monitor was off.

seth · 2025-07-13 14:04:46

Are the edid's meanwhile exposed to /sys/class/drm/?

Tharbad · 2025-07-13 14:30:26

seth wrote:

DP-0 is still connected but reads
You can straight up copy the "good" edid from… HOLD ON! there isn't even a /sys/class/drm/card0-DP-0 ??

No. Checked

Tharbad · 2025-07-13 14:40:39

seth wrote:

Are the edid's meanwhile exposed to /sys/class/drm/?

No

Tharbad · 2025-07-13 14:43:24

Xorg log after reboot:
https://pastebin.com/iPgH3h0D

1 Monitor was off.

seth · 2025-07-13 15:04:59

[    41.219] (**) |-->Screen "Screen0" (0)
[    41.219] (**) |   |-->Monitor "Monitor0"
[    41.219] (**) |   |-->Device "Device0"
[    41.219] (**) |-->Input Device "Keyboard0"
[    41.219] (**) |-->Input Device "Mouse0"
[    41.219] (**) Option "Xinerama" "0"
[    41.219] (**) Allowing byte-swapped clients

there's still some static server config somewhere… do not run nvidia-xconfig and the likes.

Here's your relevant edid binary: http://0x0.st/8Dnm.bin
Is this only after hibernation or also after a reboot?
This is "wrong" and might be at the core of the issue.

Tharbad · 2025-07-14 16:31:24

seth wrote:

[    41.219] (**) |-->Screen "Screen0" (0)
[    41.219] (**) |   |-->Monitor "Monitor0"
[    41.219] (**) |   |-->Device "Device0"
[    41.219] (**) |-->Input Device "Keyboard0"
[    41.219] (**) |-->Input Device "Mouse0"
[    41.219] (**) Option "Xinerama" "0"
[    41.219] (**) Allowing byte-swapped clients
there's still some static server config somewhere… do not run nvidia-xconfig and the likes.
Here's your relevant edid binary: http://0x0.st/8Dnm.bin
Is this only after hibernation or also after a reboot?
This is "wrong" and might be at the core of the issue.

Where did you get that edid?
both clean boot and hibernate.
Will remove everything and report.

seth · 2025-07-14 20:10:31

Where did you get that edid?

your xorg log and hex2bin
You might have to just inject that since there's sth. off about the system obtaining the edids, at least after hibernation (though them not exposed to the drm system despite nvidia_drm.modeset=1 is weird and I can't explain that)

Tharbad · 2025-07-15 16:53:39

seth wrote:

Where did you get that edid?
your xorg log and hex2bin
You might have to just inject that since there's sth. off about the system obtaining the edids, at least after hibernation (though them not exposed to the drm system despite nvidia_drm.modeset=1 is weird and I can't explain that)

I've rebooted the system today and also did an hibernation return to test and everything is ok.
Yesterday I removed the last nvidia config file.
So far it seems to be solved (!). Many Thanks!

If it returns, I'll come back till the end of the week, otherwise will mark as solved.
Should I inject edid anyway?

seth · 2025-07-15 20:10:41

Should I inject edid anyway?

Only if the system has continued trouble to pick it up itself, otherwise leave it alone.

Tharbad · 2025-07-20 07:10:45

seth wrote:

Should I inject edid anyway?
Only if the system has continued trouble to pick it up itself, otherwise leave it alone.

Thanks

Arch Linux

#1 2025-07-11 19:59:42

[SOLVED] Monitors sometimes recognized wrong

#2 2025-07-12 08:42:30

Re: [SOLVED] Monitors sometimes recognized wrong

#3 2025-07-13 02:48:18

Re: [SOLVED] Monitors sometimes recognized wrong

#4 2025-07-13 05:59:25

Re: [SOLVED] Monitors sometimes recognized wrong

#5 2025-07-13 06:18:35

Re: [SOLVED] Monitors sometimes recognized wrong

#6 2025-07-13 06:55:20

Re: [SOLVED] Monitors sometimes recognized wrong

#7 2025-07-13 13:37:10

Re: [SOLVED] Monitors sometimes recognized wrong

#8 2025-07-13 13:51:23

Re: [SOLVED] Monitors sometimes recognized wrong

#9 2025-07-13 14:02:05

Re: [SOLVED] Monitors sometimes recognized wrong

#10 2025-07-13 14:04:46

Re: [SOLVED] Monitors sometimes recognized wrong

#11 2025-07-13 14:30:26

Re: [SOLVED] Monitors sometimes recognized wrong

#12 2025-07-13 14:40:39

Re: [SOLVED] Monitors sometimes recognized wrong

#13 2025-07-13 14:43:24

Re: [SOLVED] Monitors sometimes recognized wrong

#14 2025-07-13 15:04:59

Re: [SOLVED] Monitors sometimes recognized wrong

#15 2025-07-14 16:31:24

Re: [SOLVED] Monitors sometimes recognized wrong

#16 2025-07-14 20:10:31

Re: [SOLVED] Monitors sometimes recognized wrong

#17 2025-07-15 16:53:39

Re: [SOLVED] Monitors sometimes recognized wrong

#18 2025-07-15 20:10:41

Re: [SOLVED] Monitors sometimes recognized wrong

#19 2025-07-20 07:10:45

Re: [SOLVED] Monitors sometimes recognized wrong

Board footer