Code review comment for lp:~andreas-pokorny/mir/add-pixel-format-to-display-configuration

> (1) I agree in real display systems (non-nested) the pixel format is not
> something you choose. What you choose is a colour depth (which may or may not
> fully dictate the pixel format), and from that you can query what the physical
> pixel format is. That's if you even need it at all. In the case of OpenGL for
> example, you never need to know the physical display pixel format. I'm
> wondering if should make it more obvious that the MirPixelFormat parameter is
> only meaningful to nested displays?
>
> My key concern is that although two graphics systems might look similar, one
> may only support RGB and the next might only support BGR. And a third might
> only support 16-bit colour (like i8xx GPUs). So specifying a desired pixel
> format is very dangerous to portability _if_ you require that the format be
> honored. It's not yet clear to me if we are using it in an unsafe way though.

I think neither for nested nor for the real display outputs specifying a pixel format makes
sense. What is shown on the display changes dynamically based on the content provided.
So if there is content provided by a client that can be scanned out directly the
"current pixel format" at the output as an up-front configuration makes no sense.
If we can somehow leverage more hardware composting support, we might have opaque and
 non opaque RGB buffers and YUV buffers at the same time - and no notion of "current pixel format"
on an output.

As soon as we do that (=hwc) for real displays we will also do that for the nested case.
Then we should also rework NestedDisplay and NestedOutput. Those classes should only create
buffers when the nested shell request buffers for rendering.

But right now the graphical structure (as i understand them) is:
 * there is a mir server that creates a frame buffer
 * the frame buffer contains the rendering result of the shell that draws all its visible clients
and that recursively for all levels of nested servers. Bypass is just an exception through the system.

With the hwc support we discussed in December it may become:
 * there is a mir server
 * the shell decides which set of buffers define the rendering result of the server
and that recursively for all levels of nested servers. Bypass does not exist as a special case.

At that point the "current pixel format" should no longer be part of the Output Configuration.

> (2) Namespaces: See previous comment

What is bad about to opening namespace scope inside source files of the class to be implemented?