Add note about what all wl_pointer.release does. Mainly that
it destroys the proxy object, so programmer must not call
wl_pointer_destroy() on the pointer any further.
Signed-off-by: Marek Chalupa <mchqwerty@gmail.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Change wording to be more consistent with other parts of the subsurface
protocol. Before this change, wl_subsurface.set_position explicitly
stated that the new state was to be applied on the parents
wl_surface.commit and wl_subsurface.place_above/below only said "on
the next commit of the parent surface". What "committed" means is
ambiguous considering that a wl_surface.commit actually defers the
actual commit when in synchronized mode, but the intention has always
been that placement of a subsurface should be considered part of its
content, i.e. placement state should be applied when other state
(buffer, regions). This patch makes that more clear.
Note that prior to this patch, one could correctly have interpreted
the protocol meaning that placements operations takes effect explicitly
on wl_surface.commit of the parent surface no matter whether other state
of the parent surface is applied at that point. This patch clarifies that
that is not the case.
https://bugs.freedesktop.org/show_bug.cgi?id=88857
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Acked-by: Jasper St. Pierre <jstpierre@mecheye.net>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Clarify that a client receiving a wl_data_device.selection event must
destroy the data_offer of the previous wl_data_device.selection event,
if any.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
On the interfaces where it was missing:
- wl_data_device
- wl_shell
- wl_pointer
add an error code for requests that set a wl_surface role when the
wl_surface already has a different role.
This is needed for compositors to appropriately report wl_surface
role violations.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Jasper St. Pierre <jstpierre@mecheye.net>
Acked-by: Jason Ekstrand <jason.ekstrand@intel.com>
Now that we have defined "role", use the term.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
Reword the conditions to make use of the definition of "role".
It is still forbidden to create more than one wl_subsurface for a
wl_surface at a time.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
Now that we have defined "role", use the term.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
Now that we have defined "role", use the term.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
Define what a role is, and what restrictions there are.
A change to existing behaviour is that a role cannot be changed at all
once set. However, this is unlikely to cause problems, as there is no
reason to re-use wl_surfaces in clients.
v2: give more concrete examples of roles, define losing a role, Jasper
rewrote the paragraph on how a role is set.
v3: make role permanent, there is no such thing as "losing a role".
Re-issuing the same role again must be allowed for wl_pointer.set_cursor
et al. to work.
v4: clarify the semantics of destroying a role object.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
In the process wl_keyboard's version has been incremented. Given
clients get the wl_keyboard from wl_seat without a version, wl_seat's
version has also been incremented (wl_seat version 4 implies
wl_keyboard version 4).
earlier Acked-by: Daniel Stone <daniel@fooishbar.org>
Reviewed-by: Pekka Paalanen <ppaalanen@gmail.com>
The "release" message of wl_pointer, wl_keyboard and wl_touch introduced
in version 3 was placed first in the respective interface XML element,
causing wayland-scanner to misbehave and set the version number of the
"release" message to all subsequent messages with no explicitly specified
"since" version.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
"the callback event will arrive after the next output refresh" is wrong,
if you interpret "output refresh" as framebuffer flip or the moment when
the new pixels turn into light the first time. Weston has probably never
worked this way.
Weston triggers the frame callbacks when it submits repainting commands
to the GPU, which is before the framebuffer flip.
Strike the incorrect claim, and the rest of the paragraph which no
longer offers useful information.
As a replacement, expand on the "throttling and driving animations"
characteristic. The main purpose is to let clients animate at the
display refresh rate, while avoiding drawing frames that will never be
presented.
The new claim is that the server should give some time between
triggering frame callbacks and repainting itself, for clients to draw
and commit. This is somewhat intimate with the repaint scheduling
algorithm a compositor uses, but hopefully the right intention.
Another point of this update is to imply, that frame callbacks should
not be used to count compositor repaint cycles nor monitor refresh
cycles. It has never been guaranteed to work. Removing the mention of
frame callback without an attach hopefully discourages such use.
v2: Don't just remove a paragraph, but add useful information about the
request's intent.
v3: Specify the order of posting frame callbacks.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Cc: Axel Davy <axel.davy@ens.fr>
Cc: Jason Ekstrand <jason@jlekstrand.net>
Same reason as commit cd31275f28b0a04d2ec5426dc81e875197b47e52 from weston:
The scanner needs to be good enough. If it crashes or fails to report
invalid input, that needs to get fixed.
Clarify when the pending and current buffer transform and scale values
change, and what exactly happens on commit.
This matches what Weston currently does.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
"data" is the name of the void* argument in the implementation.
While we probably shouldn't use such an easily-collidable name,
just rename the callback's argument to callback_data for now.
Make it clear that multiple requests before commit are allowed and how it
is handled.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Jasper St. Pierre <jstpierre@mecheye.net>
Clarify some semantics of wl_subsurface.place_below and
wl_subsurface.place_below that were not specified.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Jasper St. Pierre <jstpierre@mecheye.net>
The sub-surface protocol was originally committed into Weston on May
10th, 2013, in commit 2396aec6842c709a714f3825dbad9fd88478f2e6. The
design for the protocol had started in the beginning of December 2012. I
think it is high time to move this into the core now.
This patch copies the sub-surface protocol as it was in Weston on Nov
15th, 2013, into Wayland. Weston gets a patch to remove the protocol from
there.
Sub-surface is a wl_surface role. You create a wl_surface as usual, and
assign it the sub-surface role and a parent wl_surface. Sub-surfaces are
an integral part of the parent surface, and stay glued to the parent.
For window management, a window is the union of the top-level
wl_surface and all its sub-surfaces. Sub-surfaces are not clipped to the
parent, and the union of the surface tree can be larger than the
(top-level) wl_surface at its root.
The representative use case for sub-surfaces is a video player window.
When the video content is given its own wl_surface, there is no need to
modify the video frame contents after decoding or copy them into a whole
window sized buffer before submitting it to the compositor. This allows
efficient, zero-copy video presentation paths, where video decoding
hardware produces a (YUV) buffer, which eventually ends up in a
(YUV-capable) hardware overlay and is scanned out directly.
This can also be used for zero-copy presentation of windowed OpenGL
content, where the OpenGL rendering engine does not need to draw or
avoid window decorations.
Sub-surfaces allow mixing different buffer types into the same window,
e.g. software-rendered decorations in wl_shm buffers, and live content
in EGL-based buffers.
However, the sub-surface extension does not offer clipping or scaling
facilities, or accurate presentation timing. Those are topics for
additional extensions.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
The scanner is not very forgiving if the protocol doesn't match it's
expectations and crashes without much of a notice. Thus, validate the protocol
against a DTD.
Move the protocol subdir forward so we validate first before trying anything
else, and install the DTD so we can validate weston's protocols as well.
We missed destroy requests in the 1.0 protocol and since the scanner
generates local-only *_destroy requests in that case we can't add
destroy requests without breaking protocol. A client needs to verify
that the server provides a version 3 seat to use the protocol destructor
so the name needs to be something else than wl_*_destroy.
v2 (Rob Bradford): Rebased, bumped the protocol versions and added since
attributes to the requests.
This format is used to specify that the key button events received are not in
relation to any key map and that the codes should be interpreted directly.
v2: Use zero for the no keymap enum value and enhance the documentation
for the enum entry.
Modes are mainly meant to be used in coordination with fullscreen in
DRIVER mode, by e.g. games. For such games what they generally want
is to match some hardware mode and resize their window for that. We
don't really need to complicate this with the scaling. So, we
keep the resolutions in HW pixels, and drop the SCALED flag (as it
is now useless).
This lets you just create e.g an 800x600 buffer of scale 1 and
fullscreen that, ignoring the output scaling factor (although you can
of course also respect it and create a 400x300 surface at scale 2).
Conceptually the mode change is treated like a scaling which overrides
the normal output scale.
The only complexity is the FILL mode where it can happen that the user
specifies a buffer of the same size as the screen, but the output has scale
2 and the buffer scale 1. Just scanning out this buffer will work, but
effectively this is a downscaling operation, as the "real" size of the surface
in pels is twice the size of the output. We solve this by allowing FILL to
downscale (but still not upscale).
This adds the wl_surface.set_buffer_scale request, and a wl_output.scale
event. These together lets us support automatic upscaling of "old"
clients on very high resolution monitors, while allowing "new" clients
to take advantage of this to render at the higher resolution when the
surface is displayed on the scaled output.
It is similar to set_buffer_transform in that the buffer is stored in
a transformed pixels (in this case scaled). This means that if an output
is scaled we can directly use the pre-scaled buffer with additional data,
rather than having to scale it.
Additionally this adds a "scaled" flag to the wl_output.mode flags
so that clients know which resolutions are native and which are scaled.
Also, in places where the documentation was previously not clear as to
what coordinate system was used this was fleshed out.
It also adds a scaling_factor event to wl_output that specifies the
scaling of an output.
This is meant to be used for outputs with a very high DPI to tell the
client that this particular output has subpixel precision. Coordinates
in other parts of the protocol, like input events, relative window
positioning and output positioning are still in the compositor space
rather than the scaled space. However, input has subpixel precision
so you can still get input at full resolution.
This setup means global properties like mouse acceleration/speed,
pointer size, monitor geometry, etc can be specified in a "mostly
similar" resolution even on a multimonitor setup where some monitors
are low dpi and some are e.g. retina-class outputs.
This add a wl_output.done event which is send after every group
of events caused by some property change. This allows clients to treat
changes touching multiple events in an atomic fashion.
Fix summary for wl_touch::motion, extend summary for wl_touch::down to match
up/motion a bit better.
Fix a typo in wl_touch, and claim that it's zero or more update events, not
one or more.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Remove "mice, for example", it's described in the wl_pointer interface in
detail. And remove space before the full stop.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Add a few missing summaries and descriptions, spell out file
descriptor, use hyphens in drag-and-drop, don't use hyphens in
'mime type', and reword a few things.
To match the Weston commit e7144fd175d1d68b91aa0cec7ab63381b79385a9:
Author: Kristian Høgsberg <krh@bitplanet.net>
Date: Mon Mar 4 12:11:41 2013 -0500
compositor: Only send release event in response to wl_surface.attach
Remove the implicit attach semantics from wl_surface.commit and .attach.
Before, if you did this on a wl_surface: attach, commit, commit, you
would receive wl_buffer.release for both commits. After this change, you
will only receive wl_buffer.release for the first commit. To get a
second release, the same buffer must be attached again.
There is no need for the implicit attach on the second commit. If the
compositor needs the wl_buffer for repainting, it will not release it to
begin with. If the compositor does not need to keep the wl_buffer around
for repainting, it will not need it for a new commit either.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
This request allows a client to render its contents according to the
output transform, enabling the compositor to use optimizations such as
overlays, hardware cursors, scan out of a client buffer for
fullscreen surface, etc, even if the output is rotated.
5909dddc78 removed protocol/Makefile.am
which meant protocol/wayland.xml no longer got included in the tarball.
Add back protocol/Makefile.am and configure.ac bits and add protocol to
subdirs in Makefile.am to fix this.
This was added previously (commit 015c42e1) when we didn't have docbook
formatted documentation. Now it became quite useless.
Signed-off-by: Tiago Vignatti <tiago.vignatti@intel.com>
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>
