Finally got my wife away from Windows and on Fedora 40 (Gnome 46).

Now, when her PC goes to suspend and when she wakes it up, one of her 2 monitors doesn’t wake up.

Both are connected to HDMI ports (no dedicated video card, just the integrated card in her Ryzen 9).

Any ideas on what could be happening? I wouldn’t want her to go back to Winblows over something so insignificant, but she would.

  • Deckweiss@lemmy.world
    23·
    8 months ago

    One monitor not working after sleep - “insignificant”

    Thats the true Linux nerd mentality :D

    Jokes aside, can you check for anything gpu or monitor related in journalctl after the wakeup?

    • youmaynotknow@lemmy.mlOP
      21·
      8 months ago

      I’ll check all the logs as soon as she stands up from her desk. Thanks so much.

      And about the “joke”, not really a joke. Most of us see that as nothing more than a slight bump on the road. But Windows users moving over to the brighter side of computers will see that as an excuse to go back to pain. People are weird.

  • Corngood@lemmy.ml
    16·
    8 months ago

    I’d probably:

    1. make sure it can be reliably reproduced using something like systemctl suspend
    2. try swapping the cables and see if it still happens on the same screen, or the same port
    3. look at journald/dmesg output for the period from suspend to resume

    When the screen fails to wake, are you able to get it back by powering it off, or by unplugging it? Is it X or wayland?

    • Para_lyzed@lemmy.world
      3·
      8 months ago

      Fedora 40 removes X by default (you’d have to install it yourself), so this is going to be using Wayland. Seems like they’re using Ryzen integrated graphics, so at least it shouldn’t be related to any of the problems with Nvidia on Wayland.

      • youmaynotknow@lemmy.mlOP
        2·
        8 months ago

        That’s correct. She’s on Ryzen integrated, and Wayland by default, and all info on this subject out there points to Nvidia related issues. Thanks guys.

    • youmaynotknow@lemmy.mlOP
      2·
      8 months ago

      Switched cables for between monitors, the same monitor did not come up again.

      Wayland is the default on Fedora.

      I’m waiting for my wife to get up from her desk to look at all the logs.

  • acockworkorange@mander.xyz
    9·
    8 months ago

    This happens to me consistently on Linux Mint. My secondary monitor which is an HDMI TV resumes fine and takes over as primary. The primary screen on a Display Port over USB fails to wake up.

    I’m using the edge kernel line, version 6.5. I’ll try to downgrade to 5.15 to check if this is a kernel regression.

    I’m running an AMD system with embedded graphics from Minisforum, btw. What are you running and which kernel?

    • applepie@kbin.social
      4·
      8 months ago

      i got pop (fresher kernel?) and xorg but same issue you described. i keep unplugged unless i am using it but also since it will limit main monitor fps.

      • acockworkorange@mander.xyz
        2·
        8 months ago

        I have tried disconnecting and then connecting the display to see if it will wake up, but it doesn’t work. Sometimes shutting down the display and turning it on again work.

      • acockworkorange@mander.xyz
        2·
        8 months ago

        I managed to get it on kernel 5.15 and replicate the issue. I had to find its USB-C charger to keep it on while I power down my monitor otherwise it would hard shutdown it. So, connecting the monitor back, the weirdest thing just happened. The display rearranged, but didn’t use the new monitor. Instead, the lock screen got resized and I could see my session behind it without logging in (!).

        I’ve got this on dmesg: [119330.829398] amdgpu 0000:63:00.0: [drm] *ERROR* no VCPI for [MST PORT:00000000e7b3da3d] found in mst state 000000005563f49a

        journalctl gives more details:

        May 03 17:05:01 Glass /usr/libexec/gdm-x-session[1601]: (II) AMDGPU(0): Allocate new frame buffer 2560x1440
