Display configuration not using EDID from Intel Arc

Wondering if anyone can point me in the right direction on this one?

I have a setup with 5 monitors…
3x 2560 x 1440 Display Port (all the same)
2x 3840 x 1100 HDMI (both the same)

I am currently running…
KDE Neon (fully up to date)
Kernel 6.5.0-26
Plasma 6.0.02
Wayland

I had been running them under X11 for years without issue but upon upgrading to Plasma 6 Wayland I had consistent random issues with both the Nouveau and proprietary driver.

Being aware nvidia was likely to be the culprit here (especially as I was mixing with the onboard Intel to run the 5 screens) I took the punt and got an Intel Arc 580.

So this is my current setup…

Intel Arc 580:
3x 2560 x 1440 Display Port
1x 3840 x 1100 HDMI

Onboard Intel i7-6700:
1x 3840 x 1100 HDMI

I am now running everything off the i915 driver as expected.

The issue I am having is when going into Display Configuration the resolution and refresh options shown for the HDMI display on the Arc seem to be defaults; there is no means to select the 3840x1100 native. Its almost like the Arc is not reading the EDID?

However the Arc is reading the EDID as I found out…

cat /sys/class/drm/card0-HDMI-A-2/edid | parse-edid
cat /sys/class/drm/card1-HDMI-A-4/edid | parse-edid

Both show the same results correctly listing the 3840 x 1110 mode…
Modeline "Mode 0" 282.89 3840 3888 3920 4100 1100 1103 1108 1150 +hsync -vsync

This explains why swapping the monitors has no effect…

So far I have attempted the following kernel line parameter…
video=HDMI-A-4:3840x1100@60

Which resulted in this in DMESG…
i915 0000:04:00.0: [drm] User-defined mode not supported: "3840x1100": 60 282890 3840 3888 3920 4100 1100 1103 1108 1150 0x68 0x9

Could it be that the Arc just genuinely doesn’t support this resolution, seems unlikely since my onboard does? Or is it just that setting the video mode like this isn’t the way to do it?

Thanks for any help anyone can give as I don’t know where to go from here really. Is it a limitation, is it a bug, and if so with the Intel i915 driver or Plasma or Wayland?

I’ve attached below the full output of kscreen-doctor -i -o
As can be seen the modes listed for HDMI-A-4 are blatantly wrong, they do not match the EDID. They should read the same as HDMI-A-2.

Environment: 
  * KSCREEN_BACKEND           : [not set]
  * KSCREEN_BACKEND_INPROCESS : [not set]
  * KSCREEN_LOGGING           : [not set]
Logging to                : [logging disabled]
Preferred KScreen backend : KSC_KWayland.so
Available KScreen backends:
  * KSC_Fake.so: /usr/lib/x86_64-linux-gnu/qt6/plugins/kf6/kscreen/KSC_Fake.so
  * KSC_KWayland.so: /usr/lib/x86_64-linux-gnu/qt6/plugins/kf6/kscreen/KSC_KWayland.so
  * KSC_QScreen.so: /usr/lib/x86_64-linux-gnu/qt6/plugins/kf6/kscreen/KSC_QScreen.so
  * KSC_XRandR.so: /usr/lib/x86_64-linux-gnu/qt6/plugins/kf6/kscreen/KSC_XRandR.so

Output: 1 HDMI-A-4
        enabled
        connected
        priority 5
        HDMI
        Modes:  0:3840x2160@60*!  1:3840x2160@60  2:3840x2160@50  3:3840x2160@30  4:3840x2160@30  5:3840x2160@25  6:3840x2160@24  7:3840x2160@24  8:2560x1080@60  9:2560x1080@60  10:1920x1080@60  11:1920x1080@60  12:1920x1080@50  13:1680x1050@60  14:1600x900@60  15:1280x1024@75  16:1280x1024@60  17:1440x900@60  18:1280x800@60  19:1152x864@75  20:1280x720@60  21:1280x720@60  22:1280x720@60  23:1280x720@50  24:1024x768@75  25:1024x768@70  26:1024x768@60  27:832x624@75  28:800x600@75  29:800x600@72  30:800x600@60  31:800x600@56  32:720x576@50  33:720x480@60  34:720x480@60  35:720x480@60  36:720x480@60  37:640x480@75  38:640x480@73  39:640x480@67  40:640x480@60  41:640x480@60  42:640x480@60  43:720x400@70 
        Geometry: 0,1440 2560x1440
        Scale: 1.5
        Rotation: 1
        Overscan: 0
        Vrr: incapable
        RgbRange: Automatic
        HDR: incapable
        Wide Color Gamut: incapable
        ICC profile: none
