May not be worth it if you are already at 4s though.

Linux isn't my daily driver so this might be a dumb question, but what's up with Wayland? I feel like I've been hearing for a solid decade that X is dead yet whenever someone recommends me a piece of software it never works on Wayland. Wayland is fourteen damn years old at this point.

Most app developers are dragging their feet when it comes to supporting wayland, but with big distros now shipping wayland by default, the pressure to make sure their apps work in wayland is really high in the past two years. For example, just last week vscode finally fix rendering issues that plagued wayland + nvidia users for years (had to use insiders version with some extra args but at least I can use vscode in wayland now). I think the rate of developers finally adding wayland support in their apps is finally accelerating.

Please note that I’m having issues with their smart keyboard port, but that may be related to the interaction between the two.

[0] https://www.amazon.com/gp/product/B088WGKFZH

Can no EDID negotiation be faster?

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].

[1] http://billauer.co.il/blog/2020/08/linux-override-fake-edid/

[2] https://github.com/mbruggmann/osx-edid-overrides

[3] https://learn.microsoft.com/en-us/windows-hardware/drivers/d...

TLDR: because it is done over a slow protocol (I²C) and because of artificial delays in code to account for slower devices

The negotiation is done when the host initiates it, usually when the cable is connected to a port or when coming back from deeper sleep/standby.

If the host remains active after the negotiation, the monitor doesn't go through the process again, I explained how that worked for me here: https://news.ycombinator.com/item?id=34051428

The problem that OP has is when the host being switched to is in standby. In that mode, most devices deactivate the video ports completely, disconnecting the monitors and removing them from the hardware device tree.

Switching to the inactive input without waking up the host device will usually show a "No signal" message on the monitor. Waking the device before switching to the input could improve the waiting time, but that is an implementation detail depending on both the monitor and the OS and can't be guaranteed.

No, at this point removing EDID will simply get the display not detected at all. It used to be optional in the times of VGA, where you could just drive out 640x480 "blind", but there's too much stuff in there these days.

http://decimator.com/ Has some really good shit including (accidental) hdmi copy protection removal.

Sometimes the 400 Euro grabber works sometimes the 30 Euro one works. The expensive ones are surely more rugged tho.

I suspect all most manufacturers do is build a decice around some existing HDMI IC and if your stuff is supported by that IC and they didn't cut a ton of corners it works. Maybe you need the 4000 Euro price class to run it all, I never tried.

Is this something you've tried before and could go into more detail about? I've got an HDMI grabber for using a DSLR as a webcam, but never thought to output the display of one of my computers to another. This would solve a lot of issues regarding switching between work and personal laptops.

Why does the negotiation take so long, though? There doesn't intuitively seem to be a lot of information.

[1] https://www.nvidia.com/content/Control-Panel-Help/vLatest/en...

[2] https://nvidia.custhelp.com/app/answers/detail/a_id/3569/~/m...

[3] https://portal.7thsense.one/user-guides/MC264-display-config...