USB-C -> Display Port issue

Hello, I’m using a a USB-C hub to Display Port, this 1 in specific:

It will recognize the monitor and the monitor will turn on and light up (never get any actual display) than it turns back off. In the KDE Plasma display settings I can see the monitor and move it around, but enable/disabling doesn’t fix the issue neither does changing from 1440p to 1080p. I as well on the right side have another USB-C port and I plug a 2nd 1440p external monitor into it with HDMI instead of DP, this one works well plugged into the USB-C port I want it in aswell as the USB-C dock that the DP monitor has issues with.
I than tried both monitors on HDMI and the “difective” monitor plugged into the right side USB-C hub works fine, along with the 1440p plugged in via HDMI to the left side USB-C port. They both worked but I want the original setup because the USB-C → DP allows for 120hz on the main monitor I use and would like that instead of both being bottle necked at 60hz on the HDMI cables I have.
This whole setup that I’m attempting with works on my Windows 11 installation without any issue, so it doesn’t appear to be a hardware issue in my setup. Any help or information on what info I can gather to help diagnose would be greatly appreciated!

Because Windows works, I’d give a live distro or 2 or 3 other than openSUSE a try to see if the problem remains. If yes, I’d say you have a reportable upstream kernel driver bug. If not, I’d report a bug on

Before you do that, try an IceWM session or some other DE instead of Plasma. They don’t use KScreen2 to get tangled up with multiple displays. Or, try just disabling KScreen2 from automatically starting in background startup settings. Either way, if the problem goes away, you’re experiencing a Plasma impediment. You can use xrandr directly, or arandr indirectly, to configure displays if necessary with KScreen2 disabled, or running IceWM.

Amazing thank you for your response, I’m going to try a couple other Distros and the other DE to rule out KDE Plasma & Open Suse.
What do you mean about the xrandr and arandr part? is there any documentation I can read to understand that interaction better?
EDIT: About 2 days ago I had Garuda Linux (Arch based) running KDE Plasma with the same hardware setup and it ran the same way as windows, I think the Kernel I was using in specific was either 6.1 - 6.3 Zen Kernel.

I’m downloading Gnome at the moment X11 and Wayland to see if there’s an difference when I login to them instead of KDE. I really like plasma and my layout unfortunately so I hope I can find some resolution in that DE.

I tried with IceWM, Gnome (X11 & Wayland) and KDE Plasma (X11 and Wayland) all of them show the same results where they recognize the monitor but the monitor continues to power up and show a back light, than it powers down. Happens once every 10-15 seconds.

Sounds like an openSUSE-specific kernel or X bug that needs to be reported. You might try a devel (6.3rc) kernel or next kernel first to see if anything differs. The parents of those two repo directories contain ready-to-use .repo files that you can place in /etc/zypp/repos.d/ instead of manually enabling with zypper addrepo or YaST repositories.

Arandr is just a DE-agnostic GUI tool that can generate xrandr scripts to configure multiple displays. Xrandr is the backend that all GUI screen management tools, like KScreen2, employ. man xrandr

I go to your “next kernel” link and go up one directory to find the .repo file, however when I select the repo link it doesn’t initiate a download. Is there another url I should be trying to hit or should I be trying to pull via curl/wget?
Nevermind I was able to using firefox, the brave browser was being a pain

I have the .repo file inside of the /zypp/repos.d/ and I can now see that Repository in my Yast software manager repositories, but which package do I install? I see 2 others that start with “The Standard Kernel …” when I go to install one of them it gives me a message about deleting the current running one. Even though in my zypp.conf I have it set to allow multiple kernels. What should be my next step for moving to the new kernel for testing?
Okay I figured it out (I hope), I got the 6.3 vanilla kernel running and having the same issue with the monitor. I could try Ubuntu or Debian to verify they work on their Kernels atm too.

OMG it’s working… I changed the resoluton to 1080p than back to 1440p and now it’s showing… WHAT?!
I’m going to run it awhile and see what issues I run into. Is there any commands I can run to gather additional information while it’s connected?

Thank you so much for the assistance!

Working with kernel-default-6.2.10?

Your configuration state can be shared via input/output copy/paste using PRE tags (</> icon) after running inxi -GSaz and xrandr --listproviders in Konsole. The X log Xorg.0.log can be found in either /var/log/ or ~/.local/share/xorg/ (usually the former for Plasma users), and shared by upload using the susepaste command, e.g. cat /var/log/Xorg.0.log |susepaste -e 40320 (-e 40320 sets expiration to 1 month instead of 1 day default; man susepaste for alternate expires) and then posting here a resulting URL. If ambitious you might also append simple xrandr output to Xorg.0.log before susepasting it, or susepaste it separately. For 3 displays it typically gets a little long for pasting here, and adds modestly to inxi output.

