Display Refresh Rate Issue When Connected Through Capture Card

coestar · January 9, 2025, 10:58pm

What exactly is the problem? “It doesn’t work” isn’t going to help us to help you. Give us details about what’s going wrong.

I’m a newly returning Ubuntu user and am transitioning my two PC streaming setup from Windows. It’s going great, but I have been struggling to solve a refresh rate issue. My setup involves a Gaming PC and a Stream PC and the video chain is a bit complex. The video output from the Gaming PC goes to an HDMI switch, which goes to an input on the capture card in the Stream PC, then out from the pass-through on the capture card to my monitor.

The specific issue is that the refresh rate on my Gaming PC is being limited to 4K 30 Hz, whereas my monitor supports 4K 120 Hz, as does the pass-through on my capture card.

What hardware are you using?

Gaming PC: https://pcpartpicker.com/user/Coestar/saved/P4drcf
Stream PC: https://pcpartpicker.com/user/Coestar/saved/gZYmxr
HDMI Switch: https://www.amazon.com/gp/product/B0B6FCPG5Q

The directly related hardware:

Monitor: Gigabyte M28U and supports 4K 144 Hz
Gaming PC GPU: Nvidia RTX 4080 Super
Stream PC Capture Card: AverMedia Live Gamer 4K 2.1 (GC575)

What have you already tried? What happened as a result?

I’ve tried changing the video chain around to see what happens:

Gaming PC → Monitor - Works perfectly, 4K 144 Hz
Gaming PC → HDMI Switch → Monitor - No signal
Gaming PC → Capture Card → Monitor - Works, but limited to 4K 29.97 Hz
Gaming PC → HDMI Switch → Capture Card → Monitor - Works, but limited to 4K 29.97 Hz (This is the setup that I was using successfully in Windows to capture 4K 60 Hz and pass-through 4K 120 Hz)

This seemed to eliminate the HDMI Switch as the issue, despite failing to get a signal. All of the above are HDMI connections, no DisplayPort.

I attempted to force the mode and rate using xrandr, e.g. $ xrandr --output HDMI-2 --mode 3840x2160 --rate 120.000, but this had no effect.

I also attempted to force the mode by editing ~/config/monitors.xml to change the rate fields associated with the GC575 to 120.000. This also did not work, though it did seem to have an effect one time where I was able to get 60 Hz instead of 29.97 Hz. After another reboot, however, it returned to 29.97 Hz and stayed that way.

Those are the main things I tried, nothing else of note. Spent a lot of time searching but can’t seem to find anything near to this specific issue involving a capture card.

Gaming PC Command Outputs

$ lsb_release -a
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 24.10
Release:	24.10
Codename:	oracular

$ uname -a
Linux rex 6.11.0-13-generic #14-Ubuntu SMP PREEMPT_DYNAMIC Sat Nov 30 23:51:51 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux

$ nvidia-smi
Thu Jan  9 19:28:42 2025       
+-----------------------------------------------------------------------------------------+
| NVIDIA-SMI 560.35.03              Driver Version: 560.35.03      CUDA Version: 12.6     |
|-----------------------------------------+------------------------+----------------------+
| GPU  Name                 Persistence-M | Bus-Id          Disp.A | Volatile Uncorr. ECC |
| Fan  Temp   Perf          Pwr:Usage/Cap |           Memory-Usage | GPU-Util  Compute M. |
|                                         |                        |               MIG M. |
|=========================================+========================+======================|
|   0  NVIDIA GeForce RTX 4080 ...    Off |   00000000:08:00.0  On |                  N/A |
|  0%   30C    P8             11W /  320W |     943MiB /  16376MiB |      0%      Default |
|                                         |                        |                  N/A |
+-----------------------------------------+------------------------+----------------------+
                                                                                         
+-----------------------------------------------------------------------------------------+
| Processes:                                                                              |
|  GPU   GI   CI        PID   Type   Process name                              GPU Memory |
|        ID   ID                                                               Usage      |
|=========================================================================================|
|    0   N/A  N/A      3125      G   /usr/bin/gnome-shell                          299MiB |
|    0   N/A  N/A      3583      G   /usr/bin/Xwayland                             513MiB |
|    0   N/A  N/A      3717      G   /usr/libexec/xdg-desktop-portal-gnome          10MiB |
|    0   N/A  N/A      8822      G   ...local/share/Steam/ubuntu12_32/steam          4MiB |
|    0   N/A  N/A      9021      G   ./steamwebhelper                               48MiB |
|    0   N/A  N/A      9050    C+G   ....local/share/Steam/logs/cef_log.txt          9MiB |
+-----------------------------------------------------------------------------------------+

