This is one of the things on my TODO-list for when I stumble upon a way to have infinite amounts of time: Learn "FPGA 'n stuff" and build my own display contro

This is one of the things on my TODO-list for when I stumble upon a way to have infinite amounts of time: Learn "FPGA 'n stuff" and build my own display controller. Like many people here, I don't understand why this takes so much bloody time. Not just the input switching, but also switching resolution or refresh rate on the same input. So either I'd have an a-ha moment and see why it's not possible (more likely outcome), or well, it'll just work and I can write a cool hackaday post. The EDID explanation given in the comment currently at the top doesn't make too much sense: Even if the display is off and not in some super hardcore energy saving mode, EDID works, i.e. your computer can query the EDID data from the screen and know what its preferred resolution is, etc. Likewise, even if your display is switched to HDMI-1, a machine connected to HDMI-2 can already be outputting 1080p60 to it, so why does switching inputs take more than a few milliseconds? Afaik (and I only have very rough knowledge here), there is no side-channel in HDMI/DVI that tells the display what mode it's actually receiving, so the display has to look at the signal and make sense of it. So you have to put some brains in it. But that can hardly take several seconds, i.e. hundreds of frames? Maybe two or three frames! I could see this being a cost cutting measure, maybe doing the dumb implementation that takes seconds instead of milliseconds saves you a cent or two per device.