No currently I’m on 6.3.0 Vanilla Kernel. I booted into windows 11 and back to Open Suse and the monitor was in the same problem state, the switching to 1080p and back to 1440p worked in bringing it back.
I ran the Xorg.0.log command:

Pasted as:

I also ran the other commands you mentioned:

gloat@localhost:~> inxi -GSaz
  Kernel: 6.3.0-rc7-1.g9e073da-vanilla arch: x86_64 bits: 64 compiler: gcc
    v: 13.0.1 parameters: BOOT_IMAGE=/boot/vmlinuz-6.3.0-rc7-1.g9e073da-vanilla
    root=UUID=ca4ceb27-a537-4bc8-957c-f494534d3c2c splash=silent
    mitigations=auto quiet security=apparmor
  Desktop: KDE Plasma v: 5.27.4 tk: Qt v: 5.15.8 wm: kwin_wayland vt: 2 dm:
    1: GDM v: 44.0 2: SDDM note: stopped Distro: openSUSE Tumbleweed 20230419
  Device-1: AMD Navi 23 [Radeon RX 6650 XT / 6700S 6800S] vendor: ASUSTeK
    driver: amdgpu v: kernel arch: RDNA-2 code: Navi-2x process: TSMC n7 (7nm)
    built: 2020-22 pcie: gen: 4 speed: 16 GT/s lanes: 16 ports: active: DP-1
    empty: HDMI-A-1,eDP-1 bus-ID: 03:00.0 chip-ID: 1002:73ef class-ID: 0300
  Device-2: AMD Rembrandt [Radeon 680M] vendor: ASUSTeK driver: amdgpu
    v: kernel arch: RDNA-2 code: Navi-2x process: TSMC n7 (7nm) built: 2020-22
    pcie: gen: 4 speed: 16 GT/s lanes: 16 ports: active: DP-12,eDP-2
    empty: DP-10, DP-11, DP-2, DP-3, DP-4, DP-5, DP-6, DP-7, DP-8, DP-9
    bus-ID: 07:00.0 chip-ID: 1002:1681 class-ID: 0300 temp: 54.0 C
  Device-3: IMC Networks USB2.0 HD UVC WebCam type: USB driver: uvcvideo
    bus-ID: 3-3:2 chip-ID: 13d3:56eb class-ID: fe01 serial: <filter>
  Device-4: Sunplus Innovation NexiGo N930AF FHD Webcam type: USB
    driver: snd-usb-audio,uvcvideo bus-ID: 7-1.4.2:5 chip-ID: 1bcf:2283
    class-ID: 0102 serial: <filter>
  Display: wayland server: v: with: Xwayland v: 23.1.1
    compositor: kwin_wayland driver: X: loaded: modesetting unloaded: fbdev,vesa
    dri: radeonsi gpu: amdgpu,amdgpu d-rect: 6327x4000 display-ID: 0
  Monitor-1: DP-1 pos: top-right res: 1440x2560 size: N/A modes: N/A
  Monitor-2: DP-12 pos: bottom-c res: 2560x1440 size: N/A modes: N/A
  Monitor-3: eDP-2 pos: bottom-l res: 2327x1455 size: N/A modes: N/A
  API: OpenGL v: 4.6 Mesa 23.0.2 renderer: AMD Radeon Graphics (rembrandt
    LLVM 16.0.1 DRM 3.52 6.3.0-rc7-1.g9e073da-vanilla) direct render: Yes
gloat@localhost:~> xrandr --listproviders
Providers: number : 0

That shouldn’t happen:

# xrandr --listproviders
Providers: number : 1
Provider 0: id: 0x46; cap: 0xf (Source Output, Sink Output, Source Offload, Sink Offload); crtcs: 3; outputs: 5; associated providers: 0; name: modesetting
    output DP-1
    output HDMI-1
    output HDMI-2
    output HDMI-3
    output DP-2
