This commit does not break ABI. It merely changes the types of some things
and adds a wl_shm_buffer_get function.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
This commit adds a wl_resource_init function for initializing wl_resource
structures similar to wl_client_add_object.
From this commit forward, wl_resource structures should not be initialized
manually, but should use wl_resource_init. In the event of a change to the
wl_resource structure, this allows us to protect against regressions by filling
in added fields with reasonable defaults. In this way, while changing
wl_object or wl_resource still constitutes an ABI break, compositors following
this rule will only need to be recompiled in order to properly link against the
new version.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
This avoids a valgrind error like:
==31496== Conditional jump or move depends on uninitialised value(s)
==31496== at 0x407620: weston_buffer_post_release (compositor.c:928)
==31496== by 0x406AEB: weston_surface_attach (compositor.c:725)
==31496== by 0x409EB8: pointer_attach (compositor.c:2009)
==31496== by 0x34ECE05D63: ffi_call_unix64 (unix64.S:75)
==31496== by 0x34ECE05784: ffi_call (ffi64.c:486)
==31496== by 0x5674C4D: wl_closure_invoke (connection.c:770)
==31496== by 0x566ECCB: wl_client_connection_data (wayland-server.c:255)
==31496== by 0x56722F9: wl_event_source_fd_dispatch (event-loop.c:79)
==31496== by 0x5672C99: wl_event_loop_dispatch (event-loop.c:410)
==31496== by 0x56705FF: wl_display_run (wayland-server.c:1004)
==31496== by 0x40C775: main (compositor.c:2937)
==31496== Uninitialised value was created by a heap allocation
==31496== at 0x4A074CD: malloc (vg_replace_malloc.c:236)
==31496== by 0x5670EA7: shm_pool_create_buffer (wayland-shm.c:113)
==31496== by 0x34ECE05D63: ffi_call_unix64 (unix64.S:75)
==31496== by 0x34ECE05784: ffi_call (ffi64.c:486)
==31496== by 0x5674C4D: wl_closure_invoke (connection.c:770)
==31496== by 0x566ECCB: wl_client_connection_data (wayland-server.c:255)
==31496== by 0x56722F9: wl_event_source_fd_dispatch (event-loop.c:79)
==31496== by 0x5672C99: wl_event_loop_dispatch (event-loop.c:410)
==31496== by 0x56705FF: wl_display_run (wayland-server.c:1004)
==31496== by 0x40C775: main (compositor.c:2937)
The wayland protocol, as X, uses timestamps to match up certain
requests with input events. The problem is that sometimes we need to
send out an event that doesn't have a corresponding timestamped input
event. For example, the pointer focus surface goes away and new
surface needs to receive a pointer enter event. These events are
normally timestamped with the evdev event timestamp, but in this case,
we don't have a evdev timestamp. So we have to go to gettimeofday (or
clock_gettime()) and then we don't know if it's coming from the same
time source etc.
However for all these cases we don't need a real time timestamp, we
just need a serial number that encodes the order of events inside the
server. So we introduce a serial number mechanism that we can use to
order events. We still need real-time timestamps for actual input
device events (motion, buttons, keys, touch), to be able to reason
about double-click speed and movement speed so events that correspond to user input carry both a serial number and a timestamp.
The serial number also give us a mechanism to key together events that
are "logically the same" such as a unicode event and a keycode event,
or a motion event and a relative event from a raw device.
There's a big cost to setting up and tearing down a mmap and faulting in
the pages to back it. For cases where we're continuously reallocating
shm wl_buffers (resizing a surface, typically) it is a big performance
improvement to be able to reuse a mmap area. This change makes the shm
buffer allocation a two step process: first allocate a wl_shm_pool, then
allocate a buffer from the pool. The wl_shm_pool encapsulate the shared
memory pool, and lets clients allocate wl_buffers backed by chunks of that
memory. Buffers are allocated at an offset into the pool, so it's possible
to create multiple buffers from one pool, for example for icons or cursor
images.
The visual interface was meant to be a generic mechanism for
specifying the content of a buffer. It goes back to before we had the
buffer factory interfaces (like wl_drm and wl_shm) and we wanted to
keep it open-ended enough that yuv, png or even svg buffer or so would
be possible.
Now that we have the buffer abstraction, we can add different buffer
types by introducing new interfaces that create buffers. It only
makes sense to leave it to those interfaces to specify the contents of
the buffers.
For wl_shm, this means that we now just specify the pixel format using
an enum. For EGL buffers, the exact pixel formats are controlled by
the implementation (part of wl_drm and similar), and from the client
point of view, everything is controlled using EGLConfigs.