$ sudo lshw -C display
  *-display                 
       description: VGA compatible controller
       product: AD103 [GeForce RTX 4080 SUPER]
       vendor: NVIDIA Corporation
       physical id: 0
       bus info: pci@0000:08:00.0
       logical name: /dev/fb0
       version: a1
       width: 64 bits
       clock: 33MHz
       capabilities: pm msi pciexpress vga_controller bus_master cap_list rom fb
       configuration: depth=32 driver=nvidia latency=0 mode=1024x768 resolution=1024,768 visual=truecolor xres=1024 yres=768
       resources: iomemory:780-77f iomemory:7c0-7bf irq:111 memory:fb000000-fbffffff memory:7800000000-7bffffffff memory:7c00000000-7c01ffffff ioport:e000(size=128) memory:fc000000-fc07ffff

$ xrandr
Screen 0: minimum 16 x 16, current 3840 x 2160, maximum 32767 x 32767
HDMI-2 connected primary 3840x2160+0+0 (normal left inverted right x axis y axis) 630mm x 360mm
   3840x2160     29.96*+
   2048x1536     29.95  
   1920x1440     29.88  
   1600x1200     29.85  
   1440x1080     29.86  
   1400x1050     29.84  
   1280x1024     29.90  
   1280x960      29.82  
   1152x864      29.92  
   1024x768      29.89  
   800x600       29.55  
   640x480       29.85  
   320x240       27.50  
   2560x1600     29.94  
   1920x1200     29.87  
   1680x1050     29.95  
   1440x900      29.91  
   1280x800      29.83  
   1152x720      29.72  
   960x600       29.86  
   928x580       29.64  
   800x500       29.53  
   768x480       29.64  
   720x480       29.25  
   640x400       29.58  
   320x200       26.53  
   3200x1800     29.93  
   2880x1620     29.92  
   2560x1440     29.94  
   2048x1152     29.94  
   1920x1080     29.86  
   1600x900      29.92  
   1368x768      29.94  
   1280x720      29.72  
   1024x576      29.84  
   864x486       29.50  
   720x400       29.51  
   640x350       29.03

$ cat .config/monitors.xml
<monitors version="2">
  <configuration>
    <layoutmode>logical</layoutmode>
    <logicalmonitor>
      <x>0</x>
      <y>0</y>
      <scale>1</scale>
      <primary>yes</primary>
      <monitor>
        <monitorspec>
          <connector>HDMI-2</connector>
          <vendor>GBT</vendor>
          <product>M28U</product>
          <serial>23060B001096</serial>
        </monitorspec>
        <mode>
          <width>3840</width>
          <height>2160</height>
          <rate>144.000</rate>
        </mode>
      </monitor>
    </logicalmonitor>
  </configuration>
  <configuration>
    <layoutmode>logical</layoutmode>
    <logicalmonitor>
      <x>0</x>
      <y>0</y>
      <scale>1.25</scale>
      <primary>yes</primary>
      <monitor>
        <monitorspec>
          <connector>HDMI-2</connector>
          <vendor>AVX</vendor>
          <product>AVT GC575</product>
          <serial>0x00000000</serial>
        </monitorspec>
        <mode>
          <width>3840</width>
          <height>2160</height>
          <rate>120.000</rate>
        </mode>
      </monitor>
    </logicalmonitor>
  </configuration>
  <configuration>
    <layoutmode>physical</layoutmode>
    <logicalmonitor>
      <x>0</x>
      <y>0</y>
      <scale>1</scale>
      <primary>yes</primary>
      <monitor>
        <monitorspec>
          <connector>HDMI-2</connector>
          <vendor>GBT</vendor>
          <product>M28U</product>
          <serial>23060B001096</serial>
        </monitorspec>
        <mode>
          <width>3840</width>
          <height>2160</height>
          <rate>144.000</rate>
        </mode>
      </monitor>
    </logicalmonitor>
  </configuration>
  <configuration>
    <layoutmode>logical</layoutmode>
    <logicalmonitor>
      <x>0</x>
      <y>0</y>
      <scale>1.25</scale>
      <primary>yes</primary>
      <monitor>
        <monitorspec>
          <connector>HDMI-1</connector>
          <vendor>AVX</vendor>
          <product>AVT GC575</product>
          <serial>0x00000000</serial>
        </monitorspec>
        <mode>
          <width>3840</width>
          <height>2160</height>
          <rate>120.000</rate>
        </mode>
      </monitor>
    </logicalmonitor>
  </configuration>
  <configuration>
    <layoutmode>physical</layoutmode>
    <logicalmonitor>
      <x>0</x>
      <y>0</y>
      <scale>1</scale>
      <primary>yes</primary>
      <monitor>
        <monitorspec>
          <connector>HDMI-2</connector>
          <vendor>AVX</vendor>
          <product>AVT GC575</product>
          <serial>0x00000000</serial>
        </monitorspec>
        <mode>
          <width>3840</width>
          <height>2160</height>
          <rate>120.000</rate>
        </mode>
      </monitor>
    </logicalmonitor>
  </configuration>
