[PATCH] Don't look for weston.ini in the current working directory
It's a bit surprising that Weston looks different when launched from the root
of the git repo vs from elsewhere.
But it's also technically a security vulnerability: if I launch it from
a directory like /tmp, it might pick up a weston.ini created by another user,
which could then load modules with arbitrary code. Basically, it's the same
problem as including "." in $PATH.
Signed-off-by: Dima Ryazanov
---
man/weston.ini.man | 1 -
man/weston.man | 4 +---
shared/config-parser.c | 8 ++--
3 files changed, 3 insertions(+), 10 deletions(-)
diff --git a/man/weston.ini.man b/man/weston.ini.man
index c12e0505..2171b960 100644
--- a/man/weston.ini.man
+++ b/man/weston.ini.man
@@ -27,7 +27,6 @@ server is started:
.B "weston/weston.ini in each"
.BR "\ \ \ \ $XDG_CONFIG_DIR " "(if $XDG_CONFIG_DIRS is set)"
.BR "/etc/xdg/weston/weston.ini" "(if $XDG_CONFIG_DIRS is not set)"
-.BR "/weston.ini " "(if no variables were set)"
.fi
.RE
.PP
diff --git a/man/weston.man b/man/weston.man
index c09d4c2d..c1aa6476 100644
--- a/man/weston.man
+++ b/man/weston.man
@@ -261,14 +261,12 @@ See
.SH FILES
.
If the environment variable is set, the configuration file is read
-from the respective path, or the current directory if neither is set.
+from the respective path.
.PP
.BI $XDG_CONFIG_HOME /weston.ini
.br
.BI $HOME /.config/weston.ini
.br
-.I ./weston.ini
-.br
.
.\" ***
.SH ENVIRONMENT
diff --git a/shared/config-parser.c b/shared/config-parser.c
index ae5f8035..7b1402d2 100644
--- a/shared/config-parser.c
+++ b/shared/config-parser.c
@@ -75,8 +75,7 @@ open_config_file(struct weston_config *c, const char *name)
}
/* Precedence is given to config files in the home directory,
-* and then to directories listed in XDG_CONFIG_DIRS and
-* finally to the current working directory. */
+* then to directories listed in XDG_CONFIG_DIRS. */
/* $XDG_CONFIG_HOME */
if (config_dir) {
@@ -111,10 +110,7 @@ open_config_file(struct weston_config *c, const char *name)
next++;
}
- /* Current working directory. */
- snprintf(c->path, sizeof c->path, "./%s", name);
-
- return open(c->path, O_RDONLY | O_CLOEXEC);
+ return -1;
}
static struct weston_config_entry *
--
2.19.1
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH 2/3] Delete an unused variable
Signed-off-by: Dima Ryazanov
---
clients/window.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/clients/window.c b/clients/window.c
index 1ab33545..470ac090 100644
--- a/clients/window.c
+++ b/clients/window.c
@@ -278,7 +278,6 @@ struct window {
struct zwp_relative_pointer_v1 *relative_pointer;
struct zwp_locked_pointer_v1 *locked_pointer;
- struct input *locked_input;
bool pointer_locked;
locked_pointer_locked_handler_t pointer_locked_handler;
locked_pointer_unlocked_handler_t pointer_unlocked_handler;
@@ -4866,7 +4865,6 @@ window_lock_pointer(struct window *window, struct input
*input)
&locked_pointer_listener,
input);
- window->locked_input = input;
window->locked_pointer = locked_pointer;
window->relative_pointer = relative_pointer;
@@ -4884,7 +4882,6 @@ window_unlock_pointer(struct window *window)
window->locked_pointer = NULL;
window->relative_pointer = NULL;
window->pointer_locked = false;
- window->locked_input = NULL;
}
void
--
2.19.1
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH 3/3] A better fix for a crash when unlocking or unconfining a pointer
This is a rewrite of the fix in:
https://lists.freedesktop.org/archives/wayland-devel/2018-May/038140.html
It addresses Pekka's concerns about window getting destroyed before the
unlock/unconfine event is triggered.
Signed-off-by: Dima Ryazanov
---
clients/window.c | 31 +++
1 file changed, 27 insertions(+), 4 deletions(-)
diff --git a/clients/window.c b/clients/window.c
index 470ac090..d55d27eb 100644
--- a/clients/window.c
+++ b/clients/window.c
@@ -343,6 +343,8 @@ struct input {
struct window *pointer_focus;
struct window *keyboard_focus;
struct window *touch_focus;
+ struct window *locked_window;
+ struct window *confined_window;
int current_cursor;
uint32_t cursor_anim_start;
struct wl_callback *cursor_frame_cb;
@@ -1584,6 +1586,10 @@ window_destroy(struct window *window)
input->pointer_focus = NULL;
if (input->keyboard_focus == window)
input->keyboard_focus = NULL;
+ if (input->locked_window == window)
+ input->locked_window = NULL;
+ if (input->confined_window == window)
+ input->confined_window = NULL;
if (input->focus_widget &&
input->focus_widget->window == window)
input->focus_widget = NULL;
@@ -4792,7 +4798,10 @@ locked_pointer_locked(void *data,
struct zwp_locked_pointer_v1 *locked_pointer)
{
struct input *input = data;
- struct window *window = input->pointer_focus;
+ struct window *window = input->locked_window;
+
+ if (!window)
+ return;
window->pointer_locked = true;
@@ -4808,10 +4817,15 @@ locked_pointer_unlocked(void *data,
struct zwp_locked_pointer_v1 *locked_pointer)
{
struct input *input = data;
- struct window *window = input->pointer_focus;
+ struct window *window = input->locked_window;
+
+ if (!window)
+ return;
window_unlock_pointer(window);
+ input->locked_window = NULL;
+
if (window->pointer_unlocked_handler) {
window->pointer_unlocked_handler(window,
input,
@@ -4867,6 +4881,7 @@ window_lock_pointer(struct window *window, struct input
*input)
window->locked_pointer = locked_pointer;
window->relative_pointer = relative_pointer;
+ input->locked_window = window;
return 0;
}
@@ -4904,7 +4919,10 @@ confined_pointer_confined(void *data,
struct zwp_confined_pointer_v1 *confined_pointer)
{
struct input *input = data;
- struct window *window = input->pointer_focus;
+ struct window *window = input->confined_window;
+
+ if (!window)
+ return;
window->confined = true;
@@ -4920,11 +4938,15 @@ confined_pointer_unconfined(void *data,
struct zwp_confined_pointer_v1 *confined_pointer)
{
struct input *input = data;
- struct window *window = input->pointer_focus;
+ struct window *window = input->confined_window;
+
+ if (!window)
+ return;
window_unconfine_pointer(window);
window->confined = false;
+ input->confined_window = NULL;
if (window->pointer_unconfined_handler) {
window->pointer_unconfined_handler(window,
@@ -4989,6 +5011,7 @@ window_confine_pointer_to_rectangles(struct window
*window,
window->confined_pointer = confined_pointer;
window->confined_widget = NULL;
+ input->confined_window = window;
return 0;
}
--
2.19.1
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH 1/3] Revert "Fix a crash when unlocking or unconfining a pointer"
This reverts commit e0dc5d47cb5f29deec495efd958fcd5f6f833389.
Signed-off-by: Dima Ryazanov
---
clients/window.c | 23 ++-
1 file changed, 10 insertions(+), 13 deletions(-)
diff --git a/clients/window.c b/clients/window.c
index 12939cb7..1ab33545 100644
--- a/clients/window.c
+++ b/clients/window.c
@@ -286,7 +286,6 @@ struct window {
confined_pointer_unconfined_handler_t pointer_unconfined_handler;
struct zwp_confined_pointer_v1 *confined_pointer;
- struct input *confined_input;
struct widget *confined_widget;
bool confined;
@@ -4793,8 +4792,8 @@ static void
locked_pointer_locked(void *data,
struct zwp_locked_pointer_v1 *locked_pointer)
{
- struct window *window = data;
- struct input *input = window->locked_input;
+ struct input *input = data;
+ struct window *window = input->pointer_focus;
window->pointer_locked = true;
@@ -4809,8 +4808,8 @@ static void
locked_pointer_unlocked(void *data,
struct zwp_locked_pointer_v1 *locked_pointer)
{
- struct window *window = data;
- struct input *input = window->locked_input;
+ struct input *input = data;
+ struct window *window = input->pointer_focus;
window_unlock_pointer(window);
@@ -4865,7 +4864,7 @@ window_lock_pointer(struct window *window, struct input
*input)
ZWP_POINTER_CONSTRAINTS_V1_LIFETIME_ONESHOT);
zwp_locked_pointer_v1_add_listener(locked_pointer,
&locked_pointer_listener,
- window);
+ input);
window->locked_input = input;
window->locked_pointer = locked_pointer;
@@ -4907,8 +4906,8 @@ static void
confined_pointer_confined(void *data,
struct zwp_confined_pointer_v1 *confined_pointer)
{
- struct window *window = data;
- struct input *input = window->confined_input;
+ struct input *input = data;
+ struct window *window = input->pointer_focus;
window->confined = true;
@@ -4923,8 +4922,8 @@ static void
confined_pointer_unconfined(void *data,
struct zwp_confined_pointer_v1 *confined_pointer)
{
- struct window *window = data;
- struct input *input = window->confined_input;
+ struct input *input = data;
+ struct window *window = input->pointer_focus;
window_unconfine_pointer(window);
@@ -4989,9 +4988,8 @@ window_confine_pointer_to_rectangles(struct window
*window,
zwp_confined_pointer_v1_add_listener(confined_pointer,
&confined_pointer_listener,
-window);
+input);
- window->confined_input = input;
window->confined_pointer = confined_pointer;
window->confined_widget = NULL;
@@ -5052,7 +5050,6 @@ window_unconfine_pointer(struct window *window)
zwp_confined_pointer_v1_destroy(window->confined_pointer);
window->confined_pointer = NULL;
window->confined = false;
- window->confined_input = NULL;
}
static void
--
2.19.1
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH wayland-protocols v3] Add alpha-compositing protocol
This protocol specifies a set of interfaces used to control the alpha compositing and blending of surface contents, based on the Chromium Wayland protocol of the same name [1]. Signed-off-by: Scott Anderson [1] https://chromium.googlesource.com/chromium/src/+/master/third_party/wayland-protocols/unstable/alpha-compositing/alpha-compositing-unstable-v1.xml --- Changes in v3: - Rename "blending" event to "blending_equation" - Add enum specifier to "blending_equation" event and "set_blending" request. - Fix typos Changes in v2: - Add additional "fromsource" blending equation used by [3] - Allow the server to advertise which blending equations it supports - Added a protocol error for using an unsupported equation - Added a protocol error for using an invalid alpha value - Added clarification about wl_surface.set_opaque_region - Added clarification about per-pixel alpha values Makefile.am | 1 + unstable/alpha-compositing/README | 5 + .../alpha-compositing-unstable-v1.xml | 175 ++ 3 files changed, 181 insertions(+) create mode 100644 unstable/alpha-compositing/README create mode 100644 unstable/alpha-compositing/alpha-compositing-unstable-v1.xml diff --git a/Makefile.am b/Makefile.am index 6394e26..ac6c9f8 100644 --- a/Makefile.am +++ b/Makefile.am @@ -21,6 +21,7 @@ unstable_protocols = \ unstable/xdg-output/xdg-output-unstable-v1.xml \ unstable/input-timestamps/input-timestamps-unstable-v1.xml \ unstable/xdg-decoration/xdg-decoration-unstable-v1.xml \ + unstable/alpha-compositing/alpha-compositing-unstable-v1.xml \ $(NULL) stable_protocols = \ diff --git a/unstable/alpha-compositing/README b/unstable/alpha-compositing/README new file mode 100644 index 000..5826967 --- /dev/null +++ b/unstable/alpha-compositing/README @@ -0,0 +1,5 @@ +Alpha compositing protocol + +Maintainers: +David Reveman +Alexandros Frantzis diff --git a/unstable/alpha-compositing/alpha-compositing-unstable-v1.xml b/unstable/alpha-compositing/alpha-compositing-unstable-v1.xml new file mode 100644 index 000..d3c41d5 --- /dev/null +++ b/unstable/alpha-compositing/alpha-compositing-unstable-v1.xml @@ -0,0 +1,175 @@ + + + + +Copyright 2016 The Chromium Authors. +Copyright 2017-2018 Collabora Ltd +Copyright 2018 NXP + +Permission is hereby granted, free of charge, to any person obtaining a +copy of this software and associated documentation files (the "Software"), +to deal in the Software without restriction, including without limitation +the rights to use, copy, modify, merge, publish, distribute, sublicense, +and/or sell copies of the Software, and to permit persons to whom the +Software is furnished to do so, subject to the following conditions: + +The above copyright notice and this permission notice (including the next +paragraph) shall be included in all copies or substantial portions of the +Software. + +THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR +IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, +FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL +THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER +LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING +FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER +DEALINGS IN THE SOFTWARE. + + + +This protocol specifies a set of interfaces used to control the alpha +compositing and blending of surface contents. + +Warning! The protocol described in this file is experimental and backward +incompatible changes may be made. Backward compatible changes may be added +together with the corresponding interface version bump. Backward +incompatible changes are done by bumping the version number in the protocol +and interface names and resetting the interface version. Once the protocol +is to be declared stable, the 'z' prefix and the version number in the +protocol and interface names are removed and the interface version number is +reset. + + + + + The global interface exposing compositing and blending capabilities is + used to instantiate an interface extension for a wl_surface object. + This extended interface will then allow the client to specify the + blending equation and alpha value used for compositing the wl_surface. + + + + + + + + +Informs the server that the client will not be using this +protocol object anymore. This does not affect any other objects, +blending objects included. + + + + + +Instantiate an in
Re: question about xdg shell version
On Wed, 14 Nov 2018 23:00:21 +0800 zou lan wrote: > Hi pekka & all > > I find weston support many xdg shell versions in different weston versions, > as far as I know, > applications only use the genernal xdg shell interfaces to create a window, > for example, waylandsink. If the weston upgrade, should the applications > modify its xdg shell interface or are they just backward compatible. Does > weston only support stable/xdg-shell.xml in the future? How could make > weston upgrade not impact applications? Hi Nancy, Weston still supports even wl_shell, I don't think there is much pressure to drop the deprecated versions. I would imagine Weston will carry the support for a good number of years if not indefinitely. Weston still doesn't have an implementation for the stable xdg-shell though. Applications are recommended to move on to the stable xdg-shell version. xdg-shell v5 support was dropped quite some time ago as maintaining it with the other revisions became inconvenient. The revisions other than v5 should not suffer from similar issues. A compositor can support several major revisions at the same time, and Weston does. Clients can also choose which one they use and they can see what the compositor supports. The stable xdg-shell will be developed in a backwards-compatible way. Actually all Wayland extensions are developed that way, both stable and unstable ones. The difference is that unstable ones may get a new incompatible revision through renaming most of the interfaces, which technically allows both compositors and clients to support multiple incompatible versions at the same time. If you are worried about loosing something, you can always follow the Weston merge requests in Gitlab and chime in if something you care about is about to disappear. I don't think bringing xdg-shell v5 support back would be impossible if someone really wanted to, but I suspect it would be much more work than just reverting the removal. xdg-shell v5 is actually multiple incompatible versions IIRC, it was using an ad hoc versioning mechanism which didn't turn out to be that good in the long run. Thanks, pq pgp0qkbsognZk.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
question about xdg shell version
Hi pekka & all I find weston support many xdg shell versions in different weston versions, as far as I know, applications only use the genernal xdg shell interfaces to create a window, for example, waylandsink. If the weston upgrade, should the applications modify its xdg shell interface or are they just backward compatible. Does weston only support stable/xdg-shell.xml in the future? How could make weston upgrade not impact applications? Thank you! Best Regards Nancy ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH RFC wayland-protocols] unstable/linux-dmabuf: add wp_linux_dmabuf_device_hint
On Tue, 13 Nov 2018 18:19:29 + Simon Ser wrote: > > Hi Simon, > > > > On Fri, 2018-11-02 at 18:49 +, Simon Ser wrote: > > > On Friday, November 2, 2018 12:30 PM, Philipp Zabel > > > wrote: > > > > > > + > > > > > > + > > > > > > +This event advertizes the primary device that the server > > > > > > prefers. There > > > > > > +is exactly one primary device. > > > > > > > > Which device should this be if the scanout engine is separate from the > > > > render engine (e.g. IPU/imx-drm and GPU/etnaviv on i.MX6) > > > > > > When the surface hints are created, I expect the compositor to send the > > > device > > > it uses for compositing as the primary device (assuming it's using only > > > one > > > device). > > > > i.MX6 has a separate scanout device without any acceleration capabilities > > except some hardware overlay planes, and a pure GPU render device without > > any connection to the outside world. The compositor uses both devices for > > compositing and output. > > But most of the time, client buffers will go through compositing. So the > primary device is still the render device. > > The situation doesn't change a lot compared to wl_drm to be honest. The device > that is advertised via wl_drm will be the primary device advertised by this > protocol. > > Maybe when the compositor decides to scan-out a client, it can switch the > primary device to the scan-out device. Sorry, I don't know enough about these > particular devices to say for sure. Hi, I do see Philipp's point after thinking for a while. I'll explain below. > > > > When the surface becomes fullscreen on a different GPU (meaning it > > > > becomes > > > fullscreen on an output which is managed by another GPU), I'd expect the > > > compositor to change the primary device for this surface to this other > > > GPU. > > > > > > If the compositor uses multiple devices for compositing, it'll probably > > > switch > > > the primary device when the surface is moved from one GPU to the other. > > > > > > I'm not sure how i.MX6 works, but: even if the same GPU is used for > > > compositing > > > and scanout, but the compositing preferred formats are different from the > > > scanout preferred formats, the compositor can update the preferred format > > > without changing the preferred device. > > > > > > Is there an issue with this? Maybe something should be added to the > > > protocol to > > > explain it better? > > > > It is not clear to me from the protocol description whether the primary > > device means the scanout engine or the GPU, in case they are different. > > > > What is the client process supposed to do with this fd? Is it expected > > to be able to render on this device? Or use it to allocate the optimal > > buffers? > > The client is expected to allocate its buffers there. I'm not sure about > rendering. Well, actually... > > > > What about contiguous vs non-contiguous memory? > > > > > > > > On i.MX6QP (Vivante GC3000) we would probably want the client to always > > > > render DRM_FORMAT_MOD_VIVANTE_SUPER_TILED, because this can be directly > > > > read by both texture samplers (non-contiguous) and scanout (must be > > > > contiguous). > > > > > > > > On i.MX6Q (Vivante GC2000) we always want to use the most efficient > > > > DRM_FORMAT_MOD_VIVANTE_SPLIT_SUPER_TILED, because neither of the > > > > supported render formats can be sampled or scanned out directly. > > > > Since the compositor has to resolve into DRM_FORMAT_MOD_VIVANTE_TILED > > > > (non-contiguous) for texture sampling or DRM_FORMAT_MOD_LINEAR > > > > (contiguous) for scanout, the client buffers can always be non- > > > > contiguous. > > > > > > > > On i.MX6S (Vivante GC880) the optimal render format for texture sampling > > > > would be DRM_FORMAT_MOD_VIVANTE_TILED (non-contiguous) and for scanout > > > > DRM_FORMAT_MOD_VIVANTE_SUPER_TILED (non-contiguous) which would be > > > > resolved into DRM_FORMAT_MOD_LINEAR (contiguous) by the compositor. > > > > > > I think all of this works with Daniel's design. > > > > > > > All three could always handle DRM_FORMAT_MOD_LINEAR (contiguous) client > > > > buffers for scanout directly, but those would be suboptimal if the > > > > compositor decides to render on short notice, because the client would > > > > have already resolved into linear and then the compositor would have to > > > > resolve back into a texture sampler tiling format. > > > > > > Is the concern here that switching between scanout and compositing is > > > non-optimal until the client chooses the preferred format? > > > > My point is just that whether or not the buffer must be contiguous in > > physical memory is the essential piece of information on i.MX6QP, > > whereas the optimal tiling modifier is the same for both GPU composition > > and direct scanout cases. > > > > If the client provides non-contiguous buffers, the "optimal" tiling > > doesn't help one bit in the scanout case, as the sc
Re: [PATCH wayland-protocols v2] Add alpha-compositing protocol
Hi Alexandros and Scott, Here are a few small comments. Overall this proposal looks good. > This protocol specifies a set of interfaces used to control the alpha > compositing and blending of surface contents. > > It's based on the Chromium Wayland protocol of the same name ([1]) and > an old proposal of this protocol ([2]). > > Differences from v1 proposal: > - Add additional "fromsource" blending equation used by [3] > - Allow the server to advertise which blending equations it supports > - Added a protocol errors for using an unsupported equation > - Added a protocol error for using an invalid alpha value > - Added clarification about wl_surface.set_opaque_region > - Added clarification about per-pixel alpha values This should probably not be part of the commit message (ie. be after "---"). > A proof-of-concept implementation for Weston can be found at: > https://gitlab.freedesktop.org/ascent/weston/tree/alpha-compositing-v1 > [1] https://chromium.googlesource.com/chromium/src/+/master/third_party/wayland-protocols/unstable/alpha-compositing/alpha-compositing-u> nstable-v1.xml > [2] > https://lists.freedesktop.org/archives/wayland-devel/2017-August/034741.html > [3] > https://lists.freedesktop.org/archives/wayland-devel/2018-September/039437.html Signed-off-by tags are missing here. > --- > Makefile.am | 1 + > unstable/alpha-compositing/README | 5 + > .../alpha-compositing-unstable-v1.xml | 172 ++ > 3 files changed, 178 insertions(+) > create mode 100644 unstable/alpha-compositing/README > create mode 100644 > unstable/alpha-compositing/alpha-compositing-unstable-v1.xml > > diff --git a/Makefile.am b/Makefile.am > index 6394e26..ac6c9f8 100644 > --- a/Makefile.am > +++ b/Makefile.am > @@ -21,6 +21,7 @@ unstable_protocols = > \ > unstable/xdg-output/xdg-output-unstable-v1.xml > \ > unstable/input-timestamps/input-timestamps-unstable-v1.xml \ > unstable/xdg-decoration/xdg-decoration-unstable-v1.xml \ > + unstable/alpha-compositing/alpha-compositing-unstable-v1.xml > \ > $(NULL) > > stable_protocols = > \ > diff --git a/unstable/alpha-compositing/README > b/unstable/alpha-compositing/README > new file mode 100644 > index 000..5826967 > --- /dev/null > +++ b/unstable/alpha-compositing/README > @@ -0,0 +1,5 @@ > +Alpha compositing protocol > + > +Maintainers: > +David Reveman > +Alexandros Frantzis > diff --git a/unstable/alpha-compositing/alpha-compositing-unstable-v1.xml > b/unstable/alpha-compositing/alpha-compositing-unstable-v1.xml > new file mode 100644 > index 000..aae1d6e > --- /dev/null > +++ b/unstable/alpha-compositing/alpha-compositing-unstable-v1.xml > @@ -0,0 +1,172 @@ > + > + > + > + > +Copyright 2016 The Chromium Authors. > +Copyright 2017-2018 Collabora Ltd > +Copyright 2018 NXP > + > +Permission is hereby granted, free of charge, to any person obtaining a > +copy of this software and associated documentation files (the > "Software"), > +to deal in the Software without restriction, including without limitation > +the rights to use, copy, modify, merge, publish, distribute, sublicense, > +and/or sell copies of the Software, and to permit persons to whom the > +Software is furnished to do so, subject to the following conditions: > + > +The above copyright notice and this permission notice (including the next > +paragraph) shall be included in all copies or substantial portions of the > +Software. > + > +THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS > OR > +IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, > +FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL > +THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR > OTHER > +LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING > +FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER > +DEALINGS IN THE SOFTWARE. > + > + > + > +This protocol specifies a set of interfaces used to control the alpha > +compositing and blending of surface contents. > + > +Warning! The protocol described in this file is experimental and backward > +incompatible changes may be made. Backward compatible changes may be > added > +together with the corresponding interface version bump. Backward > +incompatible changes are done by bumping the version number in the > protocol > +and interface names and resetting the interface version. Once the > protocol > +is to be declared stable, the 'z' prefix and the version number in the > +protocol and interface names are removed and the interface version > number is > +reset. > + > +
