Improving next_buffer() rpc

Kevin DuBois kevin.dubois at
Tue Jul 8 13:10:03 UTC 2014

Hello mir team,

In order to get the next buffer for the client, we currently have:

rpc next_buffer(SurfaceId) returns (Buffer);

which is problematic for me in working on [1] because this implicitly
releases the buffer from the client side, whereas in working on that
performance improvement, I have to send a fd back to the server. So I was
thinking of adding an rpc method more like:

rpc exchange_buffer(Buffer) returns (Buffer);

This would be sufficient to pass the fd fence back, and the buffer id in
the Buffer protocol message would be sufficient for the server to figure
out which surface has sent back its buffer. (given the global buffer id's
we're using)

This does not address the problem noted in:
but I think that might be better addressed by having an exchange type rpc
call (explicit or implicit) and negotiating/increasing how many buffers the
client owns somehow else.

This seems like something that could have diverse opinions, so I'm hoping
to get some input on the protocol change here first.


"[kdub] fencing improvements for clients add the ipc plumbing"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Mir-devel mailing list