</monitors>

modrobert · January 10, 2025, 6:39am

Is that through HDMI (or DisplayPort)?

coestar · January 10, 2025, 7:08am

That’s over HDMI, yea.

modrobert · January 10, 2025, 7:34am

There are different protocol versions of HDMI, perhaps some of the hardware isn’t up to spec?

https://en.wikipedia.org/wiki/HDMI#Versions

EDIT:
Noticed now your capture card is 2.1 (assuming HDMI 2.1), found this in the wiki;

“It adds support for higher resolutions and higher refresh rates, including 4K 120 Hz and 8K 60 Hz.”

I think 144Hz @ 4K is pushing it, did you try lowering the settings from source?

EDIT2:
Another test might be to try different HDMI cables (Ultra High Speed HDMI Cable), the shorter the better. I was looking at the FRL transmission mode of the HDMI 2.1 protocol, looks like it can auto negotiate data rate downwards if there are too many errors during transmission, so that might be the case.

coestar · January 10, 2025, 3:28pm

All good points, but I’ve accounted for all that already (I think):

My target is actually 4k 120 Hz, as that’s the max spec for the GC575’s pass-through.
The HDMI switch is 8k HDMI 2.1.
All HDMI cables involved are 8k HDMI 2.1 rated and are 3ft in length apart from the final run to the monitor, which is 6ft.
This hardware & cabling worked reliably in my Windows setup for viewing 4k 120 Hz and capturing 4k 60 Hz.

Not sure I follow - the source in this case would be the Gaming PC, which doesn’t give me the option to set anything higher than 4K 29.97 Hz at the moment.

modrobert · January 10, 2025, 3:50pm

You mentioned…

I was assuming you could still select lower refresh rate than 144 Hz, like 60Hz, but realize now that was probably not the case with capture card connected.

Since it works when connected directly to monitor, perhaps there is some way to add a display mode with ‘xrandr --addmode’, then select said mode, like a 60 Hz option. I’m not an expert when it comes to configuring this but recently read another thread in this forum, which linked this:

https://forums.linuxmint.com/viewtopic.php?t=274540

So the idea is that you look what modes you get with when it works when directly hooked up to monitor (without capture card), then use that info as base for adding a new mode, and then select that mode. Perhaps it’s best to try and add 60 Hz mode when using the capture card, since that was the max when you ran windows.

coestar · January 10, 2025, 3:57pm

Just to be clear (and to be fair my setup is confusing): 120 Hz is the max for the pass-through. On Windows I was able to view at 120 Hz on the Gaming PC and capture at 60 Hz on the Stream PC.

Thanks, that’s a good idea - I’ll give it a shot and report back.

modrobert · January 10, 2025, 4:01pm

Aha, OK, so 60 Hz only relevant in the software used to capture then?

coestar · January 10, 2025, 4:04pm

Yea, exactly. The GC575 takes in 4k 120 Hz and passes it through the pass-through output as-is. The software on the Stream PC is able to then capture that signal at 4k 60 Hz max, but that doesn’t affect the pass-through.

modrobert · January 10, 2025, 4:10pm

If I understood everything correctly this time, it’s probably best to go for 144 Hz then as your new mode with capture card connected.

coestar · January 10, 2025, 7:34pm

I’ve tested a little further w/ xrandr, to no avail.

Generated my desired modeline using cvt:

$ cvt 3840 2160 120
# 3840x2160 119.98 Hz (CVT) hsync: 277.87 kHz; pclk: 1498.25 MHz
Modeline "3840x2160_120.00"  1498.25  3840 4192 4616 5392  2160 2163 2168 2316 -hsync +vsync

Then translated that into these xrandr commands:

$ xrandr --newmode "3840x2160_120.00"  1498.25  3840 4192 4616 5392  2160 2163 2168 2316 -hsync +vsync
$ xrandr --addmode HDMI-2 "3840x2160_120.00"

Which does add the modes (down at the bottom):

$ xrandr
Screen 0: minimum 16 x 16, current 3840 x 2160, maximum 32767 x 32767
HDMI-2 connected primary 3840x2160+0+0 (normal left inverted right x axis y axis) 630mm x 360mm
   3840x2160     29.96*+
   2048x1536     29.95  
   1920x1440     29.88  
   1600x1200     29.85  
   1440x1080     29.86  
   1400x1050     29.84  
   1280x1024     29.90  
   1280x960      29.82  
   1152x864      29.92  
   1024x768      29.89  
   800x600       29.55  
   640x480       29.85  
   320x240       27.50  
   2560x1600     29.94  
   1920x1200     29.87  
   1680x1050     29.95  
   1440x900      29.91  
   1280x800      29.83  
   1152x720      29.72  
   960x600       29.86  
   928x580       29.64  
   800x500       29.53  
   768x480       29.64  
   720x480       29.25  
   640x400       29.58  
   320x200       26.53  
   3200x1800     29.93  
   2880x1620     29.92  
   2560x1440     29.94  
   2048x1152     29.94  
   1920x1080     29.86  
   1600x900      29.92  
   1368x768      29.94  
   1280x720      29.72  
   1024x576      29.84  
   864x486       29.50  
   720x400       29.51  
   640x350       29.03  
   3840x2160_60.00  59.98  
   3840x2160_120.00 119.98

