Subject: Mir in a virtual machine

From: Rian Quinn <[email-masked]>
Date: Tue, 21 Jan 2014 13:08:54 -0800 (PST)

Is it possible to get Mir up and running in a Virtual Machine. I have both VMWare and VirtualBox. Currently, under VMWare, you get an error about open_drm_device. Basically, I am working with Mir for some client / server development, and would like to do testing in a virtual machine to start. 

Thanks,
- Rian

---

From: Daniel van Vugt <[email-masked]>
Date: Wed, 22 Jan 2014 09:44:06 +0800

Rian,

VMware (Thomas Hellstrom) has implemented Mir support. Apparently you 
need kernel 3.13 for the requisite graphics driver DRM changes. And you 
need a newish Mesa.

I don't think anyone has documented the particulars yet. But we 
certainly should at least by the time regular Ubuntu (trusty?) has all 
the prerequisites in place.

- Daniel

On 22/01/14 05:08, Rian Quinn wrote:
> Is it possible to get Mir up and running in a Virtual Machine. I have
> both VMWare and VirtualBox. Currently, under VMWare, you get an error
> about open_drm_device. Basically, I am working with Mir for some client
> / server development, and would like to do testing in a virtual machine
> to start.
>
> Thanks,
> - Rian
>
>

---

From: Rian Quinn <[email-masked]>
Date: Wed, 22 Jan 2014 12:21:28 -0500

Daniel,

I was able to update my system, and my sources and was able to get Mir up
and running.

I am actually really impressed with the Mir source code. We were
considering writing a lot of this ourselves, but I think that Mir has
everything that we need already.

I do have a couple of questions.
- Does Mir support multiple monitors? If so, do you have any examples or at
least a starting point on how to set that up.
- How does Mir handle surfaces with shapes cut out of them. For example, a
smiley face where the background is shown through the eyes and mouth.
- Do clients need to have root access. For the fingerprint test, I could
not get it to run without a sudo.

Thanks,
- Rian

For others interested in how I got Mir up and running, here were my steps:

1:
Install the 3.13 linux kernel. Here is what I used for that:
http://linuxg.net/how-to-install-kernel-3-13-rc-7-on-ubuntu-linux-mint-pear-os-and-elementary-os/

2:
Install libDRM from the following PPA:
https://launchpad.net/~oibaf/+archive/graphics-drivers/

3:
run sudo apt-get build-dep mir

4:
Download and compile Mir form the following:
http://unity.ubuntu.com/mir/building_source_for_pc.html

5:
Download and compile Mir's version of Mesa and here are the compilation
steps:
http://www.mesa3d.org/install.html

I had to add --disable-dri3 to get it to compile, plus the
--with-egl-platform=mir,drm

Once I was done with that, I could get the examples to execute.

On Tue, Jan 21, 2014 at 8:44 PM, Daniel van Vugt <
[email-masked]> wrote:

> Rian,
>
> VMware (Thomas Hellstrom) has implemented Mir support. Apparently you need
> kernel 3.13 for the requisite graphics driver DRM changes. And you need a
> newish Mesa.
>
> I don't think anyone has documented the particulars yet. But we certainly
> should at least by the time regular Ubuntu (trusty?) has all the
> prerequisites in place.
>
> - Daniel
>
>
>

---

From: Alan Griffiths <[email-masked]>
Date: Wed, 22 Jan 2014 17:36:54 +0000

Hi Rian,

On 22/01/14 17:21, Rian Quinn wrote:
> Daniel,
>
> I was able to update my system, and my sources and was able to get Mir
> up and running.

that's great news!

> - Does Mir support multiple monitors? If so, do you have any examples
> or at least a starting point on how to set that up.

Some stuff works but I'll leave someone else to respond with details.
(It isn't our current dev focus and I'm not sure of the current status.)

> - How does Mir handle surfaces with shapes cut out of them. For
> example, a smiley face where the background is shown through the eyes
> and mouth.

We support alpha blending - there are some examples with transparency

> - Do clients need to have root access. For the fingerprint test, I
> could not get it to run without a sudo.

They don't, but they need access to the socket (and the socket name
depends on the user).

So (assuming the server socket defaults to /tmp/mir_socket) you need:

sudo chmod +rw /tmp/mir_socket
/mir_demo_client_fingerpaint -m /tmp/mir_socket

HTH
Alan

---

From: Daniel van Vugt <[email-masked]>
Date: Thu, 23 Jan 2014 10:35:14 +0800

