I feel pretty good about this as I have only had Linux installed as my daily driver since late October 2025. This machine is the only exposure to Linux I get, as I work as a Windows sysadmin. I run openSUSE LEAP 16.0 with KDE and while I can’t say I’m comfortable or even within spitting-distance of being comfortable with it, I feel like today moved the needle a bit more towards that.

This started a few days ago with my three displays. I run an LG 34" curved display as my main monitor and two 27" CRUA curved displays on the sides of it. Previously, I had experienced no issues with this setup when using Bricklink Studio 2.0 via wine. However, on Thursday night I quit Studio and boom, my side monitors wouldn’t stay on or detect a signal, and my main display kept freaking out and blinking every 5-7 seconds. I could get one of the two side monitors to work, but not both with the main monitor.

Long story short (DP->HDMI adapter swaps, cable changes, port arrangements with the graphics card, etc.), I used DuckDuckGo searches (lots of the results came from the Arc forums, my consolences) and was pointed toward log files for kwin. I used the Logs app on my machine to check the important logs that would appear when I tried to have both monitors plugged in. That showed me that it was having trouble finding or removing some reference object. I looked in the Display Configuration settings and noticed the monitors would pop up, last for about 5-7 seconds, then get disconnected within the same time frame as the logs. I also noticed that when they would be visible, the ‘Enable’ checkbox would be unchecked.

So with my trusty vertical mouse in hand, I studied the placement of the buttons and checkbox and after a few fails, successfully selected the checkbox to enable one of the displays, apply the change, and select keep before it could fully disconnect the monitor. Boom! The monitor turned back on and stayed on. I had to adjust it’s position in the layout, but after that, it had no issue being on! I repeated this for the other monitor and now, I am happy to say, all three of my monitors are on and my system is running exactly as before!

I really appreciate the openness to information that I see in many of the Linux communities, and thank you to those of you who have contributed, or will contribute to that knowledge. Because of people keeping that information open and available, a complete and utter Linux-n00b like myself can take a shot at investigating and fixing my own system woes.

Best regards!

P.S. I have a theory about what happened with wine and why the issue wouldn’t happen with one of the side monitors plugged in, and only happen when both were. But I’ll save that for a comment if someone asks.

  • Ænima@lemmy.zipOP
    1·
    8 hours ago

    I posted this in another comment in this same thread, but figure I’d just paste it here for you!

    I don’t know how wine works fully, but I know a bit about how Windows works. Based on my use of emulation and VMs, wine strikes me more as an emulator. Windows expects a certain structure and wine sets up a sort of emulated instance of that environment. If I’m correct in my assumptions, wine has to get control information about the monitor from Linux to display the application correctly when it’s being emulated. When I closed Studio 2.0, I believe wine failed to pass this monitor information/control back to Linux. Linux didn’t think it should have the monitor control cause wine never passed it back, so every time the OS detected the monitors, it would essentially say, “no thanks, you should be hanging out with wine right now!” and disable the monitors within Linux. This caused the monitors to basically disconnect. Since wine had closed, there was nothing to take that control back, so the monitor just reappeared on the list of OS hardware to take control of, and would again say, “no thanks,” over and over.

    Again, I may be completely off-base and merely speculating, but when I managed to quickly toggle the monitor back to enable and save the configuration, it changed the handling of the monitor to forcefully tell Linux to take it back and use it, which broke the loop. Again, not sure, but it was quite a journey. Glad to have all my monitors back to 100Hz and super glad my graphics card doesn’t need to be replaced!

    Thank you for your question!

    I appreciate you taking the time to reply!

    • nyan@sh.itjust.works
      2·
      4 hours ago

      Careful there, WINE Is Not an Emulator (yes, really, that’s what it stands for—back in the 90s, we thought that recursive acronyms were cool. See also GNU).

      What you saw could indeed have been a bad handoff, assuming it didn’t persist through a reboot. If it did, then it sounds more like a KDE (or Wayland?) bug.

      • Ænima@lemmy.zipOP
        1·
        4 hours ago

        At the time it was using X11. But changing to Weyland was one of the things I tried. Seemed whatever the fault, it persisted through reboots and those changes. Is there something that both X11 and Weyland check when processing the handshakes?