But setting the mode like so does nothing at all:

$ xrandr --output HDMI-2 --mode "3840x2160_120.00"

Display settings haven’t changed:

This led me to learning a bit about Wayland, which seems to be the default on 24.10, and it appears that my efforts with xrandr are wasted - it has nothing to do with Wayland, only Xorg.

coestar · January 11, 2025, 12:36am

Through further digging and learning about Wayland, I think I don’t want to fall back to Xorg. Seems like Wayland is the future, but maybe a tad more difficult to solve issues for those of us who experience edge cases like I am.

At this time, I suspect that one of these three things is happening:

AverMedia’s GC575 reports an invalid EDID
Wayland is misinterpreting the EDID from the GC575
There’s something in the EDID that explains what I need to do to achieve 4K 120 Hz pass-through (I’m starting to suspect color modes)

I’m new to examining EDIDs, so I don’t know whether the GC575’s is invalid. Here’s what I get:

$ sudo get-edid | edid-decode
This is read-edid version 3.0.2. Prepare for some fun.
Attempting to use i2c interface
No EDID on bus 0
No EDID on bus 1
No EDID on bus 2
No EDID on bus 3
No EDID on bus 4
No EDID on bus 5
No EDID on bus 6
No EDID on bus 8
1 potential busses found: 7
256-byte EDID successfully retrieved from i2c bus 7
Looks like i2c was successful. Have a good day.
edid-decode (hex):

00 ff ff ff ff ff ff 00 06 d8 57 00 00 00 00 00
1e 21 01 03 80 3f 24 78 ee a8 15 ad 50 45 a2 26
0e 50 54 20 00 00 d1 c0 01 01 01 01 01 01 01 01
01 01 01 01 01 01 08 e8 00 30 f2 70 5a 80 b0 58
8a 00 b9 88 21 00 00 1e 00 00 00 10 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 fc 00 41
56 54 20 47 43 35 37 35 0a 20 20 20 00 00 00 fd
00 30 90 1e 87 3c 00 0a 20 20 20 20 20 20 01 8a

02 03 41 f1 48 76 61 5f 3f 20 10 04 03 23 09 07
07 83 01 00 00 6b 03 0c 00 10 00 38 44 20 00 20
01 6a d8 5d c4 01 78 80 33 02 30 90 e2 00 d5 e3
05 c0 00 e6 06 05 01 66 66 1f e3 0e 61 76 e2 0f
03 56 c2 00 a0 a0 a0 55 50 30 20 35 00 b9 88 21
00 00 1e 56 5e 00 a0 a0 a0 29 50 30 20 35 00 b9
88 21 00 00 1e 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 d3

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

Block 0, Base EDID:
  EDID Structure Version & Revision: 1.3
  Vendor & Product Identification:
    Manufacturer: AVX
    Model: 87
    Made in: week 30 of 2023
  Basic Display Parameters & Features:
    Digital display
    Maximum image size: 63 cm x 36 cm
    Gamma: 2.20
    DPMS levels: Standby Suspend Off
    RGB color display
    Default (sRGB) color space is primary color space
    First detailed timing is the preferred timing
  Color Characteristics:
    Red  : 0.6777, 0.3144
    Green: 0.2714, 0.6328
    Blue : 0.1484, 0.0556
    White: 0.3134, 0.3291
  Established Timings I & II:
    DMT 0x04:   640x480    59.940476 Hz   4:3     31.469 kHz     25.175000 MHz
  Standard Timings:
    DMT 0x52:  1920x1080   60.000000 Hz  16:9     67.500 kHz    148.500000 MHz
  Detailed Timing Descriptors:
    DTD 1:  3840x2160   60.000000 Hz  16:9    135.000 kHz    594.000000 MHz (697 mm x 392 mm)
                 Hfront  176 Hsync  88 Hback  296 Hpol P
                 Vfront    8 Vsync  10 Vback   72 Vpol P
    Dummy Descriptor:
    Display Product Name: 'AVT GC575'
    Display Range Limits:
      Monitor ranges (GTF): 48-144 Hz V, 30-135 kHz H, max dotclock 600 MHz
  Extension blocks: 1
Checksum: 0x8a

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