Q: Does Mir support multiple monitors? If so, do you have any examples 
or at least a starting point on how to set that up.
A: Yes... The API for affecting the multi-monitor config is
   mir_connection_create_display_config
   mir_connection_apply_display_config
   etc.. http://unity.ubuntu.com/mir/group__mir__toolkit.html
To enable basic multi-monitor testing you can:
   mir_demo_server_shell --display-config sidebyside
Mir's multi-monitor configuration is already used in detail by XMir. 
That's how you can configure displays from X under XMir.

Q: How does Mir handle surfaces with shapes cut out of them. For 
example, a smiley face where the background is shown through the eyes 
and mouth.
A: Create your surface with an alpha channel (e.g. 
mir_pixel_format_abgr_8888) and then any pixels with alpha==0 will be 
transparent. As an example of a free-form shape, you can run:
     mir_demo_client_egltriangle -b 0.0

Q: Do clients need to have root access. For the fingerprint test, I 
could not get it to run without a sudo.
A: Yes and no. A client can run as the same user as the server, 
including non-root. This works perfectly for touch (Android) devices 
however desktop has the problem of requiring root to access input 
devices. You can run mir server and client on desktop as non-root but 
you won't be able to interact with it.

On 23/01/14 01:21, Rian Quinn wrote:
> - Does Mir support multiple monitors? If so, do you have any examples or
> at least a starting point on how to set that up.
> - How does Mir handle surfaces with shapes cut out of them. For example,
> a smiley face where the background is shown through the eyes and mouth.
> On Tue, Jan 21, 2014 at 8:44 PM, Daniel van Vugt
> <[email-masked] <mailto:[email-masked]>>
> wrote:
>
>     Rian,
>
>     VMware (Thomas Hellstrom) has implemented Mir support. Apparently
>     you need kernel 3.13 for the requisite graphics driver DRM changes.
>     And you need a newish Mesa.
>
>     certainly should at least by the time regular Ubuntu (trusty?) has
>     all the prerequisites in place.
>
>     - Daniel
>
>
>

---

From: Rian Quinn <[email-masked]>
Date: Thu, 23 Jan 2014 04:48:28 -0800 (PST)

I would prefer to run the server as non-root, but if I attempt to do that, it complains about not being able to open the DRM device. If I run the fingerprint demo as non-root, and the server as root, the client complains about not being able to make a connection to the server. And some of the clients I cannot get to connect at all regardless of root or not (like all of the EGL examples). 

I am a little confused though. If Mir is to replace X someday, clients will have to be able to be run as non-root. The ideal solution is where both the server/compositor, and clients are running as non-root which is one of the things that X doesn’t do today. Are there plans to fixing the privilege issue (everything needing root), or am I not understanding something. 

Thanks
- Rian

> On Jan 22, 2014, at 9:35 PM, Daniel van Vugt <[email-masked]> wrote:
> 
>

---

From: Kevin Gunn <[email-masked]>
Date: Thu, 23 Jan 2014 17:22:20 -0600

Hi Rian - yes, we will eventually address the running as root issue. In
fact in the touch configuration we'll soon have a nested mir setup (or
mir-on-mir), where one is associated with the user session for unity8 and
the other as root which the greeter will be using (as the system
compositor).
br,kg

On Thu, Jan 23, 2014 at 6:48 AM, Rian Quinn <[email-masked]> wrote:

> I would prefer to run the server as non-root, but if I attempt to do that,
> it complains about not being able to open the DRM device. If I run the
> fingerprint demo as non-root, and the server as root, the client complains
> about not being able to make a connection to the server. And some of the
> clients I cannot get to connect at all regardless of root or not (like all
> of the EGL examples).
>
> I am a little confused though. If Mir is to replace X someday, clients
> will have to be able to be run as non-root. The ideal solution is where
> both the server/compositor, and clients are running as non-root which is
> one of the things that X doesn’t do today. Are there plans to fixing the
> privilege issue (everything needing root), or am I not understanding
> something.
>
> Thanks
> - Rian
>
> --
> Mir-devel mailing list
> [email-masked]
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/mir-devel
>
>

---

From: Daniel van Vugt <[email-masked]>
Date: Fri, 24 Jan 2014 10:35:15 +0800

Rian,

Both of the issues you describe /had/ simple solutions, documented under 
"Running Mir natively":
   http://unity.ubuntu.com/mir/using_mir_on_pc.html
   or: $SRC/doc/using_mir_on_pc.md

