91–100 of 185 posts
Not always, though. The switch sometimes happens instantly. (At least, it has been this way since I replaced my Nvidia card with an AMD. I don't recall whether the Nvidia ever switched instantly.)
I wish I knew what conditions make it instant, so I could try to make it happen consistently.
Earlier quoted context omitted.
Then there must be something badly wrong with the protocol and/or implementations. Negotiating a few bits over a high-quality cable link should be instantaneous.
There could be, but there are (at least) three parties involved in whatever's causing the slow monitor response. I find it irritating even without a switch, just plugging in my external monitor should not take what seems like thirty seconds to actually turn on. But in reality, you've got whatever tiny micro is inside the monitor, talking to whatever's on the graphics card, in turn talking to display drivers and who-k…
Yeah. And the DM must adapt to the new resolution, redraw stuff, maybe adjust the refresh rate. That's why I think stating "I want it on immediately" is a bit naive and assuming.
Earlier quoted context omitted.
> Monitors are kind of the same. There's handshaking that goes on each time you connect a monitor to a video source. If the connector is high bandwidth enough to send hundreds of thousands of pixels 60 times a second, how can it possibly be so slow to send a few bytes of handshake or EDID data? Handshakes should be happening nearly instantly. You can complete opening a TCP connection to the other side of the world in…
There's a major difference between the data-plane (the lanes where frames go from the signal source to the display) and the control-plane (the command and control channel that is bidirectional and used to discover a peer and negotiate settings). The former is indeed very high speed, in the order of gigabits per second (up to 48gbps in later iterations), whereas the latter can seem ancient in comparison - 500bps to 11…
Earlier quoted context omitted.
Even with one of the fancy KVM switches that were recommended here my switching isn’t instant. It did go down from 10-20 seconds of flickering to +/- 2 seconds though. May not be worth it if you are already at 4s though.
What model do you use that gave you 2 seconds switching time? One of the mentioned Rextron or something else?
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…
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.
0: I use `ddcutil` (on Linux), it takes about 2 seconds for the switch: `ddcutil -b $bus setvcp 0x60 $source`
1: Use something like NoMachine or VLC - would probably cause more problems if you've got devices that go into power-save mode
2: Ensuring that your devices are outputting the exact same mode may decrease the time.
Earlier quoted context omitted.
What if you modify the cables to remove the DDC wire? Can no EDID negotiation be faster?
EDID is important because it is the only way for the host to know which resolution, color depth, frame rate the monitor supports. Even if you remove the DDC wires, the OS will still try to communicate, and it might delay this even more because of the retries and delays in code. You might get a headstart if you hardcode the EDID in the OS itself. There are ways to do this on Linux [1], Intel macOS [2] and Windows [3].…
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…
It was really jarring when I got my M1 Pro MacBook and switching resolutions on the internal display was literally instant. No black screen between the switch whatsoever, it was just there. Makes you wonder what else we've been missing out on all this time.
Earlier quoted context omitted.
EDID is important because it is the only way for the host to know which resolution, color depth, frame rate the monitor supports. Even if you remove the DDC wires, the OS will still try to communicate, and it might delay this even more because of the retries and delays in code. You might get a headstart if you hardcode the EDID in the OS itself. There are ways to do this on Linux [1], Intel macOS [2] and Windows [3].…
But why is EDID negotiation slow?
TLDR: because it is done over a slow protocol (I²C) and because of artificial delays in code to account for slower devices