DGX Spark HDMI Display Stops Working Every

Accelerated Computing DGX Spark / GB10 User Forum DGX Spark / GB10
1

Hi everyone,

I’m experiencing a persistent HDMI display issue with my DGX Spark that’s becoming a major problem. Looking for help troubleshooting this before I lose important work or return my device within the 30 day window (coming up soon!).

The Problem:

  • HDMI output stops working randomly every 1-2 days

  • Screen goes black, no signal to monitor

  • System is still running (can hear it’s on, but can’t see anything)

  • Hardware Keyboard(s)/mouse input doesn’t wake the display

  • Happens even when I’m actively running overnight processing jobs

What I’ve Already Tried:

  • ✓ Unplugging/replugging HDMI cable multiple times

  • ✓ Tested with different HDMI cables

  • ✓ Tried connecting through HDMI switcher (preferred method)

  • ✓ Tried connecting directly to monitor (same issue persists)

  • ✓ Disconnected and reconnected keyboard

  • ✓ Pressed Escape, Enter, random and many keys.. moved mouse constantly - no response

  • ✓ Attempted SSH connection via Ethernet (couldn’t establish connection and gave up shortly after but ssh shouldn’t be needed and I don’t want a headless server anyway..)

  • ✓ Checked monitor with other devices (Mac Mini, Windows PC) - monitor works perfectly

Why I Believe It’s NOT a Hardware Issue:

  • The moment I force restart the DGX Spark, HDMI works immediately - no cable swapping needed, just press the power button and display comes right back

  • Same setup works flawlessly with my Mac Minis (2 different ones), Windows machine, and MacBook Pro laptops - never had this issue once with any of those.. over years..

  • This only happens with the new DGX Spark

  • I’ve plugged directly into the monitor and still get the same issue (though I normally prefer using my HDMI switcher)

Hardware Setup:

  • Monitor: Raven MTI (2022) - zero problems in 2+ years of use

  • HDMI Switcher: www.amazon.com/dp/B0DHXP11YB (always worked flawlessly)

  • HDMI Cables: www.amazon.com/dp/B091GWJPJ5 (worked flawlessly on all other devices)

  • All of this hardware has been tested extensively with multiple machines without a single issue

My Concerns:

  • I’m running long processing jobs overnight that I can’t afford to lose

  • Even if I’m not running long processing jobs overnight, and have only a browser or terminal open.. if I step away even for a couple hours and come back, sometimes I’m forced to restart it!

  • Can’t force restart without losing all my work and progress

  • This happens regularly (every other day, sometimes every day) making the system unreliable

  • No SSH access set up, so I’m locked out when display fails. And refuse to use my DGX Spark as a headless device anyway.

Questions:

  1. Is this a known display manager bug in Ubuntu on DGX Spark? I’ve fully updated and have even reset the device according to the NVIDIA Recovery Guide once (System Recovery — DGX Spark User Guide)

  2. How do I prevent the screen from blanking/sleeping permanently? (FYI I’ve asked AI and have followed along the GUI System Settings to changed a few option to not turn off the screen/monitor)

  3. Any other recommendations?

  4. Do I have a lemon?

System Info:

  • DGX Spark (native Ubuntu version that came with the system)

  • Connected via HDMI

  • USB-C Keyboard. (have used several and bought a new one, to no avail: RK ROYAL KLUDGE R75)

  • Bluetooth Mouse: Anker 2.4G Wireless Vertical Ergonomic Optical Mouse

  • Screen: Steven Slate Audio Raven MTi (Only monitor since 2021/2022)

Has anyone else experienced this? Any solutions that don’t involve force restarting?

Thanks in advance!

2

This is important: “this hardware has been tested extensively with multiple machines without a single issue.”

So is this: “No SSH access set up”

Shell access once the display, keyboard and mouse have become non-responsive is your only hope for directly diagnosing and correcting this problem. I can’t stress this enough. For example, I use Barrier to share my mouse and keyboard across all the Linux systems running in my office, including my DGX Spark (which is now running native Cinnamon Desktop, btw, because this matches my other desktops.) The Barrier server runs on my daily driver with all the other systems being clients. Everytime I update my DGX Spark and it reboots, this causes a malfunction in Barrier which “breaks” my daily driver’s keyboard and mouse – they become non-responsive – with all my daily applications open and being distributed across four desktop “workspaces.” The first time I encountered this, I ssh’d in and restarted the Cinnamon desktop, which worked, but it’s kind of a PITA because you then have to go from desktop to desktop reopening and cleaning up the placement of all the windows. The next time, all it took to gracefully recover from this situation, from another system, was the following:

ssh carlh@hostname
ps ax | grep barrier
sudo kill -9 430795 430812
exit

This releases Barrier’s “death grip” on my daily driver’s mouse and keyboard. It’s easy enough to re-launch Barrier once the DGX Spark system is back online. Now, I simply use the menu in Barrier to shut it down on all of my systems whenever one of them needs to be rebooted.

My recommendation would be to set up ssh key authentication between your DGX Spark and at least one other system to make diagnosing the problem possible when this issue strikes. (It could be something as simple as having inadvertently allowed the DGX Spark’s default Power Management settings to conflict with some other such configuration, e.g. screen locking, or a screensaver, etc..)

3

Hi @carlh

Thanks for your reply.

However, I’m running “out of the box” Ubuntu and didn’t make any major changes to the system. (unlike your Cinnamon desktop and Barrier (which you state causes your keyboard/mouse malfunction issue).

For ‘out of the box, DGX Spark’, I shouldn’t have any major, persistent, issues, esp when it’s HDMI related.. Esp not for a $4k machine with dedicated mouse and keyboard.

I’ll look into SSH and troubleshooting via terminal later (I guess I’ll ask AI how to go about that, to determine what the issue is, once I’ve established SSH* connection remotely).

Any others having the same or similar HDMI issue I’m currently having?

Thanks!

1 Like
4

You’re welcome! :)

My example was only meant to illustrate how seamless and convenient ssh key authentication can be when you are administering multiple systems. Once this has been set up, and it should only take about five minutes per machine, you can avoid resorting to potentially catastrophic “hard resets” of your DGX Spark.

To begin, the DGX Spark has power management enabled by default. After some period of time of inactivity, DPMS instructs the display to enter sleep, standby, or power-off modes. Once in these “deep sleep” states, the display can fail to wake up even with keyboard or mouse input, ditto when you try turning the display off and back on, ditto when you try unplugging the display cable and plugging it back in, and so on. While the system remains functional (accessible via SSH,) the display simply refuses to wake and peripherals become non-responsive.

Since you’ve already tried (and fortunately documented here) all of the obvious tests, including directly connecting the display and had the problem recur, this strongly suggests (at least to me) that this is /not/ a problem unique to the DGX Spark, but one that is actually encountered quite frequently when mixing ad hoc hardware and software produced in different years by different manufacturers. :) [Just so you know, I’m a seasoned (40+ years) electronics engineering technician by training (Heald Engineering College S.F.) and I have seen – and solved – this exact scenario many times before. All it takes is a single obscure and seemingly insignificant setting to cause the graphics subsystem to lose track of the display’s state and there you go …]

Here is all that you’ve written in this area: “(FYI I’ve asked AI and have followed along the GUI System Settings to changed a few option to not turn off the screen/monitor)”

My guess is you have missed something here, and, I only suspect this because I have done the exact same thing myself. :) You think you’ve got everything set and you walk away, but when you return the display is off … again … expletive deleted! :)

Rather than performing all of this work the “old school” way, I /did/ employ AI to help me write this part:

There are at least six possible configuration points that you need to check:

[Note: Please do not follow any of these instructions without first researching them on your own so A) you understand what they do and B) you know how to back any changes out if you decide that’s what you want to do so.]

  1. GNOME Settings GUI - Power

Navigate to Settings → Power → Screen Blank and set it to “Never”. This controls the graphical desktop environment’s screen blanking behavior.
​
2. GNOME Settings GUI - Privacy & Security

Go to Settings → Privacy & Security → Screen Lock. Configure:

Blank Screen Delay: Set to “Never”

Automatic Screen Lock: Disable or set to “Off”

These two GUI locations control different aspects and can conflict with each other.

  1. gsettings (Command Line - Session Idle)

The GNOME desktop session idle timeout must be configured separately:

bash

gsettings set org.gnome.desktop.session idle-delay 0