Though I just retested non-root clients with a root server, and it 
doesn't work as documented. So that's a bug, sorry;
   https://bugs.launchpad.net/mir/+bug/1272143

- Daniel

On 23/01/14 20:48, Rian Quinn wrote:
> I would prefer to run the server as non-root, but if I attempt to do
> that, it complains about not being able to open the DRM device. If I run
> the fingerprint demo as non-root, and the server as root, the client
> complains about not being able to make a connection to the server. And
> some of the clients I cannot get to connect at all regardless of root or
> not (like all of the EGL examples).
>
>>     example,

---

From: Alan Griffiths <[email-masked]>
Date: Fri, 24 Jan 2014 10:50:16 +0000

On 23/01/14 12:48, Rian Quinn wrote:
> that, it complains about not being able to open the DRM device. If I
> run the fingerprint demo as non-root, and the server as root, the
> client complains about not being able to make a connection to the
> server. And some of the clients I cannot get to connect at all
> regardless of root or not (like all of the EGL examples).
>
> will have to be able to be run as non-root. The ideal solution is
> where both the server/compositor, and clients are running as non-root
> which is one of the things that X doesn’t do today. Are there plans to
> fixing the privilege issue (everything needing root), or am I not
> understanding something.
>

Our intention (some work is still in progress) is for there to be a
system compositor (unity-system_compositor) running as root, but (unless
enabled for debug purposes) not exposing an endpoint on the filesystem.
(IPC will be used to pass sockets to authorised, non-root processes.)

These authorised, non-root processes will be user session compositors
that publish filesystem endpoint - to $XDG_RUNTIME_DIR/mir_socket - and
will accept clients from that user.

Because this is a work in progress we have the unfortunate situation
that the configuration you're trying (a root system compositor accepting
connections from a non-root client process) needs the permissions on the
endpoint to be changed to enable non-root client connections and the
client needs to access a non-default endpoint name.

The instructions on the website are out of date wrt trunk (they are
published from the saucy builds) I'll be fixing them on the development
version.

As Kevin says, we're in the process of separating the system and session
compositors in the touch images. There are still some issues preventing
the system compositor working exactly as described above (and we
currently connect via a filesystem endpoint), but they too should be
fixed shortly.

HTH

---

From: Rian Quinn <[email-masked]>
Date: Fri, 24 Jan 2014 04:21:13 -0800 (PST)

No problem. For now, I have enough to get going. 

Another issue that I noticed is that when I attempt to allocate a hardware buffer using mir_connection_create_surface, it fails on VMWare, but software buffers work fine. I traced the code to the mmap function failing, and noticed that it is basically the same problem I was having when trying to write the DRM code manually. 

So that brings me to a compositor question, that I have had a hard time finding good information on. My “clients” need to render into a buffer with an ARGB format. From there, each client has fullscreen access. In some cases, we “cut” holes in each of the fullscreen clients, so that when the clients are layered, other client’s data comes through (actually, the cuts we make are mutually exclusive, so when we are cutting holes, no two clients share the same pixels, and when all of the layers are combined, all pixels are accounted for). 

I’m struggling trying to figure out the best way to implement this. Should each client be rendering into RAM or VRAM? What is the best way to composite these fullscreen windows using Mir?

Thanks,
- Rian

> On Jan 23, 2014, at 9:35 PM, Daniel van Vugt <[email-masked]> wrote:
> 
> 
> Rian,
> 
>

---

From: Rian Quinn <[email-masked]>
Date: Sat, 25 Jan 2014 14:04:29 -0800 (PST)

At the moment I am trying to better understand how buffers are used and shared in Mir. I have spent the past couple of days doing nothing but reading the Mir source code, the DRM source code, and portions of the Mesa source code. Here is what I think I have learned so far, which will lead me to a question:

- The server creates the buffers. It can create either a hardware buffer, which is a gbm allocated “dumb” buffer, or a software buffer, which is nothing more than shared memory (in RAM). 
- When a hardware buffer is created, it uses DRM prime (drmPrimeHandleToFD) to create an FD for the “dumb" buffer. 
- The server then provides the client with a “ClientBuffer” which is an abstraction of the hardware / software buffer containing the information about the buffer (like format, stride, etc…) and its FD.
- To draw into this buffer, you need to call mir_surface_get_graphics_region which through some indirection, mmaps the buffer to a vaddr that can be written into. 

