Tachyon HDMI output oddity

[radu7]

I just received my Tachyon board and accessories today and made a curious discovery regarding my particular setup.

I see quite a few people having issues with inconsistent or absent HDMI output when running the Ubuntu Desktop image so I thought I’d share my particular situation in case it helps others or if anyone has any ideas what the actual cause of my issue might be.

When I connected everything per the setup instructions and performed the setup everything went perfectly, but after powering the board off and back on again after the initial image install was completed and logging-in to the desktop I noticed the battery was not charging.

I checked the USB-C power supply connection to the multi-function USB-C hub (both power adapter and hub are the ones that were available as add-ons to the Tachyon kit on KS) and found that it wasn’t actually fully inserted. It took considerable force to actually fully insert the power connection to the hub, more than what I’d consider typical anyway, but not a ridiculous amount.

Once it clicked into place the battery status changed to ‘charging’ and all was well. That is until I rebooted or even cold-booted the board. I no longer could get HDMI output.

After thinking about it for a minute I decided to repeat my ‘accidental’ previous steps and fully powering down the Tachyon and slightly backing-out the USB-C power supply from the USB-C hub.

Bingo. My Tachyon will absolutely not output any HDMI signal whatsoever if the power connector is fully inserted into the USB-C hub at boot, but neither will it do so if it is completely disconnected! (note: I haven’t consistently seen the no HDMI when power is not connected to the hub, but seems more often than not to be the case.) So I have to boot it with the power supply connection partially inserted into the hub and once booted and I have the desktop I can then fully insert the power to the hub in order to charge the battery. The HDMI output is steady and unaffected as long as I fully insert the power connection into the hub after I get the initial HDMI signal output at boot.

Maybe others are having this same issue and don’t realize it. I would likely not have discovered the issue on my setup if that power connection on the hub hadn’t required extra effort to fully seat.

Now I’m left wondering is the issue I’m seeing with the hub? Or the Tachyon?

Regards,
Anthony

[mrlambchop]

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

[radu7]

Thanks for all of that detail Nick! It is great to get that kind of insight on this from you.

You hit the nail on the head, at least for my issue, as restarting gdm (after boot with the power supply connected to the usb hub and not getting any video output) definitely kickstarts the HDMI output. So with the info you provided, I just added a script to run at boot time that will sleep for a bit (30 seconds worked so I stayed with it, but could probably be shorter) and then run systemctl restart gdm as you suggested.

Now I can leave everything connected as it should be and I get my desktop via HDMI soon after boot/reboot. I’m happy enough with that workaround.

If you need a tester for anything you or the Particle team are working on for the Tachyon (fixes or new features) let me know and I’ll be glad to help test anything you need. I didn’t have any defined projects for the Tachyon when I backed it on KS so mine is ‘available’ to help you guys out with whatever you might need someone to kick around, I’ve been a fan of what you guys are up to since the Spark days and the Tachyon looked too promising to not back the project.

Having said that, is there a defined location to report observations (don’t want to call them ‘bugs’ just yet) other than here in the community? I’ve seen a couple other things I have questions about, but they could be considered ‘cosmetic’ as far as I’m concerned at this point.

Thanks again Nick!

Regards,
Anthony

[Bartvdg]

Thanks both, restarting gdm worked for me as well!

[terracode]

I had issues with HDMI as well. I tried with USB C to HDMI active cable and a USB C portable monitor with external power. Both didn't get any video. After verifying I am plugging into 1st USB C port (only port that does alt DP and bidirectional power) and trying the plug in after power up still had issues. What finally worked was plugging into my Belkin Thunderbolt 3 dock plus which then goes to DP monitor output. Now it works every time without resorting to acrobatics.