Setting this to 0 disables the idle timeout entirely. This is distinct from the GUI settings and may override them.

  1. gsettings (Command Line - Power Plugin)

The GNOME settings daemon power plugin has its own idle settings:

bash

gsettings set org.gnome.settings-daemon.plugins.power idle-dim false
gsettings set org.gnome.settings-daemon.plugins.power sleep-inactive-ac-timeout 0

The idle-dim setting prevents screen dimming before blanking, while the timeout controls when the system enters sleep states.

  1. X11/Xorg DPMS Configuration

Create a permanent Xorg configuration file to disable Display Power Management Signaling:

bash

sudo tee /etc/X11/xorg.conf.d/90-disable-dpms.conf << EOF

Section “Extensions”
Option “DPMS” “Disable”
EndSection

Section “ServerFlags”
Option “StandbyTime” “0”
Option “SuspendTime” “0”
Option “OffTime” “0”
Option “BlankTime” “0”
EndSection
EOF

Important: GNOME may override Xorg settings at runtime, so you may also need to add this to your startup applications:

​bash

xset s off -dpms
xset dpms 0 0 0

  1. systemd-logind Configuration

Edit /etc/systemd/logind.conf to prevent system-wide idle actions:

bash

sudo nano /etc/systemd/logind.conf

Uncomment and set:

[Login]
IdleAction=ignore
IdleActionSec=infinity
HandleLidSwitch=ignore

Then restart the service (this will terminate your X session, so save your work first):

bash

sudo systemctl restart systemd-logind.service

Or simply reboot for the changes to take effect.

Why So Many Locations?

This complexity exists because Linux display blanking operates at multiple independent layers:

Desktop Environment Layer (GNOME): Manages user-visible settings and session behavior
X Server Layer: Controls the actual display hardware through DPMS
System Layer (systemd-logind): Handles system-wide power management and ACPI events

Each layer can independently trigger screen blanking, and they frequently conflict with each other. GNOME settings may reset Xorg settings within minutes, and different components may respond to different timeout values.
​
Additional Considerations for DGX Spark

Given that the DGX Spark runs Ubuntu on ARM architecture with an NVIDIA Blackwell GPU, you may encounter additional display management quirks specific to this platform. The multiple configuration points become even more important because:

The ARM-based system may have different default power profiles
The NVIDIA driver has its own power management settings that can interact with system-level configurations

KVM switches (as in your setup) add another layer of complexity by potentially losing EDID information during power state transitions

The fragmented nature of Linux power management means that overlooking even one configuration point can result in your display still turning off.

I hope this helps!

3 Likes
5

Thank you. This is the most detailed description of all of the crazy ways that linux tries to idle your display whenever you turn your back on it, and it has been kicking me around my lab on this and other finicky machines for a long time. I was just blaming the KVM switches I use, but there are obviously many more moving parts under the hood…

6

On the default ubuntu OS, without changing any setting I discovered that with the HDMI to USB-C cable and Apple Studio display I was able to keep system on idle for aeound 2 days and keyboard button press woke up the display.

Cable I used : BENFEI HDMI to USB C Cable 6 feet… Amazon.com: BENFEI HDMI to USB C Cable 6 feet 4K@60Hz, Unidirectional HDMI (Source) to USB-C (Display) Adapter for MacBook, Steam Deck, PS5/4, Nintendo Switch, AR/XR, Portable Monitors : Electronics

7

I switched to a usb-c to display port and issue went away. Only happens with my HDMI to HDMI cable.

3 Likes
8

Interesting, thanks! I’ll pick up a usb-C to hdmi cable for when this issue occurs again, and will try this to get the display back on!

9

Update: Last night and after 2.5 days my DGX Spark has been running fine.. Being able to log in and lock screen* per normal use, etc.

This morning, however, ran into the same issue where mouse and keyboard doesn’t wake the screen* and HDMI is unresponsive.

I’m waiting for a USBC-HDMI cable I ordered (thanks to input in the forums here!) but I’m assuming It’s probably not plug and play and I’ll have to download and set up drivers beforehand. Anyways, will update regardless, even if I need to force restart to setup drivers!

Cheers!

10

Are all those symptoms with or without the HDMI switcher?

11