If you look at the basic.c demo, it creates a hardware buffer, and if you look at the fingerpaint.c demo, it creates a software buffer. If I modify the basic.c demo to call mir_surface_get_graphics_region, it fails on VMWare, saying that it could not mmap the buffer. It works fine if I change the basic.c to use a software buffer. 

Is this an issue with VMWare? Or am I fundamentally not understanding something about how hardware buffer’s are used? If I am… why would a client use hardware buffers if it cannot map the buffer to use it?

Thanks,
- Rian

> On Jan 24, 2014, at 7:21 AM, Rian Quinn <[email-masked]> wrote:
> 
>

---

From: Jakob Bornecrantz <[email-masked]>
Date: Sat, 25 Jan 2014 18:42:21 -0800 (PST)

----- Ursprungligt meddelande ----- 
>
> At the moment I am trying to better understand how buffers are used and
> shared in Mir. I have spent the past couple of days doing nothing but
> reading the Mir source code, the DRM source code, and portions of the Mesa
> source code. Here is what I think I have learned so far, which will lead me
> to a question:
>
> - The server creates the buffers. It can create either a hardware buffer,
> which is a gbm allocated “dumb” buffer, or a software buffer, which is
> nothing more than shared memory (in RAM).
> - The server then provides the client with a “ClientBuffer” which is an
> abstraction of the hardware / software buffer containing the information
> about the buffer (like format, stride, etc…) and its FD.
> - To draw into this buffer, you need to call mir_surface_get_graphics_region
> which through some indirection, mmaps the buffer to a vaddr that can be
> written into.
>
> If you look at the basic.c demo, it creates a hardware buffer, and if you
> look at the fingerpaint.c demo, it creates a software buffer. If I modify
> the basic.c demo to call mir_surface_get_graphics_region, it fails on
> VMWare, saying that it could not mmap the buffer. It works fine if I change
> the basic.c to use a software buffer.
>
> Is this an issue with VMWare? Or am I fundamentally not understanding
> something about how hardware buffer’s are used? If I am… why would a client
> use hardware buffers if it cannot map the buffer to use it?

Hia,

First of, its great that you have been able to get mir up and running
the vmwgfx driver. The bring up work was done by Thomas Hellström.

The vwmgfx driver doesn't support mmapping, this is mostly due to
the way the virtual hardware isn't able to map textures (called
surfaces in vmwgfx speak) which are different to memory buffers
(called dma buffers).

Cheers, Jakob

---

From: Alexandros Frantzis <[email-masked]>
Date: Sun, 26 Jan 2014 13:10:20 +0200

On Sat, Jan 25, 2014 at 02:04:29PM -0800, Rian Quinn wrote:
> At the moment I am trying to better understand how buffers are used
> and shared in Mir. I have spent the past couple of days doing nothing
> but reading the Mir source code, the DRM source code, and portions of
> the Mesa source code. Here is what I think I have learned so far,
> which will lead me to a question:
> 
>
> - The server creates the buffers. It can create either a hardware
> buffer, which is a gbm allocated “dumb” buffer, or a software buffer,
> which is nothing more than shared memory (in RAM). 

Using the mir_buffer_usage_hardware flag leads to the creation of a
normal gbm buffer, i.e., one suited for direct usage by the GPU. This is
*not* a gbm "dumb" buffer.

You are correct that using mir_buffer_usage_software creates a shared
memory (RAM) buffer.

> - When a hardware buffer is created, it uses DRM prime
> (drmPrimeHandleToFD) to create an FD for the “dumb" buffer. 

Correct, but as noted above, it's not a gbm "dumb" buffer, but a normal
gbm buffer.

> - The server then provides the client with a “ClientBuffer” which is
> an abstraction of the hardware / software buffer containing the
> information about the buffer (like format, stride, etc…) and its FD.

> - To draw into this buffer, you need to
> call mir_surface_get_graphics_region which through some indirection,
> mmaps the buffer to a vaddr that can be written into. 

Not correct for hardware buffers, see below for more. This only works
for software buffers, in which case the fd passed to the client is a
shared memory fd which can be mapped. In the case of hardware buffers
it's a "prime" fd which in general doesn't support sensible mapping of
that kind.

> If you look at the basic.c demo, it creates a hardware buffer, and if
> you look at the fingerpaint.c demo, it creates a software buffer. If I
> modify the basic.c demo to call mir_surface_get_graphics_region, it
> fails on VMWare, saying that it could not mmap the buffer. It works
> fine if I change the basic.c to use a software buffer. 
>
> something about how hardware buffer’s are used? If I am… why would a
> client use hardware buffers if it cannot map the buffer to use it?

