没有不值得去解决的问题,也没有不值得去学习的技术!

Troubleshooting a Sudden Black Screen on Dual Monitors With Ubuntu 26.04: A ThinkPad T570 Case Study

Figure 1: Ubuntu 26.04 main screen working normally, but the Samsung secondary display has gone completely black

作者:

My ThinkPad T570 has always been connected to an old Samsung 22-inch monitor as a secondary display.

This monitor only has VGA input, and the ThinkPad T570 itself lacks a VGA port, so I previously used the following setup:

Plaintext
ThinkPad T570 HDMI

HDMI → VGA adapter

VGA cable

Samsung 22" monitor

to connect them.

This setup had been working normally for a while, with the secondary display running at:

Plaintext
1920 × 1080
60 Hz
100% scaling

In April 2026, I actually documented the configuration process for this dual-screen setup once before.

The problem back then was that Windows had already detected both monitors, but the VGA secondary display showed no picture. In the end, I found the real cause to be very simple: the VGA monitor’s cable was not properly connected.

Therefore, when the secondary display went black again this time, my initial suspicion naturally was that a similar issue had occurred with the cable, port, or adapter.

For reference, the previous troubleshooting practice can be found here:

ThinkPad T570 Dual Screen: Previous Configuration and Troubleshooting Practice

However, the problem this time was clearly much more complex.

1. Issue Occurs: Just Moved the Position, Secondary Display Suddenly Goes Black

The current system is Ubuntu 26.04.

Both screens had been working normally, but after I slightly moved the laptop and the Samsung secondary display, the secondary screen suddenly went completely black.

The laptop’s built-in screen worked perfectly, while the Samsung secondary display showed no desktop image at all.

Figure 1: Ubuntu 26.04 main screen working normally, but the Samsung secondary display has gone completely black
Figure 1: Ubuntu 26.04 main screen working normally, but the Samsung secondary display has gone completely black

My first reaction was naturally:

  • Loose HDMI or VGA port;
  • Poor contact with the HDMI→VGA adapter;
  • Ubuntu display configuration changed;
  • GNOME Wayland multi-monitor anomaly;
  • Intel i915 graphics driver issue.

So I began troubleshooting layer by layer.

2. The Strange Thing: Ubuntu Still Thinks the Secondary Display is Connected Normally

First, I went to:

Settings → Displays

I found that Ubuntu did not consider the Samsung to be disconnected.

The system could still see:

Plaintext
1 Built-in display
2 Samsung Electric Company 22"

And it was still in “Join” mode, which is the extended desktop mode.

Figure 2: Although the Samsung secondary display is actually black, Ubuntu still fully recognizes both monitors
Figure 2: Although the Samsung secondary display is actually black, Ubuntu still fully recognizes both monitors

This meant the problem was not the simplest case:

Ubuntu fails to detect the second monitor.

Next, I checked DRM while the secondary display was black:

Bash
echo "========== 当前 DRM 接口状态 =========="
for f in /sys/class/drm/card*-*/status; do
    [ -f "$f" ] || continue
    printf "%-55s " "$f"
    cat "$f"
done

echo
echo "========== 最近 10 分钟显示相关内核日志 =========="
journalctl -b -k --since "10 minutes ago" --no-pager \
    | grep -Ei 'i915|drm|hdmi|displayport|dp-|edid|connector|hotplug|link|crtc|pipe|fail|error|timeout'

The most crucial result was:

Plaintext
/sys/class/drm/card1-HDMI-A-2/status    connected

The secondary display was clearly black, but the Linux kernel still considered the HDMI display device to be connected.

At the same time, the following appeared:

Plaintext
workqueue: i915_hotplug_work_func [i915] hogged CPU for >10000us

And:

Plaintext
i915 0000:00:02.0: [drm] *ERROR* Atomic update failure on pipe A

At this point, I briefly suspected an anomaly in the Intel i915 driver or GNOME Wayland’s multi-monitor handling.

3. Further Checks: connected, enabled, and EDID All Normal

Further checking HDMI:

Bash
for f in status enabled modes; do
    echo "--- $f ---"
    cat "/sys/class/drm/card1-HDMI-A-2/$f" 2>&1
