Commits on Source (31)
-
Daniel Stone authored
We can't try to attach a dmabuf that we never imported. Signed-off-by: Daniel Stone <daniels@collabora.com>
efd6aae9 -
Daniel Stone authored
The comment about needing to have destroyed images is somewhat less true now that we actively avoid doing so. Signed-off-by: Daniel Stone <daniels@collabora.com> Fixes: 0b51b02c ("gl-renderer: Don't re-import dmabufs")
f8ac6f94 -
Daniel Stone authored
We already have the buffer in the caller, and every no-op implementation will want to access the buffer. So might as well pass it. Signed-off-by: Daniel Stone <daniels@collabora.com>
12675ed1 -
Daniel Stone authored
All the callers of flush_damage guarantee we'll have a buffer. Signed-off-by: Daniel Stone <daniels@collabora.com>
fec04008 -
Daniel Stone authored
When we first see a buffer attached, we create a weston_buffer for it. The weston_buffer doesn't contain any useful information in and of itself; that's left to renderers to populate later. Switch this to doing it in the core at the first opportunity, at least for SHM and dmabuf buffers; EGL buffers will follow in the next commit. Signed-off-by: Daniel Stone <daniels@collabora.com>
ca9bb01f -
Daniel Stone authored
Make sure we only import dmabufs where the underlying pixel_format is known: if we can't reason about the buffer content, we're not entirely likely to be able to display it well. Signed-off-by: Daniel Stone <daniels@collabora.com>
f49d6f47 -
Daniel Stone authored
Rather than only filling weston_buffer information when we first come to use it, add an explicit hook so we can fill the dimensions the first time the buffer's attached. Signed-off-by: Daniel Stone <daniels@collabora.com>
1d5f8af8 -
Daniel Stone authored
Rather than open-coding various resource -> type accessors, just stick a type enum in the buffer struct. Signed-off-by: Daniel Stone <daniels@collabora.com>
34cd0d11 -
Daniel Stone authored
Rather than calling accessors (wl_shm_buffer_get etc) to figure out which type our buffer is, just look in the structure. Signed-off-by: Daniel Stone <daniels@collabora.com>
fef8bb27 -
Daniel Stone authored
Promote these to weston_buffer rather than burying them in the renderers and backends. Signed-off-by: Daniel Stone <daniels@collabora.com>
6dcf3eac -
Daniel Stone authored
y_inverted meant that the buffer's origin was (0,0), and non-inverted meant that the buffer's origin was (0,height). In practice, every buffer was 'inverted' into our natural co-ordinate space that we use everywhere. Switch to using an explicit origin enum to make this more clear. Signed-off-by: Daniel Stone <daniels@collabora.com>
4f88b265 -
Daniel Stone authored
We already have the format; no need to go chasing it again. Signed-off-by: Daniel Stone <daniels@collabora.com>
7506cf52 -
Daniel Stone authored
Now that we have this generically available, use it rather than calling into per-buffer getters. Signed-off-by: Daniel Stone <daniels@collabora.com>
0a880240 -
Daniel Stone authored
Try to print out as much information as we can about the buffer. Signed-off-by: Daniel Stone <daniels@collabora.com>
1d9c62b5 -
Daniel Stone authored
Just pull it from the structure rather than pulling it in externally. Signed-off-by: Daniel Stone <daniels@collabora.com>
2dcfe723 -
Daniel Stone authored
Break a giant if statement out into a more legible grouping. Signed-off-by: Daniel Stone <daniels@collabora.com>
231a67ff -
Daniel Stone authored
Signed-off-by: Daniel Stone <daniels@collabora.com>
e9c792ed -
Daniel Stone authored
We currently allow a weston_buffer to outlive the underlying wl_buffer iff the renderer/backend has cached it. Currently the 'is this buffer valid?' test relies on looking for the validity of the weston_buffer itself; shift these tests to looking at the validity of the underlying resource. Signed-off-by: Daniel Stone <daniels@collabora.com>
7b3efabd -
Daniel Stone authored
Make sure we don't die if we're asked to flush the damage on a SHM buffer which has subsequently been destroyed. Signed-off-by: Daniel Stone <daniels@collabora.com>
d2a858e8 -
Daniel Stone authored
Keep the weston_buffer alive for as long as at least one of the underlying wl_buffer or a backend usage exists. Signed-off-by: Daniel Stone <daniels@collabora.com>
7e904330 -
Daniel Stone authored
Add a mode argument to weston_buffer_reference which indicates whether a buffer's storage may/will be accessed, or whether the underlying storage will no longer be accessed, e.g. because it has been copied. This will be used to retain a pointer to the weston_buffer whilst being able to send a release event to the client. Signed-off-by: Daniel Stone <daniels@collabora.com>
fdc7b9c3 -
Daniel Stone authored
In the original conception, a weston_buffer_reference indicated that the underlying contents of the wl_buffer would or could be accessed, so wl_buffer.release must not be sent until the last reference was released, as the compositor may still use it. This meant that renderers or backends which copied the buffer content - such as the GL renderer with SHM buffers - could only send a buffer release event to the client by 'losing' the buffer reference altogether. The main side effect is that `weston-debug scene-graph` could not show any information at all about SHM buffers when using the GL renderer, but it also meant that renderers and backends grew increasingly exotic structures to cache information about the buffer. Now that we have an additional buffer-reference mode (still referring to the weston_buffer/wl_buffer, but not going to access its content), we can allow the weston_buffer_reference and weston_buffer to live as long as the buffer itself, even if we do send a release event. This will enable a bunch of backend and renderer deduplication, as well as finally making scene-graph more useful. Signed-off-by: Daniel Stone <daniels@collabora.com>
a4290820 -
Daniel Stone authored
When the renderer/backend indicate that they do not need a surface's buffer content to be preserved, most often because they have copied it, simply downgrade the buffer reference to 'will not access', rather than drop the buffer reference altogether. Signed-off-by: Daniel Stone <daniels@collabora.com>
7a27f6cb -
Daniel Stone authored
Currently solid-colour displays (e.g. the background for fullscreen views) is implemented by a special-case weston_surface which has no buffer attached, with a special punch-through renderer callback to set the colour. Replace this with a weston_buffer type explicitly specifying the solid colour, which helps us eliminate yet more special cases in renderers and backends. This is not handled yet in any renderer or backend, however it is also not used by anything yet. Following commits add support to the renderers and backends. Signed-off-by: Daniel Stone <daniels@collabora.com>
43715ff0 -
Daniel Stone authored
Same as surface_set_color. Signed-off-by: Daniel Stone <daniels@collabora.com>
465f4a25 -
Daniel Stone authored
Just implemented via the same mechanism as surface_set_color. Signed-off-by: Daniel Stone <daniels@collabora.com>
d82d74e7 -
Daniel Stone authored
Refactor the buffer-type check slightly so we can handle solid-color buffers, which we do exactly nothing with. Signed-off-by: Daniel Stone <daniels@collabora.com>
493a4c01 -
Daniel Stone authored
The Pixman renderer keeps its own reference to buffers when attached to surfaces, through its surface state: just use that instead. Signed-off-by: Daniel Stone <daniels@collabora.com>
b38b735e -
Daniel Stone authored
When we're checking to see if a view is suitable to go on a plane, check for (and reject) solid-colour buffers. Signed-off-by: Daniel Stone <daniels@collabora.com>
82b64672 -
Daniel Stone authored
Rather than punching through to set the surface as a solid colour, attach an actual weston_buffer to it instead. This becomes the first user of attaching non-client-generated buffers to a weston_surface. As a result, it is necessary to introduce a function which will allow compositors and shells to attach a buffer to a surface. weston_surface_attach_solid() is therefore introduced as a special-purpose helper which will attach a solid buffer to a weston_surface. It is not intended as a general-purpose mechanism to allow compositors to attach client-generated buffers to surfaces, as doing so would have unknown effects on this core part of the compositor itself. Signed-off-by: Daniel Stone <daniels@collabora.com>
4d426ab6 -
Daniel Stone authored
Don't do this; instead, create a solid-colour buffer and attach it to the surface explicitly. Signed-off-by: Daniel Stone <daniels@collabora.com>
b5605ccd