1
0
Fork 0
Commit graph

7 commits

Author SHA1 Message Date
Ray Strode
bed82427c6 wayland: change accessible boolean to use_count counter
Since a buffer can be used by multiple surfaces at once,
we need to release the buffer only after all surfaces
are finished with it.  Currently we track whether or
not to release the buffer based on the accessible boolean.
This commit changes it to a counter to accomodate multiple
users.

Also, each surface needs to know whether not it is done with
the buffer, so this commit adds a buffer_used boolean to the
surface state.

https://bugzilla.gnome.org/show_bug.cgi?id=761613
2016-02-19 08:57:56 -05:00
Ray Strode
e097bc8353 wayland: get rid of buffer->copied_data boolean
We currently track whether or not a buffer can be released early
by looking at the copied_data boolean on the buffer.  This boolean
is, practically speaking, always set to TRUE for shm buffers and is
always false otherwise.

We can just as easily check if the buffer is a shm buffer to decide
whether or not to do an early release.  That's better from a
theoretical point of view since copied_data assumes a 1-to-1
relationship between surface and buffer, which may not actually hold.

This commit drops copied_data and changes the check to instead see
if the buffer is shm.

https://bugzilla.gnome.org/show_bug.cgi?id=761613
2016-02-19 08:57:56 -05:00
Ray Strode
7adbb58736 wayland: don't prematurely release EGL buffers
commit 0165cb6974 changed
mutter to release committed shm buffers as soon as they were
uploaded to the GPU.

It also inadvertently changed mutter to prematurely
release EGL buffers (which never get copied, but get used
directly).

This commit corrects that mistake.

https://bugzilla.gnome.org/show_bug.cgi?id=761312
2016-02-02 11:15:43 -05:00
Ray Strode
0165cb6974 wayland: release buffer after processing commit
When a client is ready for the compositor to read a surface's
shared memory buffer, it tells the compositor via
wl_surface_commit.

From that point forward, the baton is given to the compositor:
it knows it can read the buffer without worring about the client
making changes out from under it.

After the compositor has uploaded the pixel contents to the video
card it is supposed to release the buffer back to the client so that
the client can reuse it for future use.

At the moment, mutter only releases the buffer when a new buffer
is attached.  This is problematic, since it means the client has
to have a second buffer prepared before the compositor gives the
first one back.  Preparing the second buffer potentially involves
copying megabytes of pixel data, so that's suboptimal, and there's
no reason mutter couldn't release the buffer earlier.

This commit changes mutter to release a surface's buffer as soon
as it's done processing the commit request.

https://bugzilla.gnome.org/show_bug.cgi?id=761312
2016-02-01 14:16:17 -05:00
Marek Chalupa
b6d070b06f wayland: Seal SHM buffers before access
If wayland client lies about size of given buffer, compositor could touch bad
memory and get SIGBUS. Wayland provides simple API to fix it - so fix it!

[1] http://cgit.freedesktop.org/wayland/wayland/tree/src/wayland-server.h#n416
[2] http://lists.freedesktop.org/archives/wayland-devel/2013-November/012159.html

Signed-off-by: Marek Chalupa <mchqwerty@gmail.com>

https://bugzilla.gnome.org/show_bug.cgi?id=727893
2015-01-09 16:39:37 -08:00
Jasper St. Pierre
f658740043 wayland: Move some buffer manipulation functions to meta-wayland-buffer 2014-10-07 20:42:27 -07:00
Jasper St. Pierre
c1613a16c0 wayland: Put the MetaWaylandBuffer implementation in a new file 2014-10-07 20:42:27 -07:00