# inxi -SGaz --vs --hostname
inxi 3.3.26-00 (2023-03-28)
  Host: ab250 Kernel: 6.2.6-1-default arch: x86_64 bits: 64 compiler: gcc
    v: 12.2.1 parameters: BOOT_IMAGE=/boot/vmlinuz root=LABEL=pt3p07stw
    noresume ipv6.disable=1 net.ifnames=0 mitigations=auto 5
  Desktop: Trinity v: R14.0.13 tk: Qt v: 3.5.0 info: kicker wm: Twin v: 3.0
    vt: 7 dm: 1: TDM 2: XDM Distro: openSUSE Tumbleweed 20230326
  Device-1: Intel HD Graphics 630 vendor: ASUSTeK driver: i915 v: kernel
    arch: Gen-9.5 process: Intel 14nm built: 2016-20 ports:
    active: DP-1,HDMI-A-2,HDMI-A-3 empty: DP-2,HDMI-A-1 bus-ID: 00:02.0
    chip-ID: 8086:5912 class-ID: 0300
  Display: x11 server: X.Org v: 21.1.7 driver: X: loaded: modesetting
    unloaded: fbdev,vesa alternate: intel dri: iris gpu: i915 display-ID: :0
    screens: 1
  Screen-1: 0 s-res: 3600x2640 s-dpi: 120 s-size: 762x558mm (30.00x21.97")
    s-diag: 944mm (37.18")
  Monitor-1: DP-1 pos: primary,bottom-l model: Acer K272HUL serial: <filter>
    built: 2018 res: 2560x1440 hz: 60 dpi: 109 gamma: 1.2
    size: 598x336mm (23.54x13.23") diag: 686mm (27") ratio: 16:9 modes:
    max: 2560x1440 min: 720x400
  Monitor-2: HDMI-A-2 mapped: HDMI-2 pos: top-left model: NEC EA243WM
    serial: <filter> built: 2011 res: 1920x1200 hz: 60 dpi: 94 gamma: 1.2
    size: 519x324mm (20.43x12.76") diag: 612mm (24.1") ratio: 16:10 modes:
    max: 1920x1200 min: 640x480
  Monitor-3: HDMI-A-3 mapped: HDMI-3 pos: top-right model: Dell P2213
    serial: <filter> built: 2012 res: 1680x1050 hz: 60 dpi: 90 gamma: 1.2
    size: 473x296mm (18.62x11.65") diag: 558mm (22") ratio: 16:10 modes:
    max: 1680x1050 min: 720x400
  API: OpenGL v: 4.6 Mesa 23.0.0 renderer: Mesa Intel HD Graphics 630 (KBL
    GT2) direct-render: Yes

Do you get nothing again when you boot Garuda or other live media that works correctly?

I looked at the log. It looks like xf86-video-amdgpu and/or kernel-firmware-amdgpu may not be installed. X didn’t even try to load the amdgpu DDX. Normally GPUs like yours should run on the amdgpu DDX display driver in preference to the modesetting DIX as is currently happening. It could make a difference with your issue. Do you have anything in /etc/X11/xorg.con* explicitly directing modesetting to load instead?

Am I able to install that through the Yast software manager? I haven’t touched the xorg.con* file or haven’t had the need to.

It looks like the file xorg.conf.install has the modsetting set:

localhost:/home/gloat # cat /etc/X11/xorg.conf.install 
Section "Device"
  Identifier "modesetting"
  Driver  "modesetting"
  Option "PreferCloneMode" "true"
  Option "AccelMethod" "none"

Section "Screen"
  Identifier "modesetting"
  Device "modesetting"

Section "Device"
  Identifier "fbdev"
  Driver  "fbdev"

Section "Screen"
  Identifier "fbdev"
  Device "fbdev"

Section "Device"
  Identifier "vesa"
  Driver  "vesa"

Section "Screen"
  Identifier "vesa"
  Device "vesa"

Section "ServerLayout"
  Identifier "Layout"
  Screen  "modesetting"
  Screen  "fbdev"
  Screen  "vesa"

I have both Firmware AMD GPU and the other one you mentioned installed but how do I force X11 to use amdgpu isntead of modesetting?

If xf86-video-amdgpu, libdrm_amdgpu1 and kernel-firmware-amdgpu are all installed, the following should be enough.

# cat /etc/X11/xorg.conf.d/15-ddxdrv.conf
Section "Device"
  Identifier "DDX"
	Driver "amdgpu"

If it’s not, it would be a reportable bug. It shouldn’t be necessary, also a bug I think.

/etc/X11/xorg.conf.install is normally just a space waster that was used during OS installation. It can function as a template.

Most installations have no need for *.conf in /etc/X11*. Yours might possibly do better with because you have two graphic cards, but let’s not try that without a bug report first, because you shouldn’t need any.

Unfortunately that didn’t fix the issue. It ended up making it so my other 1440p monitor only reads 1080p and the affected monitor I wasn’t able to get going again.
I ended up adding the kernel parameters amd.si_support=1 amd.cik_support=1 radeon.si_support=0 radeon.cik_support=0
the monitor stays fine through laptop locks but on reboot I have to re-enable the monitor in display settings and set it to 1080p than back to 1440p. Any workaround or additional thoughts?
This morning when I booted up the monitor worked as intended without any finagglery. I’ll keep testing.

Running really good, I actually reverted back to running the Open Suse stable kernel instead of the mainline version. I think I was being a turd in describing my issue because I was using wayland the whole time as well. Thank you for all your help!

None of the Xorg stuff applies in that case.