undefined | Better HN

0 pointswzdd3y ago0 comments

Naively it seems like you could optimise this at least for the second and subsequent switches: you could detect if the cable corresponding to the input you've previously switched to has been reconnected since last switch. If it hasn't, then you could re-use the previous EDID values for the device.

You'd obviously want this to be optional for special cases, but would that work, if implemented in a monitor or KVM?

It's not so much the delay that's annoying, but the renegotiation with something which is so obviously the same device.

0 comments

1 comments · 1 top-level

alin233y ago

I believe that is already being done. As I said in my comment here (https://news.ycombinator.com/item?id=34049171) switching between two active inputs takes about 1 second for me.

The problem that OP is facing is switching to an inactive input that went into power saving mode. In that case, the link between the inactive device and the monitor may have been broken and it's impossible to know if the device is the same as the one before after reconnection (with the same exact video settings etc.).

This doesn't have to be the case though. Before I found out how to use I²C on Apple Silicon Macs, I was using a Raspberry Pi connected to an HDMI input of the monitor that could listen to DDC commands through an HTTP server: https://alinpanaitiu.com/blog/journey-to-ddc-on-m1-macs/#the...

And because I didn't want that Pi Zero to get hot, I managed to only keep the DDC lines open and stopped the video signal from being sent using `vcgencmd display_power 0`.

With those settings, the monitor still switched between inputs in 1 second, with the added small latency of having to run `vcgencmd display_power 1` (which was fast enough once it was automated to run on input switching)

j / k navigate · click thread line to collapse