Display negotiated display settings in the web UI

[cghague]

The only way to determine what display settings have been negotiated between a TinyPilot device and a connected system is to check the logs or manually pull the details over SSH. This information is very useful for support purposes so it would be helpful to surface it in the web UI.

[mtlynch]

Thanks for filing this, @cghague.

Can we flesh this out a bit more?

Where in the web UI does TinyPilot surface the negotiated resolution? How does the user act on that information?

If it's for support purposes, aren't we getting it already from the logs?

[cghague]

@mtlynch - We can indeed expand on this!

Where in the web UI does TinyPilot surface the negotiated resolution?

Version 2.5.2 displays the current video format in the status bar, so I'd suggest that would be a good place to display the negotiated resolution. For example, "H264, 1920x1080, 30Hz".

How does the user act on that information?

We have user facing documentation that lists supported resolutions and troubleshooting guides that also suggest checking the resolution is correct. However, this isn't a straightforward task as we regularly see examples where the resolution set on the target computer doesn't match what actually gets used. Making this information available in a user friendly way would help to enable self-support and reduce the amount of tickets that reach the support teams.

If it's for support purposes, aren't we getting it already from the logs?

The information is available in the logs but it isn't in a user friendly format. The key aim here is to allow users to perform basic diagnostics based on our support documentation without needing to involve the support teams and without needing the user to dig through large amounts of text.

[mtlynch]

There are a few things that make this kind of hard:

• It requires putting information in a prominent place in the main web UI, so 100% of users see it 100% of the time
  • But <5% of users need this information, and they probably only need it <5% of the time.
• It relies on scraping the uStreamer logs, which might change formats in the future and break this functionality
  • Also, what log message would we scrape? When negotiation fails, do we know the requested resolution?
• I think the frontend would have to poll the backend every N seconds to scrape the logs again and update the web UI, which is a lot of complexity

I'm also not totally clear on what the scenario is. Is the idea:

1. User sees "No Signal"
2. User checks resolution in the web UI
3. User goes to TinyPilot's supported resolutions page
4. User sees that the requested resolution is not a resolution TinyPilot supports
5. User reduces resolution on the target system and fixes the issue

I feel like if the user knows to identify resolution as a possible cause, then it's pretty likely that they'd try reducing resolution on the target system even without knowing the negotiated resolution.

One alternative that's a little more lightweight:

1. We detect when there's no signal by checking uStreamer's /state route (https://tinypilot/state) every N seconds
2. If we detect video isn't streaming (source.online === false), scrape the uStreamer logs at that point to see if we can translate it to something human-facing
3. We pop a helpful error popup explaining how to fix it

For (2) though, we'd have to figure out which uStreamer log messages would tell us the problem.

[cghague]

We discussed this in a call today - notes below for future reference.

---

There were concerns around what error message to display and when:

• Scraping logs for data is problematic for maintainability.
• "No signal" isn't intrinsically an error (e.g.the computer might just be off).
• Avoiding error fatigue is important.

We discussed an alternative approach:

• Don't display an error when signal loss is detected (using source.online).
• Instead, wait for a time or activity threshold, then display help text.
• Avoid error based wording and instead go for signposting e.g. "No Signal? Get help online.".