Block 1, CTA-861 Extension Block:
  Revision: 3
  Underscans IT Video Formats by default
  Basic audio support
  Supports YCbCr 4:4:4
  Supports YCbCr 4:2:2
  Native detailed modes: 1
  Video Data Block:
    VIC 118:  3840x2160  120.000000 Hz  16:9    270.000 kHz   1188.000000 MHz
    VIC  97:  3840x2160   60.000000 Hz  16:9    135.000 kHz    594.000000 MHz
    VIC  95:  3840x2160   30.000000 Hz  16:9     67.500 kHz    297.000000 MHz
    VIC  63:  1920x1080  120.000000 Hz  16:9    135.000 kHz    297.000000 MHz
    VIC  32:  1920x1080   24.000000 Hz  16:9     27.000 kHz     74.250000 MHz
    VIC  16:  1920x1080   60.000000 Hz  16:9     67.500 kHz    148.500000 MHz
    VIC   4:  1280x720    60.000000 Hz  16:9     45.000 kHz     74.250000 MHz
    VIC   3:   720x480    59.940060 Hz  16:9     31.469 kHz     27.000000 MHz
  Audio Data Block:
    Linear PCM:
      Max channels: 2
      Supported sample rates (kHz): 48 44.1 32
      Supported sample sizes (bits): 24 20 16
  Speaker Allocation Data Block:
    FL/FR - Front Left/Right
  Vendor-Specific Data Block (HDMI), OUI 00-0C-03:
    Source physical address: 1.0.0.0
    DC_36bit
    DC_30bit
    DC_Y444
    Maximum TMDS clock: 340 MHz
    Extended HDMI video details:
      HDMI VICs:
        HDMI VIC 1:  3840x2160   30.000000 Hz  16:9     67.500 kHz    297.000000 MHz
  Vendor-Specific Data Block (HDMI Forum), OUI C4-5D-D8:
    Version: 1
    Maximum TMDS Character Rate: 600 MHz
    SCDC Present
    Max Fixed Rate Link: 3 and 6 Gbps per lane on 3 lanes, 6 Gbps on 4 lanes
    Supports 12-bits/component Deep Color 4:2:0 Pixel Encoding
    Supports 10-bits/component Deep Color 4:2:0 Pixel Encoding
    Supports Auto Low-Latency Mode
    VRRmin: 48 Hz
    VRRmax: 144 Hz
  Video Capability Data Block:
    YCbCr quantization: Selectable (via AVI YQ)
    RGB quantization: Selectable (via AVI Q)
    PT scan behavior: Always Overscanned
    IT scan behavior: Always Overscanned
    CE scan behavior: Always Overscanned
  Colorimetry Data Block:
    BT2020YCC
    BT2020RGB
  HDR Static Metadata Data Block:
    Electro optical transfer functions:
      Traditional gamma - SDR luminance range
      SMPTE ST2084
    Supported static metadata descriptors:
      Static metadata type 1
    Desired content max luminance: 102 (455.515 cd/m^2)
    Desired content max frame-average luminance: 102 (455.515 cd/m^2)
    Desired content min luminance: 31 (0.067 cd/m^2)
  YCbCr 4:2:0 Video Data Block:
    VIC  97:  3840x2160   60.000000 Hz  16:9    135.000 kHz    594.000000 MHz
    VIC 118:  3840x2160  120.000000 Hz  16:9    270.000 kHz   1188.000000 MHz
  YCbCr 4:2:0 Capability Map Data Block:
    VIC 118:  3840x2160  120.000000 Hz  16:9    270.000 kHz   1188.000000 MHz
    VIC  97:  3840x2160   60.000000 Hz  16:9    135.000 kHz    594.000000 MHz
  Detailed Timing Descriptors:
    DTD 2:  2560x1440  119.937319 Hz  16:9    182.904 kHz    497.500000 MHz (697 mm x 392 mm)
                 Hfront   48 Hsync  32 Hback   80 Hpol P
                 Vfront    3 Vsync   5 Vback   77 Vpol P
    DTD 3:  2560x1440   59.950550 Hz  16:9     88.787 kHz    241.500000 MHz (697 mm x 392 mm)
                 Hfront   48 Hsync  32 Hback   80 Hpol P
                 Vfront    3 Vsync   5 Vback   33 Vpol P
Checksum: 0xd3

Of note, there are various mentions of 3840x2160 120.000000 Hz in the EDID, or even 3840x2160 60.000000 Hz, despite Wayland not giving me those options.

modrobert · January 11, 2025, 3:29am

Ah, yes, totally forgot about Wayland, logging in using Xorg myself (usually gives better FPS in the games). During login via Gnome you can select Xorg or Wayland (small cog on the bottom right corner at the login screen), if this option is not available in settings during login you can change config easily back and forth (but that requires restart) as follows:

https://askubuntu.com/questions/1410256/how-do-i-use-the-x-window-manager-instead-of-wayland-on-ubuntu-22-04/1413490#1413490

