Unreponsive monitor after first login bluefin 39

[kookie]

Issue

Monitor is unresponsive after logging on. A hard reset (unplug power) brings me back to the desktop.

Machine

Minisform HM80
AMD Ryzen 7 4800U with inbuilt Radeon Graphics (Renoir)

base

ostree-image-signed:docker://ghcr.io/ublue-os/bluefin-dx:39

Troubleshooting

The following was tried and was unsuccessful.

• Tried different DisplayPort cables and ports
• Tried different HDMI cables and ports
• Disabled all extensions
• Configured mutter with the following: gsettings set org.gnome.mutter experimental-features "['scale-monitor-framebuffer']"

Observations

• Perviously was on Silverblue 38, ublue 38 and 39 and did not have this issue.
• Issues started to occur on fresh installation via ISO and rebase from ublue:39.
• Once the monitor has been power cycled on the initial login multiple login/logoff attemps/screen savers/etc do not exhibit this issue.
  • This works with all extensions enabled.
• On reboot and opening another shell (Ctl+Alt+F5) and running startx after logging in does not exhibit this issue.
• Issue appears to be isolated with the initial login process from a restart and in bluefin. Others have observed the same behavior in Bazzite.

Logs

rpm-ostree status

State: idle
AutomaticUpdates: stage; rpm-ostreed-automatic.timer: no runs since boot
Deployments:
● ostree-image-signed:docker://ghcr.io/ublue-os/bluefin-dx:39
                   Digest: sha256:66226b60b7707098287df645b32218dde6e5962a9173ece9d7640eb7607d2573
                  Version: 39 (2023-11-15T19:01:14Z)
          LayeredPackages: langpacks-en

  ostree-unverified-image:docker://ghcr.io/ublue-os/silverblue-main:latest
                   Digest: sha256:6774ee72dcfa181f7656cd27353611bff50f84e981742fba20d2f431cc1f322d
                  Version: 39 (2023-11-14T15:06:07Z)
          LayeredPackages: langpacks-en

  ostree-unverified-image:docker://ghcr.io/ublue-os/silverblue-main:latest
                   Digest: sha256:72715b94adecba3e376046bf47f4f253998c1ac76dbd3d9c16460a040609e824
                  Version: 39 (2023-11-13T15:07:37Z)
          LayeredPackages: langpacks-en
                   Pinned: yes

rpm-ostree kargs

rd.luks.options=discard rhgb quiet root=UUID=5f0b7466-055f-405a-852c-64d092d89da1 rootflags=subvol=root rw ostree=/ostree/boot.1/default/aeb0521c78312096d7e2e55e731b564f2d16ae03f5261ea1a478651b52fe438f/0 iommu=pt

[pyrignis]

I have the same issue, which does not seems to appear when I rebase to ublue/silverblue-main.

The issue also appeared when my computer went in a level of seep mode, sadly I don't know which one as I've tried to change theses settings to fix the main issue.

GPU : Radeon™ RX 480

[13aer]

Same issue for me (on bluefin-nvidia:38/39), also not on ublue/silverblue-nvidia:38/39.

Lenovo ThinkPad P15s Gen 2i w/ GPU: Hybrid Intel® Xe Graphics (TGL GT2)/Nvidia T500

Edit: Only for the Monitor connected via (TB)Dock/HDMI/(TB)HDMI, the built-in works fine but reacts a bit slow after sleep/at startup.

I try to pinpoint if it is a Monitor issue or something else atm.

[castrojo]

Ok let's rule out gnome vrr, can you do just gnome-vrr and disable it, you'll need to log out and back in.

[pyrignis]

Ok let's rule out gnome vrr, can you do just gnome-vrr and disable it, you'll need to log out and back in.

On my setup this did not solve the issue, neither after logging out nor after rebooting.

[bobslept]

Because I have no clue what is the actual thing causing this behavior. It would be the easiest to strip down certain stuff and try if we can pinpoint what is causing this. I don't have the issue myself, so if somebody has the time to test it with me, please let me know in the bluefin discord and refer to this issue. Be ware this could take some time, as we need to rebase and build images back and forth.

And ofcourse this only works if you are able to reproduce this bad behavior on fairly steady basis.

[fiftydinar]

I don't know if VRR is the cause for this situation, but for me, it causes frequent lock-ups on fullscreen apps.

VRR patch is in this state for like a month.

[kookie]

