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.