[jandrese]

I read it as friction between how Rust sees its application model and the real world. Total ownership of a resource can't be maintained if some jackass goes and pulls the physical hardware out from under you. So now the Rust implementation gets crufted up with a zillion checks for unexpected changes to the underlying system that are clunky in Rust because that's supposed to be an exotic condition, not something you're doing on practically every line.

[codedokode]

This can also indicate a problem in architecture: if the monitor can go away any time, you shouldn't store long time references to it and instead, for example, call a function to get current default monitor every time you want to do something. Or at least validate those references before usage.

[jandrese]

I suspect querying the monitor for its parameters every time you want to blit pixels to it is wildly impractical. EDID runs over a slow serial link, and you have 124.4 million pixels to blit out every second.

The sensible way to handle this is for the system to throw an interrupt when the state of the connection changes, but interrupt handling is something Rust's ownership model struggles to accommodate.