I've also noted the following scenarios where the screen would also lock up.

• After monitor goes to sleep after x minutes
• Shutting down the machine the monitor goes into that hung state and never enters sleep mode.

[castrojo]

And to confirm ublue-os/bluefin:38 and ublue-os/silverblue-main:38 are unaffected? So far it's looking mostly like an issue with 39?

[kookie]

For me the issue was only on the bluefin image (38 and 39).
ublue-os/silverblue-main 38 and 39 were working fine.

[pyrignis]

For me the issue was only on the bluefin image (38 and 39). ublue-os/silverblue-main 38 and 39 were working fine.

I couldn't rebase to bluefin 38 because of some RPM Fusion key issues but the issue did not arive when I rebased to silverblue-main 39, and did not happen in 6 month with silverblue-main 38. Rebasing back to bluefin:latest brought back the issue.

[castrojo]

OK let's rule out evdi. Can ya'll try disabling the service: systemctl stop displaylink and then systemctl disable displaylink.

And then sudo rmmod evdi to remove the kernel module.

[pyrignis]

Not sure if expected, evdi doesn't seems loaded

$ systemctl stop displaylink
$ systemctl disable displaylink
Removed "/etc/systemd/system/multi-user.target.wants/displaylink.service".
$ sudo rmmod evdi
rmmod: ERROR: Module evdi is not currently loaded

[kookie]

Applied, Rebooted and still an issue.

❯ systemctl status displaylink
○ displaylink.service - DisplayLink Manager Service
     Loaded: loaded (/usr/lib/systemd/system/displaylink.service; disabled; preset: enabled)
    Drop-In: /usr/lib/systemd/system/service.d
             └─10-timeout-abort.conf
     Active: inactive (dead)

I have also disabled Gnome-VRR via just and still having the same issues.

❯ just gnome-vrr
Gnome-VRR is currently Disabled
Enable or Disable Gnome-VRR
To apply the changes make sure you logout and restart your session

[bobslept]

I think I figured out what is causing this. If you want to try and let me know if using the image below fixes your problem

These are for testing, not for daily use

Bluefin image

rpm-ostree rebase ostree-image-signed:docker://ghcr.io/bobslept/bluefin:39

Bluefin-dx image

rpm-ostree rebase ostree-image-signed:docker://ghcr.io/bobslept/bluefin-dx:39

Or if you want to test it with your own fork. Relevant changes: bobslept@3eb9fa0

[pyrignis]

This change does indeed seems to fix the issue.

[kookie]

Confirming the image from @bobslept is working as expected. No screen freezes in any situation now. Good to get this merged.

Also I rebased using bluefin-dx:39

[castrojo]

Interesting! Does ddccontrol not have a service unit? I'm trying to figure out if we can ship the binaries for people who need it but not affect others.

[castrojo]

Ok I've PRed the removal of these packages, nice teamwork ya'll!

There's an alternative tool in the archive named ddcutil that might cover the usecase, so if someone wants to layer that and see what happens we can always add that later.

[bobslept]

Interesting! Does ddccontrol not have a service unit? I'm trying to figure out if we can ship the binaries for people who need it but not affect others.

Crazy right! Let me say it wasn't the first thing I tried to disable... 😄

Disabling the service file is not really working because it is intended to be trigged by dbus. So you can't really disable it.

❯ sudo systemctl disable ddccontrol.service 
The unit files have no installation config (WantedBy=, RequiredBy=, UpheldBy=,
Also=, or Alias= settings in the [Install] section, and DefaultInstance= for
template units). This means they are not meant to be enabled or disabled using systemctl.
 
Possible reasons for having this kind of units are:
• A unit may be statically enabled by being symlinked from another unit's
  .wants/ or .requires/ directory.
• A unit's purpose may be to act as a helper for some other unit which has
  a requirement dependency on it.
• A unit may be started when needed via activation (socket, path, timer,
  D-Bus, udev, scripted systemctl call, ...).
• In case of template units, the unit is meant to be enabled with some
  instance name specified.

@kookie @pyrignis Thanks for reporting, testing and confirming this issue.

[kookie]

Thanks everyone for the hard work getting this resolved. Now just waiting for the PR and a new build so I can rebase.

[rvsmooth]

This change does indeed seems to fix the issue.

hey can u try layering ddcutil package and check if any issues occur ? ddcutil appears to be different compared to ddccontrol and yet it provides brightness control.