If the problem happens again, could you please see if you can at least ping the system on the network? Please also run sudo nvidia-bug-report.sh to capture a bug report log and attach it here (or email it to [email protected] and give us a heads up about it here). It’s okay if you have to do that after force-rebooting the system. If you do reboot, it would also be a good idea to collect the complete output of sudo journalctl -b -1 to get the full system log of the boot where the problem occurred.

If you can SSH into the system while the display isn’t working, then there are a few additional things you could try.

1 Like
12

Both with and without the HDMI switcher– my monitor reads “No Signal Input”.

I’ll even try to unplug HDMI cable completely and reconnect (both from monitor and DGX Spark) and make sure it’s firmly in place–in attempt to see if a ‘reconnection of an HDMI cable’ would somehow wake the DGX Spark’s HDMI output– and get it displaying again.. but that hasn’t worked, even once.

13

Thanks,

I’ll try in a day or so after my processing has completed. (I’m running a program that takes a few days to complete, and it doesn’t use more than a few cpu cores, so it’s not like I’m maxing out the thing..). Anyway, when I feel the DGX Spark fan and the temperature has gone down, I’ll know it’s complete so I don’t lose work.. Then, I’ll force reboot it and try a few of these extra steps, and report back!

14

This being a DGX Spark treat it like a sever and not a NUC. When the display is off the system is awake for sure. There’s no way to sleep it! When it happens again use SSH to login and run xset dpms force on and force the display to light-up.

15

Update:

USB-C to HDMI cable arrived.. I plugged it in since the standard HDMI has been unresponsive for a couple days or so and my DGX Spark is still on for about 5 days now.. But, nothing showed up on the display. Mouse and keyboard activity do nothing to help re-activate display.

.. Interestingly enough; after I force rebooted the DGX Spark–the USB-C to HDMI did indeed work “plug and play” without having to install any drivers. USB-C to HDMI cable worked as well and as if it were an HDMI directly plugged in. I even saw the startup screen, etc. (FYI).

…

Further, I’ll report back after some more testing (ssh and other settings changes, as mentioned here, and with further research). Although again, I’m coming up on my 30 days before I can return the DGX Spark (if this Display Issue isn’t resolved)— so my troubleshooting and debugging time is limited.

Cheers.

16

If you still do not see anything on your monitor can you try running these commands to see if they help?
sudo init 3 - runlevel 3, may show a commandline on the monitor after running
systemctl start gdm gnome-remote-desktop cups cups-browsed - desktop related services which may not be running. Can also run systemctl stop gdm gnome-remote-desktop cups cups-browsed to see if these services are failing somewhere

17

Hey, the “sudo nvidia-bug-report.sh” command spewed out a ton of data (several lines of warnings/errors per second–it seems like, for days in a row..).

I’m open to sending a bug report that’s more mild/truncated and reviewable. So, could you suggest a modified version of that bug report, or a follow-up command that filters out information you’d need?

Thanks for your recommendations and help here.

18

Just to be clear on my expectations (and I know I’ve said it before):

I intentionally bought the $4k DGX Spark to be an all-in-one, plug-and-play mini AI workstation that I can just sit down and use — not a headless server I have to SSH into every time the desktop throws a tantrum. Relying on SSH as the “solution” feels like a workaround for something that shouldn’t be broken in the first place, and it also adds a security surface I’d rather not have open on my desk machine.

I genuinely appreciate everyone’s help and patience — you’ve been awesome. I’ve already implemented much of what @carlh offered btw, before opening this thread). And I’m going to run it hard for a few more days and see if it stays stable-- but the amount of troubleshooting time this thing has already eaten is getting pretty ridiculous, and my 30-day return window closes next week.

If nothing else, hopefully this thread saves the next dozen people the same headache, or provides a lead to future users who don’t mind spending the time to get this thing up and running smoothly (assuming they have similar issues as mine). Or, to at least manage expectations about SSH & it’s possibility as a reliable solution (unacceptable in my circumstance, however).

Thanks again, seriously. I’ll follow up again, later.

19