done

wc -c /sys/class/drm/card1-HDMI-A-2/edid
sha256sum /sys/class/drm/card1-HDMI-A-2/edid

Results:

Plaintext
status:
connected

enabled:
enabled

EDID could also be read normally:

Plaintext
256 /sys/class/drm/card1-HDMI-A-2/edid

The system could also identify:

Plaintext
1920x1080
1680x1050
1600x900
1440x900
1280x720
1024x768
……

The desktop environment was:

Plaintext
XDG_SESSION_TYPE=wayland
XDG_CURRENT_DESKTOP=ubuntu:GNOME

In other words, from Linux’s perspective:

The monitor exists, the port is connected, output is enabled, EDID is readable, and resolutions can be identified.

But in the real world, the Samsung monitor remained a black screen.

4. Attempting to Software-Disable and Re-enable the Secondary Display

The next step was to directly disable the Samsung secondary display in GNOME display settings.

Figure 3: Disabling the Samsung secondary display in Ubuntu display settings and preparing to apply the new display configuration
Figure 3: Disabling the Samsung secondary display in Ubuntu display settings and preparing to apply the new display configuration

After applying it, only the laptop’s built-in screen remained in the layout.

Figure 4: After turning off the Samsung secondary display, GNOME currently only enables the built-in monitor
Figure 4: After turning off the Samsung secondary display, GNOME currently only enables the built-in monitor

Then I turned Samsung back on.

Theoretically, this forces GNOME to actively reconfigure the display output once.

But the result still showed no improvement.

The secondary display remained black.

Therefore, the problem no longer seemed to be a simple case of:

GNOME display state is stuck.

5. Samsung Self-Test Normal, Display Panel is Not Broken

Next, I pressed the Samsung monitor’s own menu button.

The display lit up normally and showed:

Plaintext
TEST GOOD
Figure 5: Samsung monitor successfully completes the TEST GOOD self-test, indicating that the panel, backlight, and basic display functions are still normal
Figure 5: Samsung monitor successfully completes the TEST GOOD self-test, indicating that the panel, backlight, and basic display functions are still normal

This test is very important.

Because the OSD and TEST GOOD screen are generated by the monitor itself, they do not depend on Ubuntu or the HDMI→VGA adapter.

Therefore, it can at least be confirmed that:

  • The monitor receives power normally;
  • The backlight is normal;
  • The LCD panel is normal;
  • The monitor itself can generate an image.

But it should be noted:

This only proves that the monitor itself can work; it does not prove that its VGA input circuit is necessarily normal.

6. The Problem Starts Pointing to the HDMI→VGA Conversion Chain

My actual connection is not HDMI directly to the Samsung.

Instead, it is:

Plaintext
ThinkPad HDMI

Acer HDMI→VGA adapter

VGA cable

Samsung
Figure 6: ThinkPad T570 currently uses an Acer HDMI→VGA adapter to connect to the Samsung secondary display, which only supports VGA input
Figure 6: ThinkPad T570 currently uses an Acer HDMI→VGA adapter to connect to the Samsung secondary display, which only supports VGA input

I then successively tried:

  • Replugging the HDMI on the ThinkPad side;
  • Replugging the adapter;
  • Replugging the VGA;
  • Completely powering off the Samsung and restarting it;
  • Normal Ubuntu restart;
  • Full shutdown for tens of seconds before restarting.

None of these worked.

However, a very interesting phenomenon occurred during troubleshooting:

When replugging the ports near the adapter, the Samsung would occasionally show a normal picture briefly.

This meant the video signal was not entirely absent, but rather:

It could be established, but not stably maintained.

7. After Lowering the Resolution, the Problem Changes

Next, I tried lowering the Samsung’s output resolution.

The original:

Plaintext
1920 × 1080 @ 60Hz

was basically always black.

Changed to:

Plaintext
1280 × 720 @ 60Hz

The secondary display actually lit up briefly once.

But it quickly went black again.

Then I continued lowering it:

Plaintext
1024 × 768 @ 60Hz