I’m new to EDID as well, at least regarding how to interpret the data dumped, hopefully someone else here in the forum can chime in and help, but at least you have an option to login via X temporarily to test if ‘xrandr’ works. Also, I recommend you test with 144 Hz as new mode setting since that worked for you in the past without the capture card and switch.

EDIT:

Found this in your EDID output:

     HDMI VICs:
        HDMI VIC 1:  3840x2160   30.000000 Hz  16:9     67.500 kHz    297.000000 MHz

Apparently HDMI VIC is sent from the source, which is interesting, because 30 Hz is the refresh rate you get in Wayland.

CE Video timings are identified by a VIC number (Video Identification Code). This number is part of the AVI InfoFrame transmitted by the source.

In the EDID output there is also VIC 118 (120 Hz) which seems to be what you want, maybe there is some way to force a certain VIC number. Still, I think it’s best you test with Xorg first to see if it works before we dig deeper.

EDIT2:

After reading some more, since you have a working setup (without capture card and switch connected) at 144 Hz, we can dump that working EDID (when you are at 144 Hz) with:

sudo get-edid > my_edid.bin

Copy the file in place with:

sudo install -Dm644 ./my_edid.bin /usr/lib/firmware/edid/my_edid.bin

Then force the Linux kernel to use that EDID no matter what your setup is (e.g. with switch and capture card), effectively ignoring any EDID responses, by adding a kernel parameter:

sudo nano /etc/default/grub

Look for “GRUB_CMDLINE_LINUX_DEFAULT” and add this between the double quotes:

drm.edid_firmware=edid/my_edid.bin

Save and exit, then update grub:

sudo update-grub

Still, before doing any of this, please try ‘xrandr’ when logged in with Xorg first, so we know if that works, less intrusive and perhaps more likely to work. Also, keep in mind that if you change monitor you will need to remove that kernel parameter.

coestar · January 11, 2025, 5:24pm

Managed to get it working on Xorg, huzzah! Thanks to a thread I was digging through where the user had found this:

$ nvidia-xconfig --force-yuv-420

Which adds Option "ForceYUV420" "True" to Section "Screen" in /etc/X11/xorg.conf (and generates an xorg.conf if there is none):

Section "Screen"
    Identifier     "Screen0"
    Device         "Device0"
    Monitor        "Monitor0"
    DefaultDepth    24
    Option         "ForceYUV420" "True"
    SubSection     "Display"
        Depth       24
    EndSubSection
EndSection

Restarted the display manager (sudo systemctl restart display-manager), lo and behold, 120 Hz was available to select at 4K.

So my suspicion about color modes is confirmed; The GC575 capture card does support 4K@120Hz on pass-through, but only at YUV4:2:0 per the EDID:

 YCbCr 4:2:0 Video Data Block:
    VIC  97:  3840x2160   60.000000 Hz  16:9    135.000 kHz    594.000000 MHz
    VIC 118:  3840x2160  120.000000 Hz  16:9    270.000 kHz   1188.000000 MHz
  YCbCr 4:2:0 Capability Map Data Block:
    VIC 118:  3840x2160  120.000000 Hz  16:9    270.000 kHz   1188.000000 MHz
    VIC  97:  3840x2160   60.000000 Hz  16:9    135.000 kHz    594.000000 MHz

coestar · January 12, 2025, 6:47pm

Unfortunately, while I was able to get things working in Xorg, this led to a lot of issues that seem to be symptoms of the Xorg → Wayland transition. Random application crashes, some applications failing to display with “Failed to obtain GL context” (or something like that), etc. Thus, I feel compelled to continue trying to fix this problem under Wayland.

The only update of significance since my last update is that I have installed the 565 Nvidia driver via the Graphics Drivers team’s PPA:

$ nvidia-smi                 
Sun Jan 12 13:39:36 2025       
+-----------------------------------------------------------------------------------------+
| NVIDIA-SMI 565.77                 Driver Version: 565.77         CUDA Version: 12.7     |
|-----------------------------------------+------------------------+----------------------+
| GPU  Name                 Persistence-M | Bus-Id          Disp.A | Volatile Uncorr. ECC |
| Fan  Temp   Perf          Pwr:Usage/Cap |           Memory-Usage | GPU-Util  Compute M. |
|                                         |                        |               MIG M. |
|=========================================+========================+======================|
|   0  NVIDIA GeForce RTX 4080 ...    Off |   00000000:08:00.0  On |                  N/A |
|  0%   28C    P8             10W /  320W |     538MiB /  16376MiB |      0%      Default |
|                                         |                        |                  N/A |
+-----------------------------------------+------------------------+----------------------+
                                                                                         