Wow, what a shame! :( I really hope you get this issue resolved so you can keep it! [Note to NVIDIA Customer Suport: If urmom69 /does/ unfortunately decide to send it back, I would like first dibs on purchasing it, assuming it checks out okay!]

I was just thinking, yesterday, how much I am enjoying having my shiny new DGX Spark finally fully integrated into my network, workspace and workflow.

I bought a beautiful 32" Samsung 4K display for it which is angled right next to my daily driver’s 43" 4K LG display. On the other side sits my trusty little rescue laptop (accepted as a gift and refurbished – new keyboard, display, SSD, WiFi adapter – to keep it from going to the dump) with an equally old and trusty (still good as new) 19" FHD (1080p) AOC display. Each system has it’s own wireless keyboard + mouse combo, but I use Barrier (e.g. Share mouse and keyboard between computers with Barrier) so the keyboard and mouse on my daily driver act as the server with the other combos remaining connected and available as a fall-back. This arrangement works seamlessly because all three systems, including the DGX Spark, are running Cinnamon Desktop (“inspired” according to Wikipedia by GNOME 2 and I remember this very painful transition.) I have /never/ been able to use GNOME 3 for legitimate, facts based reasons which fall outside the scope of this post.

Barrier makes copy / paste possible between systems – obviously text or links only desktop to desktop – but this is highly useful. Read further down to learn how seamless and easy network-wide filesystem access can be.

Although the DGX Spark ships with stock GNOME, you can, and I did, easily, install the stock Cinnamon Desktop as an alternative. (https://greenwebpage.com/community/how-to-install-cinnamon-on-ubuntu-24-04/) These two DEs coexist peacefully, and they do /not/ interfere with each other at all. At the login greeter, you gain the option to select to sign into either DE because they are completely separate and installed in parallel. In the overall scheme of things, this arrangement does not consume very much storage space, at all, and having a truly unified desktop environment across all of my networked systems allows the OS and DE to mostly fade into the background so I can focus on my work. :)

I do virtually all of my work on my daily driver, where I have dedicated an entire workspace (virtual desktop) for use exclusively with my DGX Spark – up to sixteen workspaces / virtual desktops are supported natively, but I seem to always max out at six. YMMV.

Because I’ve enabled ssh key authentication and configured it across all of my systems, nemo (Cinnamon’s default file manager) “sees” and offers links for instant access to the other systems’ filesystems. Full CRUD operations work seamlessly in addition to copy & paste.

I also have one-click instant terminal access to the DGX Spark from the other systems, as well as one-click instant access to the DGX Dashboard (tunneled at http://localhost:11000)

I have Ollama running in the background under Docker on the DGX Spark alongside a directly installed LM Studio, and, I have Open WebUI running under Docker on my daily driver (this conserves memory on the DGX Spark). I have set up one-click instant access to these resources as follows:

Ollama is tunneled at http://localhost:11434

Open WebUI is not tunneled at http//localhost:8080 on my daily driver

LM Studio is accessed in two ways:

a. lms-cli via terminal
b. model selection is available through Open WebUI via a “Connector”
(http://spark-xyza:1234/v1) created under Settings > Connections in Open WebUI.
(enabling this endpoint in LM Studio is straightforward in the settings.)

I have yet to dive into “jupyterlab” but am confident that it will “just work” and be accessible at http://spark-xyza:11002* (*user ports can be found via terminal using ‘cat /opt/nvidia/dgx-dashboard-service/jupyterlab_ports.yaml’)

I have not experienced a single “screen blanking” + non-responsive keyboard / mouse issue since going through the settings that I enumerated earlier in this thread. My new Samsung display is connected directly using the new HDMI<>HDMI cable supplied with the display.

I wish you the best of luck, urmom69, and my fingers are crossed that you are able to keep and enjoy your DGX Spark!

regards,

Carl

20

Thanks,

I’m not sure how most of that^ is useful to debugging and problem solving my DGX Spark’s monitor/display matter.. Again, I’m not willing to use SSH as a bandaid-workaround for these issues.

–

Btw I’m open to buying another one later, if I need to send it back.. I’m under the assumption that this DGX Spark might be a “lemon” if these last little system tweaks I made don’t “fix” it.

So, I dunno if I’d recommend snagging it @carlh.. But, like you’re suggesting–if it “checks out ok”, go for it.. I’m open to the idea that these issues are a symptom of “user error”, or me missing something, otherwise..

Again, will report back, by the end of this coming week, re: if this thing acts up again or not.

P.S. I’ve tried another display, as well, so I’m ruling my specific, primary monitor, out.