This time it was able to display, and at first it could hold for a while.

Figure 7: After lowering to 1024×768, the Samsung secondary display temporarily restored the Ubuntu desktop image
Figure 7: After lowering to 1024×768, the Samsung secondary display temporarily restored the Ubuntu desktop image

So I found a very strange pattern:

Plaintext
1920×1080 → mostly black screen

1280×720 → briefly lights up, then black screen

1024×768 → worked for a while, but still flickered

More importantly, 1024×768 did not actually solve the problem.

It merely:

made it easier to maintain the signal.

8. Screen Recording: 1024×768 Still Has Random Flickering

To document the problem more intuitively, I recorded a video.

Even after lowering to 1024×768, the Samsung was only “barely usable”; during actual operation, it would still randomly go black, flicker, and then recover.

Insert Video 1 here: 108(1).mp4

Video 1: Even when lowered to 1024×768, the Samsung secondary display still experiences random black screens and recoveries

This phenomenon made me basically abandon the explanation:

It’s just a wrong 1920×1080 resolution setting

Because if it were simply an incompatible 1080p parameter, switching to a working 1024×768 should theoretically remain stable.

But that was not the case.

9. 1920×1080 Itself is Still a Normal Mode Recognized by the System

Later, I set the Samsung back to 1920×1080.

GNOME could still display normally:

Plaintext
Resolution: 1920 × 1080
Refresh rate: 59.94 Hz
Scaling: 100%
Orientation: Landscape
Figure 8: GNOME can still configure 1920×1080, 59.94Hz, and 100% scaling for the Samsung
Figure 8: GNOME can still configure 1920×1080, 59.94Hz, and 100% scaling for the Samsung

This point is very important.

Because this monitor had been working normally at 1080p for a long time.

So the problem was not:

Whether this monitor or this setup supports 1920×1080.

The answer is clearly yes.

The real question should be:

Why can the chain that previously transmitted 1080p stably no longer work stably?

10. Suspecting a Link to a Previous Abnormal Power Outage

During troubleshooting, I thought of something else.

My ThinkPad T570 currently has no battery and relies entirely on AC power.

Previously, I had accidentally unplugged the laptop’s power.

After the computer instantly lost power, reconnecting AC power once made it unable to boot properly.

The behavior was:

Plaintext
Press power button

Power light stays on for a while

Turns off automatically

Cannot boot

Finally, I had to:

Plaintext
Unplug all peripherals

Press and hold the power button

Reconnect power

Only then did the computer return to normal.

And this Acer HDMI→VGA adapter itself does not have a separate power cable.

So I also briefly suspected:

Could an anomaly in the HDMI output or the adapter’s power state have occurred after an abnormal power outage?

So I further performed a ThinkPad Emergency Reset.

11. Performing T570 Emergency Reset

The ThinkPad T570 has an Emergency-reset hole on the bottom.

Figure 9: ThinkPad T570 bottom structure; an Emergency Reset was further performed during troubleshooting
Figure 9: ThinkPad T570 bottom structure; an Emergency Reset was further performed during troubleshooting

The procedure is:

Plaintext
Shut down Ubuntu normally

Unplug AC power

Unplug HDMI, USB, and other peripherals

Use the Emergency-reset hole to reset

Wait

Connect only AC power

Turn back on

Connect the secondary display after entering Ubuntu

But the result still showed no improvement.

Even by the next day, the previously barely working:

Plaintext
1024×768

could no longer display stably either.

This basically ruled out the explanation:

It’s just a temporary power state that wasn’t reset

.

12. Checking GNOME’s monitors.xml

Because GNOME’s behavior for the display layout differed between 1024×768 and 1920×1080, I began to suspect the display configuration file.

Checked:

Bash
ls -l ~/.config/monitors.xml

sed -n '1,240p' ~/.config/monitors.xml

The configuration was actually very simple.

What was saved at the time was:

Plaintext
Built-in screen eDP-1
1920×1080
primary=yes

Samsung HDMI-2
1024×768

And the Samsung was located to the left of the built-in screen.

No historical configuration duplication, primary monitor conflict, or obvious corruption was found.