May 03 17:05:01 Glass /usr/libexec/gdm-x-session[1601]: (II) AMDGPU(0):  => pitch 10240 bytes
May 03 17:05:01 Glass rtkit-daemon[1209]: Supervising 7 threads of 3 processes of 1 users.
May 03 17:05:01 Glass rtkit-daemon[1209]: Successfully made thread 33483 of process 1581 owned by '1000' RT at priority 5.
May 03 17:05:01 Glass rtkit-daemon[1209]: Supervising 8 threads of 3 processes of 1 users.
May 03 17:05:01 Glass csd-media-keys[1761]: Unable to get default sink
May 03 17:05:01 Glass csd-color[1770]: failed to reset xrandr-Samsung Electric Company-SAMSUNG gamma tables: gamma size is zero
May 03 17:05:01 Glass csd-color[1770]: failed to reset xrandr-Samsung Electric Company-SAMSUNG gamma tables: gamma size is zero
May 03 17:05:01 Glass /usr/libexec/gdm-x-session[1601]: (II) Quirked EDID physical size to 0x0 cm
May 03 17:05:01 Glass /usr/libexec/gdm-x-session[1601]: (--) AMDGPU(0): HDMI max TMDS frequency 225000KHz
May 03 17:05:01 Glass /usr/libexec/gdm-x-session[1601]: (II) AMDGPU(0): EDID vendor "SAM", prod id 29044
May 03 17:05:01 Glass /usr/libexec/gdm-x-session[1601]: (II) AMDGPU(0): Using hsync ranges from config file
May 03 17:05:01 Glass /usr/libexec/gdm-x-session[1601]: (II) AMDGPU(0): Using vrefresh ranges from config file
May 03 17:05:01 Glass /usr/libexec/gdm-x-session[1601]: (II) AMDGPU(0): Printing DDC gathered Modelines:

        I got it to switch monitors using Cinammon’s Display app, but it will not take two displays at the same time.

        • youmaynotknow@lemmy.mlOP
          1·
          8 months ago

          I would totally try a kernel update, even if it meant uxing zen kernel. Older kernels is one of the reasons why I stay away from Mint and Zorin.

          • acockworkorange@mander.xyz
            2·
            8 months ago

            Weirdest thing is I could swear it didn’t use to happen on Mint 21 until I both upgraded to 21.2 and switched to the edge low latency kernel. It doesn’t bother me much, and everything else just works, plus I’m addicted to aptitude so I need a Debian based distro.

  • rambos@lemm.ee
    4·
    8 months ago

    Simmilar problem here. It was working fine (on PopOS) until I replaced GPU GTX 1060 for RX570 a month ago. It happened only few times and powering off/on using monitor button worked. I guess Nvidia was handling it better for some reason

  • Shareni@programming.dev
    42·
    8 months ago

    If you’re on xorg, try executing an xrandr script. I’m currently having a similar issue but haven’t gotten around to automating it yet.

  • youmaynotknow@lemmy.mlOP
    2·
    8 months ago

    Thanks to everyone that tried to guide me.

    Quick update: For some weird reason, it’s not happening anymore. I ran a dnf update out of habit on it last night when we were going to bed, and completely neglected testing it. Today she suspended it to go out, and when she came back, it just woke up, entered her password, and both monitors were working.

    May have been I updated the kernel, but I honestly don’t remember if it even asked to restart to update,so,maybe it wasn’t? I’m confused, but happy that she never even mentioned windows, so it seems like she’s staying on this side of smart.

  • Rogue@feddit.uk
    2·
    8 months ago

    Occasionally only one of my monitors will turn on, I end up having to unplug the power cable to kick the other in to life.

    I’m using Debian, with an AMD 6700 XT graphics card, dual monitors via display port. I’ve just ended up accepting it as one of the quirks of the Linux experience.

  • onlinepersona@programming.devEnglish
    31·
    8 months ago

    So it works on windows? If so, then it’s probably not a hardware issue.

    What I could recommend to help track down the issue:

    • test another distro, if possible - sitting here on NixOS it works for me
    • test another display manager (aka X11)
    • test another desktop (KDE, LXDE, whatever)

    If it’s none of the above, you might need to get your hands dirty

    • check if it’s always the same monitor
    • check the logs (journalctl --boot -xe) maybe something will jump out
    • monitor the reconnection of peripherials with sudo udevadm monitor
    • start it when everything’s booted up and everything’s plugged in
    • disconnect problem monitor then reconnect it and observe the output
    • suspend then wake the computer and check the output

    That might give you a hint of what’s going on.

    There’s a change something isn’t working in terms of drivers. You can probe her computer with the executable from https://linux-hardware.org/ and share uploaded result here. Maybe there’ll be an indication of a missing driver or something.

    Anti Commercial-AI license