Output: 2 DP-4
        enabled
        connected
        priority 1
        DisplayPort
        Modes:  0:2560x1440@60*!  1:2048x1080@60  2:2048x1080@24  3:1920x1080@60  4:1920x1080@60  5:1920x1080@60  6:1920x1080@50  7:1600x1200@60  8:1280x1024@75  9:1280x1024@60  10:1152x864@75  11:1280x720@60  12:1280x720@60  13:1280x720@60  14:1280x720@50  15:1024x768@75  16:1024x768@60  17:800x600@75  18:800x600@60  19:720x576@50  20:720x576@50  21:720x480@60  22:720x480@60  23:720x480@60  24:720x480@60  25:640x480@75  26:640x480@60  27:640x480@60  28:640x480@60  29:720x400@70 
        Geometry: 2560,0 2560x1440
        Scale: 1
        Rotation: 1
        Overscan: 0
        Vrr: incapable
        RgbRange: Automatic
        HDR: incapable
        Wide Color Gamut: incapable
        ICC profile: none
Output: 3 DP-5
        enabled
        connected
        priority 3
        DisplayPort
        Modes:  0:2560x1440@60*!  1:2048x1080@60  2:2048x1080@24  3:1920x1080@60  4:1920x1080@60  5:1920x1080@60  6:1920x1080@50  7:1600x1200@60  8:1280x1024@75  9:1280x1024@60  10:1152x864@75  11:1280x720@60  12:1280x720@60  13:1280x720@60  14:1280x720@50  15:1024x768@75  16:1024x768@60  17:800x600@75  18:800x600@60  19:720x576@50  20:720x576@50  21:720x480@60  22:720x480@60  23:720x480@60  24:720x480@60  25:640x480@75  26:640x480@60  27:640x480@60  28:640x480@60  29:720x400@70 
        Geometry: 0,0 2560x1440
        Scale: 1
        Rotation: 1
        Overscan: 0
        Vrr: incapable
        RgbRange: Automatic
        HDR: incapable
        Wide Color Gamut: incapable
        ICC profile: none
Output: 4 DP-6
        enabled
        connected
        priority 4
        DisplayPort
        Modes:  0:2560x1440@60*!  1:2048x1080@60  2:2048x1080@24  3:1920x1080@60  4:1920x1080@60  5:1920x1080@60  6:1920x1080@50  7:1600x1200@60  8:1280x1024@75  9:1280x1024@60  10:1152x864@75  11:1280x720@60  12:1280x720@60  13:1280x720@60  14:1280x720@50  15:1024x768@75  16:1024x768@60  17:800x600@75  18:800x600@60  19:720x576@50  20:720x576@50  21:720x480@60  22:720x480@60  23:720x480@60  24:720x480@60  25:640x480@75  26:640x480@60  27:640x480@60  28:640x480@60  29:720x400@70 
        Geometry: 5120,0 2560x1440
        Scale: 1
        Rotation: 1
        Overscan: 0
        Vrr: incapable
        RgbRange: Automatic
        HDR: incapable
        Wide Color Gamut: incapable
        ICC profile: none
