Fix few typos in wl_buffer description.
Mention backing storage in wl_buffer.destroy.
Try to clarify the wl_buffer.release semantics by not explaining what
*might* happen. It is important to not suggest, that if release does not
come before frame callback, it will not come before attaching a new
buffer to the surface. We want to allow the following scenario:
The compositor is able to texture from wl_buffers directly, but it also
keeps a copy of the surface contents. The copy is updated when the
compositor is idle, to avoid the performance hit on
wl_surface.attach/commit. When the copy completes some time later, the
server sends the release event. If the client has not yet allocated a
second buffer (e.g. it updates rarely), it can reuse the old buffer.
Reported-by: John Kåre Alsaker <john.kare.alsaker@gmail.com>
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
wl_surface.commit itself does not force any repainting unless there is
damage, so change the wording to not imply repainting.
Reported-by: John Kåre Alsaker <john.kare.alsaker@gmail.com>
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
Explicitly say what happens with the wl_buffer.release event, if you
attach several wl_buffers without a commit in between.
Reported-by: David Herrmann <dh.herrmann@googlemail.com>
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
The previous clarification did not follow the current implementation in
Weston, where when a surface stops being a cursor or an icon, it becomes
a plain unmapped surface again.
Rewrite the related paragraphs, and fix some typos while at it.
For start drag, make it explicit of which surface argument we are
talking about.
v2:
Make the input region undefined when the use ends. Most likely no-one
will re-use these surfaces for anything else than the same use case, so
leave some slack for the implementations to avoid useless work on
resetting the regions.
Reported-by: Ander Conselvan de Oliveira <conselvan2@gmail.com>
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
Spell out exactly when a client may re-use a wl_buffer or its backing
storage. Mention the optimization for GL-compositor with wl_shm-clients.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
This change breaks the protocol.
The current protocol is racy in that updates to surface content and
surface state (e.g. damage, input and opaque regions) are not guaranteed
to happen at the same time. Due to protocol buffering and handling
practices, the issues are very hard to trigger.
Committing damage to a surface at arbitrary times makes it hard to
track when the wl_buffer is being read by the server, and when it is
safe to overwrite (the case of wl_shm with a single buffer reused
constantly).
This protocol change introduces the concept of double-buffered state.
Such state is accumulated and cached in the server, unused, until the
final commit request. The surface will receive its new content and apply
its new state atomically.
A wl_surface.commit request is added to the protocol. This is thought to
be more clear, than having wl_surface.attach committing implicitly, and
then having another request to commit without attaching, as would be
required for a GL app that wants to change e.g. input region without
redrawing.
When these changes are implemented, clients do not have to worry about
ordering damage vs. input region vs. attach vs. ... anymore. Clients set
the state in any order they want, and kick it all in with a commit.
The interactions between wl_surface.attach, (wl_surface.commit,)
wl_buffer.release, and wl_buffer.destroy have been undocumented. Only
careful inspection of the compositor code has told when a wl_buffer is
free for re-use, especially for wl_shm and wrt. wl_surface.damage.
Try to clarify how it all should work, and what happens if the wl_buffer
gets destroyed.
An additional minor fix: allow NULL argument to
wl_surface.set_opaque_region. The wording in the documentation already
implied that a nil region is allowed.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
The only way to make the global object listener interface thread safe is to
make it its own interface and make different listeners different wl_proxies.
The core of the problem is the callback we do when a global show up or
disappears, which we can't do with a lock held. On the other hand we can't
iterate the global list or the listener list without a lock held as new
globals or listeners may come and go during the iteration.
Making a copy of the list under the lock and then iterating after dropping
the lock wont work either. In case of the listener list, once we drop the
lock another thread may unregister a listener and destroy the callbackk
data, which means that when we eventually call that listener we'll pass it
free memory and break everything.
We did already solve the thread-safe callback problem, however. It's what
we do for all protocol events. So we can just make the global registry
functionality its own new interface and give each thread its own proxy.
That way, the thread will do its own callbacks (with no locks held) and
destroy the proxy when it's no longer interested in wl_registry events.
This makes the scanner generate the code and meta data to send the
interface name and version when we pass a typeless new_id. This way, the
generic factory mechanism provided by wl_display.bind can be provided by
any interface.
My vim spell checker is able to find typos of xml files after adding "syn spell
toplevel" to ~/.vim/after/syntax/xml.vim
aah, and Wayland is capital letter :)
Signed-off-by: Tiago Vignatti <tiago.vignatti@intel.com>
Change the description of pointer.set_cursor() so that a client without
pointer focus but that currently owns the pointer surface can update the
hotspot using it.
The set_transient and set_popup requests take a wl_shell_surface as
the parent surface argument. We don't need the parent surface to be
a shell surface and this restricts the types of surfaces we can use
the transient and popup surface types on.
With this event, the compositor generates one canonical keymap for all
clients, and then sends an mmap()able fd over the wire, rather than all
the clients generating possibly disparate keymaps.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
This event sends the current keyboard modifier/group state from the
compositor to the client, allowing all clients to have a consistent view
of the keyboard state (e.g. current layout, Caps Lock, et al). It
should be sent after a keyboard enter event, and also immediately after
any key event which changes the modifier state.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Properly handle a drag with no data source, i.e., don't crash and send
events only to the client that initiated the drag. This way a client can
do self drag and drop without offering anything to other clients.
wl_input_device has been both renamed and split. wl_seat is now a
virtual object representing a group of logically related input devices
with related focus.
It now only generates one event: to let clients know that it has new
capabilities. It takes requests which hand back objects for the
wl_pointer, wl_keyboard and wl_touch interfaces it exposes which all
provide the old input interface, just under different names.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
These events let us track when a surface enters or leaves the scanout region of
an output. This way if a surface moves to another output and that output is on
a different card, we can suggest the toolkit reallocate its buffers
appropriately.
Signed-off-by: Casey Dahlin <cdahlin@redhat.com>
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.
To reproduce, invoke distcheck from an out-of-source tree.
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Gaetan Nadon <memsize@videotron.ca>
