111–120 of 185 posts
In my (very poor) understanding, it 'caches' the information about monitor capabilities. I used it to prevent my laptop from rearranging windows when my monitor goes to energy saving mode.
This is one thing I really miss about analog tv. You could switch channels as fast as you could press the button. Everything now is so slow.
Earlier quoted context omitted.
My current (Samsung) display is a pain to switch off . If I forget and switch the PC off first, it goes to sleep and starts blinking its annoying bright blue LED, which I managed to disable when it's on or off, but not when it's asleep. To get it to switch off I have to wake it up, wait until it cycles through all its inputs, gives up and shows me the menu, from which I can finally turn it off.
I'd plug the thing into a switched wall socket!
Earlier quoted context omitted.
Most of the delay is I/O bound. Handshaking happens over the Display Data Channel (DDC) which is a protocol over I²C (a two-wire comunication bus). HDMI/DP/DVI have 2 dedicated wires inside the cable for this, USB-C has to switch over to use differential signaling on pins A8 and B8, and then switch back after communication is done. The bandwidth of that bus is small indeed, but most of the latency comes from artifici…
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…
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)
Not on a monitor (that I'm aware of), but it is a major feature of signal distribution equipment for installed AV and broadcast. A large part of the delay that you are seeing is from EDID negotiation and HDCP. This happens of the 100kbit/s DDC channel and requires a bit of back and forth. On the above systems this is pre-negotiated so that switching can take place across a single frame. A lot of that equipment is lik…
Earlier quoted context omitted.
But why is EDID negotiation slow?
See my answer here: https://news.ycombinator.com/item?id=34050157 TLDR: because it is done over a slow protocol (I²C) and because of artificial delays in code to account for slower devices
This has been annoying me since I first tried a PC after using Atari computers since they were a thing. No matter what monitor I use, it will take for ever to switch input port or just a simple change of resolution. I was used to be able to switch resolution several times per frame, you could make a game with low resolution and color on the upper 3/4 of the screen and have the stats in higher resolution 4 color mode…
See, for example, boot up times.
Also see how recovering from sleep/hibernation is now slower than 80s computer boot times, so expect a second layer of abstraction to form soon in the market, a faster recovering sleep mode than actual sleep mode.
I wish this existed. Samsung Odyssey G7 has the same issue.