+-----------------------------------------------------------------------------------------+
| Processes:                                                                              |
|  GPU   GI   CI        PID   Type   Process name                              GPU Memory |
|        ID   ID                                                               Usage      |
|=========================================================================================|
|    0   N/A  N/A      3206      G   /usr/bin/gnome-shell                          308MiB |
|    0   N/A  N/A      3417      G   /usr/bin/Xwayland                               4MiB |
|    0   N/A  N/A      3794      G   /usr/libexec/xdg-desktop-portal-gnome          10MiB |
|    0   N/A  N/A      4097      G   /usr/bin/gnome-control-center                  43MiB |
|    0   N/A  N/A      4674      G   ...yOnDemand --variations-seed-version         71MiB |
+-----------------------------------------------------------------------------------------+

Unfortunately, it had no impact on the issues I’ve been experiencing under Xorg, nor the Wayland issue.

Thanks for this info! I have started trying this out. So far, I’ve tried the following:

Made a dump of my monitor’s EDID (gigabyte_m28u.bin)
Copied it to /usr/lib/firmware/edid/
Edited /etc/default/grub to add the command like so: GRUB_CMDLINE_LINUX_DEFAULT="quiet splash drm.edid_firmware=HDMI-2:edid/gigabyte_m28u.bin"
Updated the Grub config using sudo update-grub
Rebooted
Confirmed via e on Ubuntu in Grub that the command was present and correct
Proceeded w/ login

Unfortunately, it doesn’t seem to have worked. I did a dump of the current EDID after logging in and it was still the GC575’s. As there’s no errors/logs/feedback to see that I’m aware of, I’m not sure how to determine what went wrong.

Edit: Also, I did the above procedure twice - first time was without specifying a port, e.g. GRUB_CMDLINE_LINUX_DEFAULT="quiet splash drm.edid_firmware=edid/gigabyte_m28u.bin"

Edit 2: I’m realizing now that I spaced on your guidance here:

…and literally copied the file there w/ cp. Amending that mistake and trying again…

Edit 3: No change after fixing that step.

coestar · January 12, 2025, 10:34pm

Worked on this further and got some additional help elsewhere, but ultimately it’s starting to look like I’m in no man’s land between Xorg and Wayland.

We did determine that beyond the above steps, it was also necessary to involve a custom script and rebuild initramfs for the override to work on Ubuntu 24.10. Here is the total process for installing and overriding the EDID:

Edit /etc/default/grub:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash drm.edid_firmware=edid/my_edid.bin"

Update Grub:

$ sudo update-grub

Install desired EDID:

$ sudo install -vDm644 desired_edid.bin /usr/lib/firmware/edid/my_edid.bin

Install the custom script mentioned above in /etc/initramfs-tools/hooks/edid.sh and make it executable w/ chmod +x, then rebuild initramfs:

$ sudo update-initramfs -u

Then reboot. Check dmesg for any errors:

$ sudo dmesg | grep edid

Unfortunately, while we confirmed that the EDID was overriding, something else seems to be preventing this approach from working. Since this is under Wayland, it seems like Nvidia or Mutter would be the likely culprits. We were able to force other resolutions and refresh rates, but we were not able to successfully force a YUV 4:2:0 color mode. There doesn’t appear to be any other way of doing so at this time.

modrobert · January 13, 2025, 5:33am

I think your are in no man’s land primarily because you installed the proprietary 565 Nvidia driver (assuming you had the Ubuntu default opensource driver previously), there shouldn’t be anything but minor differences when switching between Wayland and Xorg (at least that’s my experience of it), definitely not the type of crashes you describe. I suspect this is about the 565 driver in combination with Xorg, perhaps this driver is intended to be used with Wayland?

Regarding my instructions for permanent EDID, the idea was to use the situation when you don’t have the capture card or switch connected, when you have it working perfectly at 144 Hz as mentioned in your first post, not about forcing the YUV 4:2:0 color mode (which assumes the capture card is connected).

What I wanted to happen was for the system to stop negotiating EDID, and be forced to use the one provided by the kernel command line. The script you linked regarding initramfs shouldn’t be necessary (is it something new with the latest kernels?). I only used ‘install’ to make sure the directory was created as needed and file got correct permission when copied (to save a few lines of instructions).

I have verified, and at least on my system with Ubuntu 24.04.1 LTS when creating the EDID dump file with sudo get-edid > my_edid.bin it is exactly the same (byte for byte) as the pci system one after boot. In my case (this will not be the same for you):

/sys/devices/pci0000:00/0000:00:08.1/0000:0b:00.0/drm/card1/card1-HDMI-A-1/edid

The pci file is not really relevant (so no need to start experimenting with that), the reason I wanted you to use ‘get-edid’ for dumping was to make sure you get the current working mode without capture card and switch (Gaming PC → Monitor - Works perfectly, 4K 144 Hz), and not copying the wrong edid file from somewhere else.

I think loading the edid by kernel is a long shot mostly because it might fail to communicate over HDMI later when you have everything connected, as in it actually has a legit reason to downgrade to 30Hz to begin with.

Anyway, what happened when you tried my exact instructions regarding kernel edid without the initramfs script? Did you get some error?

coestar · January 13, 2025, 6:15am

