Tachyon HDMI output oddity

Tachyon
2

Hey Anthony,

Thanks so much for writing in and taking the time to document your experience - we really appreciate it. You’re absolutely right that HDMI output on Tachyon can be finicky, and it’s one of the top issues on my radar at the moment. It’s frustrating because for a large number of users it works just fine, but there’s definitely a cold boot problem and some strange behavior depending on how the board is powered and what’s connected at boot.

I wanted to be transparent and share what we believe is going on behind the scenes, because it’s actually pretty interesting (if a bit annoying in practice).

What we’ve observed is a combination of two things:

  1. GDM3 and Display Detection: When GNOME starts via GDM3, it checks for a connected display. If the display hasn’t enumerated yet, as is the case when USB-C hasn’t fully initialized, GNOME can “give up” early. GDM3 starts, but it doesn’t wait correctly for the display subsystem to come online, so no output appears.

  2. USB-C Timing and Role Switching: The USB-C port on boot defaults into a charging role, and only later performs a USB bus reset, switches roles to become a host, negotiates alt modes, and finally configures itself as a DisplayPort output. That sequence introduces a race condition with the display manager - if GNOME checks too early, it misses the window when the display becomes available.

You can stop/start gdm3 (systemctl restart gdm) and it pops up with the display each time when everything is stable. That suggests there is a work around timing wise, but… we’ve been trying to debug this still. There’s clearly a bug or fragile timing interaction somewhere in the stack, and it’s proven extremely tricky to track down before we give up and ‘work around’ it.

That said, there is a workaround we’re testing internally: enabling a virtual display at boot. This tricks GNOME into starting up correctly regardless of what’s connected, and once GNOME is running, we use a script to detect when the real HDMI display (DP1) has enumerated and then disable the virtual display automatically. So far in testing, that seems to eliminate the race condition without leaving a phantom desktop hanging around.

This workaround of the virtual display was removed earlier because the virtual display would show up in desktop settings and could be confusing - dragging windows onto a non-existent screen isn’t great UX, but we’re now leaning toward re-enabling it with the proper cleanup script.

This is all on Ubuntu 20.04.

Anyway, I hope that background is helpful - and again, thank you for sharing your insight. I’m really glad you spotted that power-init dependency; it lines up exactly with what we’re seeing. If you have any other observations or thoughts, I’d love to hear them.

Thanks again for the collaboration,

Nick

2 Likes