In general, buffers created for direct GPU usage cannot be reasonably
mmap-ed and their pixels accessed directly. Even if the mapping
operation itself is supported by the driver, the contents of the mapped
area are usually not laid out in memory in a linear fashion (i.e. they
have some sort of tiling), and therefore not useful for pixel
manipulation.

The only way to draw into a hardware buffer in Mir is to go through one
of the "accelerated" APIs supported by Mesa EGL (e.g. OpenGL). The
example at examples/scroll.c shows how to do that.

Bottom line: the failure to mmap is expected for hardware buffers, it's
not a VMWare issue; the mir_surface_get_graphics_region call is only
meaningful for Mir software buffers.

Thanks,
Alexandros

---

From: Thomas Hellstrom <[email-masked]>
Date: Sun, 26 Jan 2014 13:13:52 +0100

> meaningful for Mir software buffers.

I guess the bottom line is, that if you share accelerated buffers (which
you probably want for performance reasons), and you need to draw using
CPU to these buffers, you need to use an accelerated API (GL, GLES?) and
use whatever functionality is present depending on whether the buffer is
represented as a texture or a renderbuffer: tex(Sub)Image, drawPixels etc.

Thanks,
/Thomas

---

From: Rian Quinn <[email-masked]>
Date: Sun, 26 Jan 2014 12:17:25 -0800 (PST)

I went back and re-read the gbm code, and noticed that it only creates the dumb buffer if you set the GBM_BO_USE_WRITE flag, which means that you can use the gbm_bo_write command which takes a char*. So that makes sense to me now. What I guess I was looking for, was something more like DirectDraw, where a client could get access to device memory, and render directly into for 2D. 

In my case I’m not really interested in 3D, but instead my clients are rendering using the VGA spec, 2D pixel data. I’m trying to figure out the best way to reduce the number of memcpys. At the moment, I am going to assume that I need to use a software buffer for the clients, and the server will copy the pixel data to the scanout buffer. 

That being the case, what is the best method for transferring this ARGB pixel data from shared RAM, onto a scanout buffer? From what I understand, glTexSubImage2D does a memcpy via the CPU. Ideally, I would prefer this transfer to be done via DMA and not the CPU. Keep in mind that each client is rendering as a VGA device, so I don’t really have control of “when” the client decides to modify it’s char*.

After reading a lot of the compositor code in Mir, I so far have not been able to locate how this is done for a software buffer vs. a hardware buffer.

Also, is there an example of how someone would use Mir to composite multiple clients. From what I can tell, all of the server examples just call run_mir, and don’t really do anything. 

Thanks
- Rian

> On Jan 26, 2014, at 6:10 AM, Alexandros Frantzis <[email-masked]> wrote:
> 
>

---

From: Daniel van Vugt <[email-masked]>
Date: Tue, 28 Jan 2014 09:35:14 +0800

Rian,

The distinction between "software" and "hardware" buffers in Mir is 
confusing, I know, due to the vague names. What it actually means is:

mir_buffer_usage_software: Client draws individual pixels and the server 
composites this (in hardware still). Presently glTexImage2D, I know. :/

mir_buffer_usage_hardware: Client never has access to address individual 
pixels and must use OpenGL.

So if you want to draw the pixels yourself then you must use 
mir_buffer_usage_software. If you feel glTexImage2D is too slow at that, 
then it's an enhancement for Mir later. But not something that's visible 
to the client.

To see the various implementations just search for the "bind_to_texture" 
method:

grep -r '::bind_to_texture' *

- Daniel