Output: 5 HDMI-A-2
        enabled
        connected
        priority 2
        HDMI
        Modes:  0:3840x1100@60*!  1:3840x2160@30  2:3840x2160@30  3:3840x2160@25  4:3840x2160@24  5:3840x2160@24  6:1920x2160@60  7:2560x1440@60  8:2560x1080@60  9:2560x1080@60  10:1920x1080@60  11:1920x1080@60  12:1920x1080@60  13:1920x1080@60  14:1920x1080@50  15:1680x1050@60  16:1600x900@60  17:1280x1024@75  18:1280x1024@60  19:1440x900@60  20:1280x800@60  21:1152x864@75  22:1280x720@60  23:1280x720@60  24:1280x720@60  25:1280x720@50  26:1024x768@75  27:1024x768@70  28:1024x768@60  29:832x624@75  30:800x600@75  31:800x600@72  32:800x600@60  33:800x600@56  34:720x576@50  35:720x480@60  36:720x480@60  37:720x480@60  38:720x480@60  39:640x480@75  40:640x480@73  41:640x480@67  42:640x480@60  43:640x480@60  44:640x480@60  45:720x400@70 
        Geometry: 5120,1440 2560x734
        Scale: 1.5
        Rotation: 1
        Overscan: 0
        Vrr: incapable
        RgbRange: Automatic
        HDR: incapable
        Wide Color Gamut: incapable
        ICC profile: none

Thanks

Daniel

You might take a peek at other reports, similar to this one, though I think it is probably out of date.

It links to this and this which doesn’t really make things all that clear, of course. Note that neon, being Ubuntu 22.04 currently does have the 23.04 kernel.

Basically, the card is a bit fresh for the Ubuntu mesa/kernel, maybe. Possibly? An updated mesa is provided by intel in the second link, not sure if any source with more current Mesa (Kisak PPA, or similar) provides the same updates.

I am looking at potentially getting an a580 or better myself, maybe, though I only use 2 1080p monitors.

Yeah I have to admit Arc + Wayland + Plasma 6 is definitely living life on the edge. I did look at AMD but they didn’t have any cards that support 5 monitors so I would end up back in the realm of mixed drivers which didn’t seem ideal.

Interestingly a friend suggested something so obvious I don’t know why I didn’t try it before, I plugged the second HDMI monitor into the motherboard using a DVI to HDMI adaptor so both the HDMI monitors are now on the motherboard. The problem is now gone, it definitely seems to be tied to the Arc.

However I’m not sure where my setup is going in the future so I’m still interested to resolve the issue although now, for me at least I can take my time.

Does it work properly when logged in to an Xorg session?

Good idea, I just tried, same issue (works on the motherboard and not on the Arc). I’ve removed the Wayland tag from this post as its obviously not a Wayland issue.

When I get a chance I’m going to try booting from a vanilla Ubuntu 24.04 stick (Gnome) and see if the issue is there as well. That will help narrow it down further.

My guess at this stage is its an i915 driver issue or an Arc firmware issue, or potentially a physical limitation with the card on the HDMI port.

Thanks

Just an update on this…

Infront of me I have two Lenovo Thinkpads.
One with Display Port
One with HDMI
Both onboard Intel graphics, both running the same software stack as my desktop.

I just connected the same display up to HDMI laptop. Worked perfectly.
Then connected it up to the Display Port laptop via a HDMI adaptor, it showed the exact same issue as my desktop.

My understanding is the Intel Arc cards are essentially Display Port only and the HDMI port is actually emulated using a Realtek RTD2173 Display Port to HDMI converter.

If my theory is correct this is why the Arc cannot work with the displays…

That’s an unusual setup that might cause issues at different stage, the driver, the kernel, the drm dirver, kwin.

Did you try with X11, or even a different desktop environment?
It will allow to determine a bit where the issue lies.

I tried Neon 22.04 Plasma 6 in X11 and it was identical to Wayland.
Just downloading vanilla Ubuntu 23.10 to try that.

Display Port is a super set of the HDMI and DVI interfaces. My understanding is that the conversion between them is can be done with passive adapters.
Unlike VGA, for example, that requires active conversion.

Display port to HDMI requires an active converter to add the sync pulses I believe as Display Port is packet based.

