Allow Reset Stream on switching inputs

[onedr0p]

Is your feature request related to a problem? Please describe.

Hi 👋🏼 Let me start by saying I am not sure if this is a bug or a feature request, maybe both?

Hardware:

• Official PiKVM v3 (latest software version as of this post)
• Tesmart 8-port KVM with 6x Intel NUCs plugged in

I am using the Tesmart 8-port KVM and very often the stream in PiKVM gets "stuck" (no output on any of the devices) when I am rebooting any of the 6 computers I have hooked up to it. The different ways to "fix" this issue include clicking the "Reset Stream" option in the UI, or closing the browser and re-opening it, or changing the FPS on the slider in the UI.

It seems like when the devices hooked up to the Tesmart KVM reboot the stream is lost. This happens once (but very often) in awhile so it's very hard to pin point how to completely fix this issue. This issue happens using WebRTC or MJPEG and on any browser I've tried so it appears to be an issue with the connection between the PiKVM and Tesmart when devices are rebooted.

I've had this issue for a very long time (2+ years) and was hopeful a update would fix it so I've been silent about bringing it up in an issue. Also, I know others with this Tesmart KVM switch that experience the same issue.

Describe the solution you'd like

I would like a way when switching devices that reset stream is automatically called or for this bug to be fixed. I know resetting the stream on input change is more of a bandaid solution but not sure how much the PiKVM team is willing to invest in helping to solve this issue.

Describe alternatives you've considered

Scripting this but I am not sure where to get started.

I know the Tesmart isn't "officially" supported but it would be nice if this issue could get addressed.

[bbeaudoin]

I seem to recall that was an issue with PiKVM v2 (DIY) and PiKVM v3 (hat) and likely related to the 50Hz limitation of those devices. On input switch, TESmart might switch to 60Hz based on the input device's current state (idle or ready). As there is no physical reconnection to PiKVM, rather than resend the EDID when the TESmart switches output frequency, it just shows "No Signal."

Although in my recollection this happened infrequently, and never when using an EDID emulator pass-through dongle set to 1080p30 or 720p60, I can understand the frustration with frequent use. This issue does not appear to happen, or at least happens less frequently, if at all, with PiKVM v4 due to higher supported frequency (1080p60).

One thing that limited this occurrence, in my case, was not every input was in the same resolution. VMware consoles grey out when idle and most text-based consoles use lower resolutions and/or signaling rates. It only appeared on those consoles which used a full GUI with higher resolutions (1080p) and lack of a persistent EDID generator or documented corruption of EDID on switching (TESmart bug, fixed in some later firmware) can also be to blame.

Although I've stopped using EDID emulators since switching to v4, it's been called a fix by some users for the older v3 and DIY builds. These can be purchased for around $7 and do work on the output port between TESmart and PiKVM. For more stubborn cases, such as when TESmart corrupts the EDID of a connected host with its own, one may also connect an EDID emulator on the input port, but I haven't had such a use case myself.

Just be certain that it is a passthrough EDID emulator that supports resolutions no higher than 1080p50. Typically 1080p30 is the highest compatible device sold and marketed in the U.S., this may also be marketed as 2K, more expensive ones have the option of copying the EDID of PiKVM or replacing the EDID with its own fixed resolution.

Ultimately I'm not sure if this is something to be addressed with older PiKVM v3 devices. As annoying as it may be, I don't know the durability of the CSI2 hardware. If the hardware can handle 10,000 hardware resets, the lifespan could be reduced from 27 years with one daily reset to just over 3 years with 8 resets per day. In cases where resets aren't necessary, as in my case many of my host consoles used lower resolutions and never went to "sleep", I might experience no benefit, only the drawbacks of unnecessary hardware resets.