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 bugzilla.opensuse.org.
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?
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:
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?
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!