Other way around; I was getting crashes and errors in Xorg before updating to 565. Updating the driver didn’t fix them, it turned out. As it didn’t really fix anything, I’m fine to revert back to 560 and test further.

The default driver Ubuntu 24.10 provided during installation was 560-open, I upgraded to 565-open.

Nothing at all. No errors or warnings in dmesg. When I checked the resulting EDID after logging in, it was not the one from /usr/lib/firmware/edid/my_edid.bin. Went through it a few times double-checking that I hadn’t missed anything, per this post.

That was when someone else suggested including that script and rebuilding initramfs. After that, I was able to confirm that the overriding EDID was being used.

There was no issue with the dumping, that was working fine. I did a dump of the EDID from my monitor while directly connected and was able to verify that it was exactly the same as the normally loaded EDID for the monitor. However, when attempting to use it to override while still connected to the monitor, the nvidia driver rejected my_edid.bin as “invalid EDID”:

$ sudo dmesg | grep edid                                                      
[    0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-6.11.0-13-generic root=UUID=712958ff-8d9f-4977-a8ad-e60b5d8800e3 ro quiet splash drm.edid_firmware=edid/my_edid.bin crashkernel=2G-4G:320M,4G-32G:512M,32G-64G:1024M,64G-128G:2048M,128G-:4096M vt.handoff=7
[    0.041118] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-6.11.0-13-generic root=UUID=712958ff-8d9f-4977-a8ad-e60b5d8800e3 ro quiet splash drm.edid_firmware=edid/my_edid.bin crashkernel=2G-4G:320M,4G-32G:512M,32G-64G:1024M,64G-128G:2048M,128G-:4096M vt.handoff=7
[    7.304659] nvidia 0000:08:00.0: [drm] *ERROR* Invalid firmware EDID "edid/my_edid.bin"
[    7.304987] nvidia 0000:08:00.0: [drm] *ERROR* Invalid firmware EDID "edid/my_edid.bin"
[    7.305141] nvidia 0000:08:00.0: [drm] *ERROR* Invalid firmware EDID "edid/my_edid.bin"
[    7.305506] nvidia 0000:08:00.0: [drm] *ERROR* Invalid firmware EDID "edid/my_edid.bin"
[    7.352973] nvidia 0000:08:00.0: [drm] *ERROR* Invalid firmware EDID "edid/my_edid.bin"
[    7.353152] nvidia 0000:08:00.0: [drm] *ERROR* Invalid firmware EDID "edid/my_edid.bin"
(...snipped, repeats for many more lines...)

After which it loaded the standard EDID from the monitor. I double-checked and there was no difference between the loaded EDID and my_edid.bin. There’s two things I need to verify and report back, as I don’t recall if I tried them:

Revert to nvidia 560-open and see if that alleviates the “invalid EDID” error
Load this EDID while the capture card is in the chain and see how it behaves

Understood. I just carried on from there with the objective of trying to force YUV 4:2:0 as it seems to be the answer to my problem, ultimately, based on the capture card’s EDID and the fact that it was what worked in Xorg.

modrobert · January 13, 2025, 6:49am

Aha, OK, that explains it. I currently use the Ubuntu default open source driver for AMD “renoir” (haven’t used an nvidia card for about a decade or two, so no idea how that works).

Thanks for explaining. I haven’t done the specific EDID by kernel myself, and can’t really test since I don’t have a capture card or switch.

OK, I wonder if the kernel verifies EDID checksum or something, not sure what “Invalid” actually means in this “DRM” context.

EDIT:

Found this: https://askubuntu.com/questions/1011098/how-to-eliminate-edid-checksum-errors

Apparently there is a ‘noedid’ kernel parameter, maybe it can be used if you manually configure everything in xorg.conf with nvidia, not sure.

Other than that, I feel out of ideas to help you, sorry. I really appreciate the way you report things even when it works (which helps me and others to understand better, and learn something), keep doing that and we will probably nail this problem with some persistence.

BTW: Regarding Mutter, I still have to patch it by modifying and compiling source code every update to make my keyboard work without slowing down with lag under Xorg (when mashing the keyboard fast), there is a bug report, but not being fixed as the suggested fix breaks certain region/locale apparently. “Welcome to Linux, here’s the source code.”

coestar · January 13, 2025, 4:21pm

Thanks for all the help! Will do, happy to report back and hate to leave an unresolved thread. If anyone else runs into this issue, hopefully this will give them something to work with.

Thanks, I’ll dig into this and see if that helps. When I have time, I’m going to try to meticulously go through different combinations of tests and log the results.

Classic haha. Yea, the thing I most want to know at the moment (apart from a workaround) is what part of Wayland/Nvidia/Mutter space is responsible for my exact issue. It’s not clear at the moment which tree I should be barking up (or investigating patching, if it comes to it), so I’ll just have to keep digging around.