13. Using gdctl to Check Mutter’s Real-time Status

Further executed:

Bash
gdctl show --verbose

The results showed that Samsung was correctly identified as:

Plaintext
Vendor: SAM
Product: S22D300

Its preferred mode was still:

Plaintext
1920×1080 @ 60.000

And when testing 1024×768, Mutter even explicitly showed:

Plaintext
1024×768 @ 60.004
is-current ⇒ yes

In other words:

GNOME/Mutter already considered the display mode successfully applied, but the actual physical monitor still had no stable image.

At this point, the possibility of “just an Ubuntu display configuration error” had clearly decreased.

14. Capturing i915 hotplug Logs Again

Then I monitored i915 in real time:

Bash
sudo journalctl -kf --no-pager \
  | grep --line-buffered -Ei 'i915|drm|hdmi|hotplug|atomic|connector|crtc|pipe|link|edid|fail|error|timeout'

While continuing to modify display modes, the following appeared again:

Plaintext
workqueue: i915_hotplug_work_func [i915] hogged CPU for >10000us

And the count was still increasing.

This meant that Intel i915 was still repeatedly processing monitor hotplug-related work.

Combined with all the previous phenomena:

Plaintext
System can always identify Samsung

EDID normal

GNOME can set display mode

Mutter thinks output has taken effect

Real monitor has no stable image

Replugging ports occasionally recovers it

Lowering resolution was slightly stable once

i915 constantly processes hotplug

The fault increasingly looked like:

The display chain itself is already in an unstable state.

15. Why Was 1080p Normal Before?

This was the most confusing question throughout the whole process.

If HDMI→VGA inherently could not output 1080p stably, then this setup should not have worked properly from the start.

But in reality, it had been working normally for months.

So the more reasonable understanding now is:

Plaintext
Before:

ThinkPad HDMI

HDMI→VGA

VGA

Samsung

Signal margin sufficient

1920×1080 stable

And now:

Plaintext
A certain link in the chain changes state

1080p cannot be stable

720p only works briefly

1024×768 barely works for a while

Eventually low resolution also starts failing

Possible factors include:

  • Acer HDMI→VGA adapter;
  • VGA cable;
  • Adapter’s VGA output port;
  • Samsung VGA input circuit;
  • ThinkPad HDMI output;
  • HDMI hotplug or power state.

Since I currently do not have spare adapters, VGA cables, or HDMI monitors, it has become difficult to continue cross-validating with existing equipment.

16. Final Decision: Switch to a Different Video Path Directly

Initially, I considered buying another HDMI→VGA adapter.

But that would only replace the adapter itself:

Plaintext
ThinkPad HDMI

New HDMI→VGA

Old VGA cable

Samsung

If it still showed a black screen, I still wouldn’t know whether it was:

the adapter, the VGA cable, the HDMI output, or the Samsung VGA input.

So I finally decided to switch to a completely different video output path.

The ThinkPad T570 also has a USB-C/Thunderbolt 3 port that supports video output.

Therefore, it can be changed to:

Plaintext
ThinkPad USB-C

Type-C → VGA all-in-one cable

Samsung VGA

This way, I can bypass at once:

Plaintext
ThinkPad's original HDMI output path
+
Acer HDMI→VGA adapter
+
Existing VGA cable

Keeping only:

Plaintext
T570 USB-C

Brand new Type-C→VGA all-in-one cable

Samsung VGA input

This is not only a solution but also a very clean cross-validation.

17. Original/Overseas Product Prices Are Not Cost-Effective

I initially looked at Lenovo and Plugable USB-C→VGA products.

Prices ranged from:

Plaintext
$16.95
$19.95
$24.99
$40.99

and up.

Figure 10: Lenovo/Plugable USB-C→VGA product prices; the cost is clearly too high for this troubleshooting validation
Figure 10: Lenovo/Plugable USB-C→VGA product prices; the cost is clearly too high for this troubleshooting validation

For an old Samsung secondary display that still only has VGA input, spending so much money just to troubleshoot a fault is not cost-effective.

Moreover, these are overseas sites, making purchases inconvenient.

