Mir client API does not support non-square pixels

The client API has all the information required to do this now - the ID of the output their surface is on, the current display mode, the current display orientation, and the physical size of the outputs.

(In hindsight, I think having the DPI in the SurfaceOutputEvent is a minor mistake - the value that clients should care about is scale - which they can't calculate themselves - not DPI, which they can. And don't use, because they're using scale ☺)

My expectation is that exactly zero clients would use the proposed API, and any client that did is not blocked on us providing this API.

It's partly a matter of convenience and efficiency. If Mir can simply tell you rendering parameters like scale, subpixel order and DPI via a simple mechanism like SurfaceOutputEvent then that's preferable to the less simple alternative of enumerating physical displays in the client/toolkit.

More generally though, these values should be abstractable in future in that a client is not forced to optimize for a single physical output but rather optimize across a number of outputs.

If output A is HBGR and B is HRGB then a surface spanning both should probably choose greyscale/none subpixel ordering regardless of what output the surface is mostly on, because otherwise it will look so ugly on one of them that people will report rendering bugs.

If output C is 120Hz and D is 60Hz then the correct decision for a surface spanning both is to use 120Hz, regardless of what output the surface covers more of.

If output E is 4K but output F is only FHD then design have said for cloning they want a 4K image scaled down to FHD for F. A surface on this display now has 2 or more physical outputs' attributes to optimize for.

These are important decisions to visual quality we can solve trivially by using MirSurfaceOutputEvent with policy decided in the server. Alternatively we could let toolkits choose their own policy but that's:
  (a) More work - repeated per toolkit; and
  (b) Not yet possible since MirSurfaceOutputEvent incorrectly identifies just one physical output to optimize for whereas it needs to be returning a list of outputs that are used.

I did say this was a low priority enhancement, but it's certainly not invalid.

Syncing task from Mir.