On 27/01/14 04:17, Rian Quinn wrote:
> I went back and re-read the gbm code, and noticed that it only creates
> the dumb buffer if you set the GBM_BO_USE_WRITE flag, which means that
> you can use the gbm_bo_write command which takes a char*. So that makes
> sense to me now. What I guess I was looking for, was something more like
> DirectDraw, where a client could get access to device memory, and render
> directly into for 2D.
>
> In my case I’m not really interested in 3D, but instead my clients are
> rendering using the VGA spec, 2D pixel data. I’m trying to figure out
> the best way to reduce the number of memcpys. At the moment, I am going
> to assume that I need to use a software buffer for the clients, and the
> server will copy the pixel data to the scanout buffer.
>
> That being the case, what is the best method for transferring this ARGB
> pixel data from shared RAM, onto a scanout buffer? From what I
> understand, glTexSubImage2D does a memcpy via the CPU. Ideally, I would
> prefer this transfer to be done via DMA and not the CPU. Keep in mind
> that each client is rendering as a VGA device, so I don’t really have
> control of “when” the client decides to modify it’s char*.
>
> After reading a lot of the compositor code in Mir, I so far have not
> been able to locate how this is done for a software buffer vs. a
> hardware buffer.
>
> Also, is there an example of how someone would use Mir to composite
> multiple clients. From what I can tell, all of the server examples just
> call run_mir, and don’t really do anything.
>
> Thanks
> - Rian
>
>> On Jan 26, 2014, at 6:10 AM, Alexandros Frantzis
>> <[email-masked]> wrote:
>>

---

From: Rian Quinn <[email-masked]>
Date: Mon, 27 Jan 2014 17:43:18 -0800 (PST)

Awesome. It all makes a lot more sense to me now. We will likely be using shared memory. 

Lol…. I was actually excited about glTexImage2D with PBOs to do the composition. Is there a better way to do this? 

- Rian

> On Jan 27, 2014, at 8:35 PM, Daniel van Vugt <[email-masked]> wrote:
> 
> 
> Rian,
> 
>

---

From: Daniel van Vugt <[email-masked]>
Date: Tue, 28 Jan 2014 09:44:43 +0800

Incidentally, Mir had the ability to bypass software buffers until 
recently (before the SHM work). Bypass means no compositing required, no 
texture upload, just dump it (fullscreen surfaces) to the display.

However even when we could, I disabled bypass of software buffers 
because it was apparently always slower than compositing. I guess the 
bus doesn't like you poking pixels individually into VRAM. It seems to 
prefer a single copy of the whole buffer, for performance.

That all said, there are other ways to avoid glTexImage2D uploads of 
software buffers. We just haven't implemented them yet.

---

From: Daniel van Vugt <[email-masked]>
Date: Tue, 28 Jan 2014 10:02:30 +0800

Before anyone corrects me... I know mir_buffer_usage_hardware is 
intentionally vague and not called mir_buffer_usage_opengl for a reason. 
The reason is that mir_buffer_usage_hardware is not limited to OpenGL. 
In XMir for example we use mir_buffer_usage_hardware and the various DDX 
drivers implement their own acceleration.

---

From: Christopher James Halse Rogers <[email-masked]>
Date: Tue, 28 Jan 2014 15:55:18 +1100

> In my case I’m not really interested in 3D, but instead my clients are rendering using the VGA spec, 2D pixel data. I’m trying to figure out the best way to reduce the number of memcpys. At the mom…

That sounds like the appropriate approach.

> That being the case, what is the best method for transferring this ARGB pixel data from shared RAM, onto a scanout buffer? From what I understand, glTexSubImage2D does a memcpy via the CPU. Ideally…

I can't remember if TexImage2D mandates anything that prohibits DMA; I'm
pretty sure _something_ in the radeon mesa driver was doing DMA, but I
wasn't paying that much attention.

That said, unless you're really, really hurting for CPU a CPU memcpy
will be simple and fast.

It sounds like what you want to do is implement a GL-less renderer in
Mir; this should be reasonably easy (and if it isn't, we should make it
so). I'd suggest using pixman, but even that might be overkill - it
doesn't sound like you're planning to do *any* blending, just
copy-or-not.

If you're using Mir then you do have control over when clients modify
their buffers - mir_surface_swap_buffers submits their existing buffer
and then gets a new one. Once they've called mir_surface_swap_buffers,
you can assume that the buffer they submitted won't change.

> After reading a lot of the compositor code in Mir, I so far have not been able to locate how this is done for a software buffer vs. a hardware buffer.

We upload with TexImage2D IIRC.

> Also, is there an example of how someone would use Mir to composite multiple clients. From what I can tell, all of the server examples just call run_mir, and don’t really do anything. 

All of the server examples are just that - servers. You can connect
clients to them, and they'll be composited.

---

From: Daniel van Vugt <[email-masked]>
Date: Wed, 29 Jan 2014 09:45:12 +0800

For anyone not following the bug progress, non-root clients on a root 
server do in fact work perfectly. Just our documentation was wrong.

For now, if you need to connect a non-root client to a root server you 
need to explicitly specify the socket to connect to:
     myclient -m /tmp/mir_socket