What is the reasoning for putting this code in the video driver?
The "Theory of Operation" comment in the merged-then-reverted code is insightful. Apparently, the code is supposed to figure out which parts of windows are damaged, and then tell the windowing system to do something about it.
IMHO, windows are not a concept that should even exist in the video driver [1]. They should be entirely under control of the windowing system. Which means that figuring out which parts of windows are damaged is logic that should totally reside in the windowing system, having no parts in the video driver.
If this code must be in the driver because it needs to access private data/functionality that's not visible outside the driver, then an API to expose those driver internals to the windowing system would be a design that better separates those layers.
Reverting this commit seems like a sound technical decision to me. Assuming Intel's decision is politically motivated, and then getting outraged about it, seems counterproductive.
[1] Even if this concept has already leaked into the driver for X or other windowing systems, doesn't mean that questionable designs used in old code should be allowed in new code.
Not really informed here but I would venture a guess that 'perfect separation of concerns' causes a performance hit. In the backend web dev world you can usually suck that up by making the load parallelizable across servers, something you don't have the option of doing with code running locally. In other words, 'separation of concerns' is great until you hit a performance bottleneck, as you often do with any resource constrained system.
So originally the XMir support was merged in, then reverted on instructions from Higher Ups.
I can't really blame them, if they make driver changes Intel would have to adapt the XMir code to cope with them.