Screen turns black on boot if connected to external monitor

I’m turning an old laptop into a “desktop” of sorts. I connected an external monitor to the HDMI port, which I plan to use the laptop exclusively through.

If I connect the external monitor to the already booted up system, everything works fine. The problem is when I turn the system on with the monitor previously connected. Then the screen turns black and the boot process seems to halt.

Any ideas?


The laptop has intel graphics and I’m currently using GDM as rhe sessions manager. I’m assuming the problem is opensuse-specific, since grup shows up in the external monitor just fine, as well as Windows.

What does inxi -GSaz run from within a Gnome session report after connecting the external display post-boot?

How far into the boot process does it turn black? Do you get a Grub menu first? If yes, strike the E key, remove quiet and splash, then proceed to boot. Do you see messages that constitute clues?

After display turns black, and waiting a minute or more, does Ctrl-Alt-F3 produce a login prompt?

Nothing at first, but if I press Ctrl+Alt+Del to tell it to reboot, this happens:

Looks like a faulty driver to me.

After seeing this, I added the “nomodeset” option to the linux line and now I get the splash screen and gdm (though I’m unable to start either a gnome session or a plasma one).

I repeat: What does inxi -GSaz run from within a Gnome session report after connecting the external display post-normal-boot?

It might be, but it might be GDM-triggered. Nomodeset’s value is primarily collecting data and implementing repairs. Gnome and Plasma both require functionality that nomodeset blocks.

System:
  Kernel: 6.9.6-1-default arch: x86_64 bits: 64 compiler: gcc v: 13.3.0
    clocksource: tsc avail: hpet,acpi_pm
    parameters: BOOT_IMAGE=/boot/vmlinuz-6.9.6-1-default
    root=UUID=37b5cdc3-d191-4056-a4f7-b16a66b21ee3 splash=silent
    mitigations=auto quiet security=apparmor
  Desktop: GNOME v: 46.2 tk: GTK v: 3.24.42 wm: gnome-shell
    tools: gsd-screensaver-proxy avail: xscreensaver dm: GDM v: 46.2
    Distro: openSUSE Tumbleweed 20240627
Graphics:
  Device-1: Intel 3rd Gen Core processor Graphics vendor: ASUSTeK Zenbook
    Prime UX31A driver: i915 v: kernel arch: Gen-7 process: Intel 22nm
    built: 2012-13 ports: active: HDMI-A-1 off: eDP-1 empty: DP-1,VGA-1
    bus-ID: 00:02.0 chip-ID: 8086:0166 class-ID: 0300
  Device-2: Chicony USB2.0 HD UVC WebCam driver: uvcvideo type: USB rev: 2.0
    speed: 480 Mb/s lanes: 1 mode: 2.0 bus-ID: 2-1.5:3 chip-ID: 04f2:b368
    class-ID: 0e02 serial: <filter>
  Display: wayland server: X.org v: 1.21.1.12 with: Xwayland v: 24.1.0
    compositor: gnome-shell driver: gpu: i915 display-ID: 0
  Monitor-1: HDMI-A-1 model: Acer EA220QH serial: <filter> built: 2023
    res: 1920x1080 dpi: 102 gamma: 1.2 size: 480x260mm (18.9x10.24")
    diag: 546mm (21.5") ratio: 16:9 modes: max: 1920x1080 min: 720x400
  Monitor-2: eDP-1 model: ChiMei InnoLux 0x1348 built: 2012 res: 1920x1080
    dpi: 173 gamma: 1.2 size: 282x165mm (11.1x6.5") diag: 327mm (12.9")
    ratio: 15:9 modes: 1920x1080
  API: OpenGL v: 4.2 vendor: intel mesa v: 24.1.2 glx-v: 1.4 es-v: 3.0
    direct-render: yes renderer: Mesa Intel HD Graphics 4000 (IVB GT2)
    device-ID: 8086:0166 memory: 1.46 GiB unified: yes display-ID: :2.0
  API: EGL Message: EGL data requires eglinfo. Check --recommends.

I’m not so sure about that, given that the screen goes blank as soon as the splash screen (and, I’m assuming, modesetting) kicks in.

How do we know GDM doesn’t try to start as soon as KMS kicks in?

Try disabling the splash, so that you can see error messages during boot as they occur.

Try booting with a 3 on kernel cmdline and external connected. If you get expected login prompts on the ttys, try logging in on 3 or 4 or 5 or 6 as root and running systemctl isolate graphical. Do you get black, or a GDM login screen, or something else?

As black happens early, this is a wild hunch, but try on a normal boot sans external logging into an X11 session instead of Wayland, so that X11 becomes the default on subsequent login attempts, then try a cold boot with the external connected to see if it makes any difference.

Did you run inxi with the lid closed?

I’m not sure if this means anything, but the same problem happens when I boot up the installation disk.

Yes, as far as I remember.


(I’ll try your suggestions out once I’m done reinstalling the system)

I found out an ugly but effective solution: since this problem happens when there’s an extra display plugged during bootup, I figured that disconnecting the laptop’s builtin display and leaving just the external monitor connected could solve the problem.

So I tried it and it did solve the problem! Now I have essentially a very thin desktop computer, which is exactly what I wanted. The builtin display was in terrible shape anyway, so I’m not losing anything of value.

Of course this doesn’t solve the actual bug, but since I no longer have a problem, I’ll just mark this as solved.

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.