18. Finally Purchasing a Type-C→VGA All-in-One Cable on Pinduoduo

Finally, I found a Type-C→VGA all-in-one cable on Pinduoduo.

The page showed:

Plaintext
Price after coupon: 33.9 RMB
Figure 11: Finally purchasing a Type-C→VGA all-in-one cable on Pinduoduo, with a price after coupon of 33.9 RMB
Figure 11: Finally purchasing a Type-C→VGA all-in-one cable on Pinduoduo, with a price after coupon of 33.9 RMB

The page advertised parameters like “4K 60Hz”, but these were not important to me.

The Samsung’s target mode itself is only:

Plaintext
1920×1080 @ 60Hz

The only real concern is:

Whether this cable can allow the T570 to output 1080p stably to the Samsung VGA monitor via USB-C.

And choosing an “all-in-one cable” instead of a “USB-C→VGA adapter + old VGA cable” has an additional benefit:

The old VGA cable is also ruled out.

The new setup ultimately becomes:

Plaintext
ThinkPad T570 USB-C

Brand new Type-C→VGA all-in-one cable

Samsung S22D300

19. Interim Conclusion: Normal System Recognition Does Not Mean the Video Chain is Normal

The most noteworthy part of this troubleshooting is not what cable I ended up buying.

Rather, it is a phenomenon very prone to misjudgment:

The operating system being able to recognize the monitor does not mean the actual video chain is necessarily normal.

This time, it was in this state for a long time:

Plaintext
Samsung correctly identified
connected
enabled
EDID normal
1920×1080 recognizable
GNOME can set display mode
Mutter even shows is-current=yes

But the actual screen:

Plaintext
Black screen

Occasionally lights up

Flickers

Goes black again

So when troubleshooting external monitors, you should at least distinguish between:

Plaintext
Monitor recognition

Desktop display configuration

Graphics card output

Video port

Adapter

Cable

Monitor input circuit

Final panel display

The system being able to recognize EDID only proves that part of the chain is still working.

It does not prove that the actual video signal has successfully and stably reached the monitor.

20. Next Step: Wait for the Type-C→VGA Cable to Arrive for Final Verification

Currently, no real conclusion can be drawn about this fault.

In particular, I cannot state right now that:

The Acer HDMI→VGA adapter is broken.

Existing evidence only shows that:

The original HDMI→VGA display chain can no longer work stably.

The real next step is to wait for the newly purchased Type-C→VGA all-in-one cable to arrive.

Then I will directly connect:

Plaintext
T570 USB-C

New Type-C→VGA all-in-one cable

Samsung

And test:

Plaintext
1920×1080
60 Hz
100% scaling

If it can work stably long-term, then the problem can basically be confirmed to be on the original:

Plaintext
HDMI output
/
HDMI→VGA adapter
/
VGA cable

side.

If the brand new USB-C→VGA path still shows a black screen or flickering, then the focus of the next phase of investigation will clearly shift to:

Plaintext
Samsung VGA input circuit

or even the monitor itself.

For now, I’ll stop here.

Once the new cable arrives, I will continue verifying.

需要长期技术维护或远程问题排查?

我是拥有 15+ 年经验的 PHP / Go 后端工程师,长期关注已有系统维护、Bug 修复、性能优化、服务器排查、WordPress 网站维护和小功能迭代。

如果你的项目遇到以下情况,可以先从一次小问题排查开始合作:

  • ✅ PHP / Laravel / Yii2 老项目无人维护
  • ✅ Go / Gin 后端接口需要排查或优化
  • ✅ WordPress 网站访问慢、报错或插件冲突
  • ✅ Nginx / MySQL / Redis / Linux 服务器异常
  • ✅ CDN / Cloudflare / DNS / HTTPS 配置问题
  • ✅ 需要长期远程技术支持或兼职维护

更多介绍请查看:关于我 & 合作

微信:13980074657
邮箱:shuijingwanwq@gmail.com
Telegram:@shuijingwan
GitHub:https://github.com/shuijingwan

评论

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注

这个站点使用 Akismet 来减少垃圾评论。了解你的评论数据如何被处理