OK testing with Ubuntu Gnome complete:
Exactly the same problem with 23.10 and 24.04 daily.

So that means its either not physically possible to do non-standard resolutions over HDMI with the Arc card or its a firmware or driver issue.

At least now we know for sure now its not a Plasma or Wayland issue.

That a protocol thing not a electrical thing. Which can do done by the GPU hardware through the DP connector.

For example DisplayPort to HDMI Adapter Converter - DisplayPort & Mini DisplayPort Adapters | Display & Video Adapters | StarTech.com United Kingdom states the cable is a passive adapter.

The cable you linked is designed for DP++ which is actually Display Port and HDMI combined on the same physical port, a bit like you get Thunderbolt on a USB-C port. Basically the clock generator is on the GPU chipset as you said.

However as it states on the link, the adaptor wont work with a pure Display Port because that uses a different protocol which doesn’t contain the HDMI electrical clock signals (a bit like a Thunderbolt device wont work on a USB-C port designed just for USB) which is why you need an active adaptor to generate the sync pulse.

In the case of the Arc graphics cards the GPU is not capable of natively generating HDMI so they use a Realtek RTD2173 chip on one of the display port outputs to convert it to HDMI and generate the clock pulse. You can see the detail on the techpowerup website (apparently I cant post links) and theres information on the RTD2173 on the anandtech website.

So the issue if if the RTD2173 is incapable of producing non standard resolutions and its not flash upgradable to add that capability the Arc cards will never support non standard monitors no matter what drivers they release.

So I came over here from the EndeavourOS forums experiencing more or less the same issue with an A750 and a 2560x1080 LG ultrawide display. I also find it behaves exactly the same in default (Gnome) Fedora and Fedora Xfce.

However, booting the exact some hardware configuration to Windows 10 yields a fully functional display (i.e. 2560x1080 resolution at both 60 and 75 Hz refresh rates the LG is designed for). So this doesn’t appear to be a case that the GPU is incapable of natively generating HDMI: this is only happening Linux-side. And only specifically with the Arc/i915 as I previously had a GTX1650 in my machine and had no issues whatsoever with display configurations.

@Daniel_Bull Have you attempted to boot this same hardware setup to Windows at all? I would be curious to see if your A580 behaves as expected under that environment like mine.

Sorry no I’ve not, I’ve not used Windows for a long time now so its not something I could test.

If its the case it works in Windows and not Linux that’s very interesting, almost like its an ARC or an RTD2173 driver issue?

So can you confirm just to make sure theres no confusion; your 2560x1080 works when connected via a HDMI cable directly to your A750 under Windows but under Linux you don’t get offered that resolution?

That is correct. I’ve got a forum post over at the eOS forums going through this. It appears I cannot post the link in here (yet?), so you can get to it through my profile blurb here.

But yes, the LG display in question works perfectly fine booted into Windows 10 over HDMI. Full 2560x1080 resolution; both refresh rates of 60 and 75 Hz. None of those options are available in Xfce or Gnome on the Linux side (I only get 1920x1080 @ 60Hz at best), despite Xorg probing the DDC to the display and DDC returning the 2560x1080 resolutions.

Some assistance over at eOS finally turned up some useful data. There’s an open bug report over at freedesktop’s gitlab (10654, “Unable to set uncommon screen resolution with Arc 380”) going over the same issue(s) with some sort of resolution in the works:

This is another case caused by the lack of the PLL algorithm.

There is a patch in works over there (135397, “Add HDMI PLL Algorithm for SNPS/C10PHY”) so far that seems to have resolved the problem for some. I’m going to try to implement it when I have the time to.

The patch I spoke to above that was sent over to intel-gfx (no. 135397 titled “Add HDMI PLL Algorithm for SNPS/C10PHY”) resolved my display problems on my A750. Applied the 5 patch files to the kernel source and built a new kernel to install. Booting back into that kernel and I had full use of my display’s modes once again. No need to muck around with forcing EDIDs or anything.

I hope this could resolve your situation as well! Cheers!

1 Like

Oh wow awesome!
Thanks!