Zero-copy path for GPU-less secondary GPUs

This series (the final patch) adds one more path for secondary GPUs to receive content. To recap all the paths, this is their preference order:

1. Secondary GPU copy: A dmabuf is exported from the primary GPU and imported to EGL on the secondary GPU. The secondary GPU performs a hardware accelerated copy into a buffer of its own, which is then shown via KMS.
2. (New!) Zero-copy: A dmabuf is exported from the primary GPU and imported to KMS on the secondary GPU as a DRM FB for showing via KMS directly. In most situations this will not work.
3. Primary GPU copy: A DRM dumb buffer is allocated on the secondary GPU and imported to EGL on the primary GPU. The primary GPU does an accelerated copy into the dumb buffer, which is shown via KMS. This has a high risk of failing, because dumb buffers are usually unusable for accelerated operations.
4. CPU copy: A DRM dumb buffer is allocated on the secondary GPU and memory-mapped to the CPU. glReadPixels copies the framebuffer content into it. The dumb buffer is shown via KMS.

Paths 1, 3 and 4 already exist in the above preference order, this MR adds path 2.

The zero-copy path is especially useful with virtual secondary GPU DRM drivers. One such driver is EVDI which is used by the DisplayLink driver stack. On hardware DRM drivers the zero-copy path probably fails and falls back to the third or fourth path unless picking the first path to begin with.

A DisplayLink dock was used to test this series on Ubuntu 19.04.

To minimize potential regressions, the secondary GPU copy path is left foremost. Using a zero-copy path may be attractive at first, but the driver combinations where it actually works are likely rare. If it does work with a pair of hardware DRM drivers, it has a risk of performing worse than either of the GPU copy paths because quite likely a CRTC must access the framebuffer through a bus (e.g. PCIe) instead of using local VRAM. This causes continuous traffic on the bus regardless of whether the image is updating or not.

Unfortunately I have not been able to test this series on anything else but the DisplayLink setup. Testing this on as many different multi-GPU setups as possible would be good.

If you enable g_debug () messages from libmutter, you will see one-time notes per secondary output about what copy paths it is taking, e.g. "Zero-copy disabled", "Using zero-copy", "Using primary GPU to copy", and "Failed to initialize accelerated iGPU/dGPU framebuffer sharing". If you see none of these and a secondary output is active, then it must be using the secondary GPU copy path.