Remote Desktop with Wayland
Hi there, I want to use Linux at work on my workstation PC but currently I can't. The main reason is lack of useful Remote Desktop access to Linux from outside. By useful Remote Desktop access I mean how it's implemented in Windows. In Windows you can connect to a locally started session and continue it remotely. When you do this the local computer will be locked. You can go back to the local computer, unlock it and take over the local session by entering your password. Also you can connect to a Windows computer without any existing session and this will start a new one remotely. After that you can go to that computer, unlock it and continue that session locally. I need this functionality to continue my work outside the office or from other location in the office (a meeting room or a workplace of a colleague). Today's Remote Desktop server solutions in Linux can't provide the above functionality. I've tried xrdp, several implementations of VNC and X2Go. None of them function as needed. They do one of the following: 1. Always start a new session 2. Continue a locally started session in a sharing mode when the local computer is not locked and anyone near it can see what I do and even intervene to that session by local mouse and keyboard. X2Go has even additional problem supporting different resolutions of remote and local computers. As far as I know you've also added the RDP support into the Weston compositor. Do you support the Windows Remote Desktop functionality as described above or this functionality should be implemented by a higher layer that uses Weston? Or what other project (that uses Wayland) should I ask about this? Sincerely, Rostislav Krasny ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH 1/2] libweston: Support autodetection of the current XDG_SEAT
---
libweston/compositor-drm.c | 5 +
libweston/compositor-fbdev.c | 5 +
2 files changed, 10 insertions(+)
diff --git a/libweston/compositor-drm.c b/libweston/compositor-drm.c
index 10adb463..44b2e448 100644
--- a/libweston/compositor-drm.c
+++ b/libweston/compositor-drm.c
@@ -3502,8 +3502,13 @@ drm_backend_create(struct weston_compositor *compositor,
struct udev_device *drm_device;
struct wl_event_loop *loop;
const char *seat_id = default_seat;
+ const char *session_seat;
int ret;
+ session_seat=getenv("XDG_SEAT");
+ if (session_seat)
+ seat_id=session_seat;
+
weston_log("initializing drm backend\n");
b = zalloc(sizeof *b);
diff --git a/libweston/compositor-fbdev.c b/libweston/compositor-fbdev.c
index e80a5040..81e5ec3b 100644
--- a/libweston/compositor-fbdev.c
+++ b/libweston/compositor-fbdev.c
@@ -712,6 +712,11 @@ fbdev_backend_create(struct weston_compositor *compositor,
{
struct fbdev_backend *backend;
const char *seat_id = default_seat;
+ const char *session_seat;
+
+ session_seat=getenv("XDG_SEAT");
+ if (session_seat)
+ seat_id=session_seat;
weston_log("initializing fbdev backend\n");
--
2.11.0
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH 2/2] Document the new handling of XDG_SEAT
--- compositor/main.c | 2 +- man/weston-drm.man | 7 +-- 2 files changed, 6 insertions(+), 3 deletions(-) diff --git a/compositor/main.c b/compositor/main.c index f8a60e97..f632fc0e 100644 --- a/compositor/main.c +++ b/compositor/main.c @@ -563,7 +563,7 @@ usage(int error_code) fprintf(stderr, "Options for drm-backend.so:\n\n" " --connector=ID\tBring up only this connector\n" - " --seat=SEAT\t\tThe seat that weston should run on\n" + " --seat=SEAT\t\tThe seat that weston should run on, instead of the seat defined in XDG_SEAT\n" " --tty=TTY\t\tThe tty to use\n" " --use-pixman\t\tUse the pixman (CPU) renderer\n" " --current-mode\tPrefer current KMS mode over EDID preferred mode\n\n"); diff --git a/man/weston-drm.man b/man/weston-drm.man index 35d62ae6..cc43c31a 100644 --- a/man/weston-drm.man +++ b/man/weston-drm.man @@ -99,8 +99,8 @@ switching to the monitor preferred mode. \fB\-\-seat\fR=\fIseatid\fR Use graphics and input devices designated for seat .I seatid -instead of the default seat -.BR seat0 . +instead of the seat defined in +. BR XDG_SEAT . .TP \fB\-\-tty\fR=\fIx\fR Launch Weston on tty @@ -122,6 +122,9 @@ The file descriptor (integer) where .B weston-launch is listening. Automatically set by .BR weston-launch . +.TP +.B XDG_SEAT +The seat that Weston will start on. . .\" *** .SH "SEE ALSO" -- 2.11.0 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [wayland + ILM] proxy wrappers usage of wayland 1.11.0 to 1.9.0
Hi, Am Freitag, den 18.08.2017, 18:35 +0530 schrieb Vikas Patil: > Dear All, > > > I have backported following patches from wayland 1.11.0 to 1.9.0 to > test one crash issue [1] . I am able to backport and start Weston > with > it. Is this valid thing to do? > > > https://cgit.freedesktop.org/wayland/wayland/commit/?id=6d29c0da3cd16 > 8e08187cd204d2314188479c0f1 > [client: Introduce proxy wrappers] > > https://cgit.freedesktop.org/wayland/wayland/commit/?id=6fe12f02e3b48 > 79cd3d5faa08f023cc761d13be9 > [client: Fix wl_display_roundtrip_queue() race condition] > > https://cgit.freedesktop.org/wayland/wayland/commit/?id=69ec70fb0d3f7 > 5f4bcce449238d6297f6a986b5f > [tests/queue-test: Add tests for proxy wrappers] -- not required. > > > > Now If I understand it correctly I need to use/modify code where the > wayland client creates the proxy and sets the queue. One such > components is [2] ILM control library. I tried to do as per the > patches but with it nothing is coming on display even though weston > starts successfully with ivi-shell and ivi-controller.so. > > > Attached here the modified file. I would like to understand if the > way I used is correct or not? Could someone explain this fix and How > to use it properly for ILM control library? Do I need to add similar > fix in qtwayland 5.5.1 and other such components (e.g. wayland sink > from gstreamer) ? I think there are some problems judging by a quick look at your file: * You create a wrapper for the wl_display, but then call wl_display_get_registry on your original display. You need to use the wrapped display here. * Consequently, you must set the queue on the wl_display wrapper before that so it correctly gets inherited to the wl_registry. * I don't understand what you use wl_display_sync for. You do know that wl_display_roundtrip_queue uses that implicitly? * You must add the registry listener immediately after creating it and not dispatch any events (on the queue the registry uses) in between. Otherwise they will get lost. You might want to take a look at how other libraries use the API, e.g. https://github.com/01org/libva/blob/master/va/wayland/va_wayland_drm.c#L251 If other libraries you use also operate on global objects in a thread- unsafe way (i.e. they are not using proxy wrappers *and* you cannot guarantee that the main queue will not be dispatched in parallel) then you will have to patch them. Regards Philipp > > [1] https://lists.freedesktop.org/archives/wayland-devel/2017-August/ > 034784.html > > [2] https://github.com/GENIVI/wayland-ivi-extension/blob/1.9.1/ivi-la > yermanagement-api/ilmControl/src/ilm_control_wayland_platform.c > (function: init_control(), line: 1260 ) > > > Thanking you in advance for your time and comments. > > > > Thanks & Regards, > > Vikash > ___ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH wayland v4] doc: start documenting Xwayland
From: Pekka Paalanen This is a rough intro to what Xwayland is and does, with just one implementation detail so far (Window identification). I paid no attention to formatting details, those can be polished in follow-ups. I just want the prose out. I also just quickly whacked up the diagram, would be happy to see someone replace it with a nicer one. I just didn't have time to learn dot for now. v2: - typo fix - rephrase "talking to hardware" as "driving the displays" - mention circular dependency in intro - add section to explain rootless and rootful modes - remove paragraph about Xwayland protocol usage - move TBD part to the end under a new section header v3: - use "advantage" and "disadvantage" instead of "pro" and "con" - slight rewording on rootful mode and rootless mode paragraphs - removed the paragraph about the lack of shell and special Wayland protocol extensions - removed the commented out list of ideas to write v4: - typo fixes pointed out by Yong Cc: Olivier Fourdan Cc: Jonas Ådahl Cc: Daniel Stone Signed-off-by: Pekka Paalanen --- doc/publican/Makefile.am | 5 +- doc/publican/sources/Wayland.xml | 1 + doc/publican/sources/Xwayland.xml | 170 + .../sources/images/xwayland-architecture.png | Bin 0 -> 7611 bytes 4 files changed, 175 insertions(+), 1 deletion(-) create mode 100644 doc/publican/sources/Xwayland.xml create mode 100644 doc/publican/sources/images/xwayland-architecture.png diff --git a/doc/publican/Makefile.am b/doc/publican/Makefile.am index 57728a0..e861fe6 100644 --- a/doc/publican/Makefile.am +++ b/doc/publican/Makefile.am @@ -24,9 +24,11 @@ publican_sources = \ $(srcdir)/sources/Preface.xml \ $(srcdir)/sources/Revision_History.xml \ $(srcdir)/sources/Protocol.xml \ + $(srcdir)/sources/Xwayland.xml \ $(srcdir)/sources/Compositors.xml \ $(srcdir)/sources/images/icon.svg \ $(srcdir)/sources/images/wayland.png \ + $(srcdir)/sources/images/xwayland-architecture.png \ $(srcdir)/sources/Client.xml \ $(srcdir)/sources/Server.xml @@ -43,7 +45,8 @@ css_sources = \ img_sources = \ $(srcdir)/sources/images/icon.svg \ - $(srcdir)/sources/images/wayland.png + $(srcdir)/sources/images/wayland.png \ + $(srcdir)/sources/images/xwayland-architecture.png doxygen_img_sources := \ $(doxydir)/xml/wayland-architecture.png \ diff --git a/doc/publican/sources/Wayland.xml b/doc/publican/sources/Wayland.xml index 2f47f13..0457c15 100644 --- a/doc/publican/sources/Wayland.xml +++ b/doc/publican/sources/Wayland.xml @@ -11,6 +11,7 @@ http://www.w3.org/2001/XInclude"; /> http://www.w3.org/2001/XInclude"; /> http://www.w3.org/2001/XInclude"; /> + http://www.w3.org/2001/XInclude"; /> http://www.w3.org/2001/XInclude"; /> http://www.w3.org/2001/XInclude"/> http://www.w3.org/2001/XInclude"/> diff --git a/doc/publican/sources/Xwayland.xml b/doc/publican/sources/Xwayland.xml new file mode 100644 index 000..a39866f --- /dev/null +++ b/doc/publican/sources/Xwayland.xml @@ -0,0 +1,170 @@ + +http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd"; [ + +%BOOK_ENTITIES; +]> + + X11 Application Support + +Introduction + + Being able to run existing X11 applications is crucial for the adoption + of Wayland, especially on desktops, as there will always be X11 + applications that have not been or cannot be converted into Wayland + applications, and throwing them all away would be prohibitive. + Therefore a Wayland compositor often needs to support running X11 + applications. + + + X11 and Wayland are different enough that there is no "simple" way to + translate between them. Most of X11 is uninteresting to a Wayland + compositor. That, combined with the gigantic implementation effort needed + to support X11, makes it intractable to just write X11 support directly in + a Wayland compositor. The implementation would be nothing short of a + real X11 server. + + + Therefore, Wayland compositors should use Xwayland, the X11 server that + lives in the Xorg server source code repository and shares most of the + implementation with the Xorg server. Xwayland is a complete X11 server, + just like Xorg is, but instead of driving the displays and opening input + devices, it acts as a Wayland client. The rest of this chapter talks + about how Xwayland works. + + + For integration and architecture reasons, while Xwayland is a Wayland + client of the Wayland compositor, the Wayland compositor is an X11 client + of Xwayland. This circular dependency requires special care from the + Wayland compositor. + + + +Two Modes for Foreign Windows + + In general, windows from a foreign window system can be presented in one + of two wa
Re: [RFC wayland-protocols] presentation-time: Add request to subscribe to wl_output presentation timings
Hi Pekka,
I have updated the RFC patch with the changes discussed until now.
I haven't got any feedback yet from the Chromium team about associating
the timing object to wl_surface. I will provide further updates when I
get more information. In any case, I think the updated patch is a good
basis for further discussion and development regardless of the path we
follow.
Note that for RFC completeness I have added the flag enumeration in the
patch, but it causes the wayland-scanner to fail since it doesn't
currently contain any values.
Thanks,
Alexandros
---
stable/presentation-time/presentation-time.xml | 108 -
1 file changed, 105 insertions(+), 3 deletions(-)
diff --git a/stable/presentation-time/presentation-time.xml
b/stable/presentation-time/presentation-time.xml
index a46994c..1a8195f 100644
--- a/stable/presentation-time/presentation-time.xml
+++ b/stable/presentation-time/presentation-time.xml
@@ -3,7 +3,8 @@
-Copyright © 2013-2014 Collabora, Ltd.
+Copyright © 2013-2017 Collabora, Ltd.
+Copyright © 2016 The Chromium Authors.
Permission is hereby granted, free of charge, to any person obtaining a
copy of this software and associated documentation files (the "Software"),
@@ -25,8 +26,8 @@
DEALINGS IN THE SOFTWARE.
-
-
+
+
@@ -49,6 +50,16 @@
presentation time can differ from the compositor's predicted
display update time and the update's target time, especially
when the compositor misses its target vertical blanking period.
+
+
+
+ In some cases it's also useful for clients to know about the
+ presentation timing of an output without having submitted a
+ surface content update. For this purpose the 'timing' request
+ creates an object that is used to inform the client about
+ the presentation timing of an wl_output in a precise and
+ low-overhead way.
+
@@ -122,6 +133,27 @@
+
+
+
+
+Create a new timing object that represents a subscription to
+presentation timing updates on the given wl_output object.
+
+The newly created object will signal an update to notify the
+subscriber of initial timing parameters as soon as these
+become available.
+
+If the given wl_output is destroyed before the initial timing
+parameters become available, then no initial update event will
+be sent.
+
+
+
+
+
@@ -263,4 +295,74 @@
+
+
+ A presentation_timing object provides information about the expected
+ presentation times on the associated wl_output.
+
+ When the wl_output associated with a presentation_timing object is
+ destroyed by either the client or the compositor, the presentation_timing
+ object becomes inert. No more events are emitted and the the client
+ is responsible for destroying the object.
+
+
+
+
+Destroy this timing object.
+
+
+
+
+
+These flags provide additional information about the timing reported in
+the 'updated' event. The intent is to help clients assess the
reliability
+of the timing.
+
+
+
+
+
+Notifies the client that the presentation timing information of
+the associated wl_output has changed.
+
+Timing information consists of the timebase and the interval. This
+event informs clients that presentation on the associated output is
+expected to occur at regular intervals of duration 'interval' starting
+at time 'timebase', i.e., at the following time points:
+
+ timebase + N * interval, for N=1,2,...
+
+Change to any timing parameter (i.e., either timebase or interval) may
+cause this event to be emitted.
+
+For the interpretation of the timebase see the information about the
+related timestamp ('tv_*') argument in the presentation.presented
event.
+
+For the interpretation of the interval see the information about the
+related 'refresh' argument in the presentation.presented event.
+
+If the server cannot accurately predict the interval between subsequent
+presentation events for the output, or the output does not have a
+constant presentation rate, then the interval argument must be zero.
+Note that the inability to predict the interval may be temporary.
+
+For the interpretion of seq_hi and seq_lo, see the related information
+in the presentation.presented event.
+
+
+
+
+
+
+
+
+
+
+
--
2.14.1
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH wayland v2] server: document wl_event_loop and wl_event_source
From: Pekka Paalanen
This documents all the public API related to wl_event_loop and
wl_event_source objects.
Signed-off-by: Pekka Paalanen
Reviewed-by: Yong Bakos
[Pekka: fixed typos pointed by Yong]
---
v2: Just typo fixes. Anyone else care to read this through?
If not, I think I'll just push this next week.
---
doc/doxygen/Makefile.am | 1 +
src/event-loop.c | 244 +-
src/wayland-server-core.h | 77 +++
3 files changed, 321 insertions(+), 1 deletion(-)
diff --git a/doc/doxygen/Makefile.am b/doc/doxygen/Makefile.am
index 276a395..f8b0b3a 100644
--- a/doc/doxygen/Makefile.am
+++ b/doc/doxygen/Makefile.am
@@ -19,6 +19,7 @@ scanned_src_files_Client =\
scanned_src_files_Server = \
$(scanned_src_files_shared) \
+ $(top_srcdir)/src/event-loop.c \
$(top_srcdir)/src/wayland-server.c \
$(top_srcdir)/src/wayland-server.h \
$(top_srcdir)/src/wayland-server-core.h \
diff --git a/src/event-loop.c b/src/event-loop.c
index 6130d2a..9bc52ac 100644
--- a/src/event-loop.c
+++ b/src/event-loop.c
@@ -42,6 +42,8 @@
#include "wayland-server-core.h"
#include "wayland-os.h"
+/** \cond INTERNAL */
+
struct wl_event_loop {
int epoll_fd;
struct wl_list check_list;
@@ -70,6 +72,8 @@ struct wl_event_source_fd {
int fd;
};
+/** \endcond */
+
static int
wl_event_source_fd_dispatch(struct wl_event_source *source,
struct epoll_event *ep)
@@ -125,6 +129,30 @@ add_source(struct wl_event_loop *loop,
return source;
}
+/** Create a file descriptor event source
+ *
+ * \param loop The event loop that will process the new source.
+ * \param fd The file descriptor to watch.
+ * \param mask A bitwise-or of which events to watch for: \c WL_EVENT_READABLE,
+ * \c WL_EVENT_WRITABLE.
+ * \param func The file descriptor dispatch function.
+ * \param data User data.
+ * \return A new file descriptor event source.
+ *
+ * The given file descriptor is initially watched for the events given in
+ * \c mask. This can be changed as needed with wl_event_source_fd_update().
+ *
+ * If it is possible that program execution causes the file descriptor to be
+ * read while leaving the data in a buffer without actually processing it,
+ * it may be necessary to register the file descriptor source to be re-checked,
+ * see wl_event_source_check(). This will ensure that the dispatch function
+ * gets called even if the file descriptor is not readable or writable
+ * anymore. This is especially useful with IPC libraries that automatically
+ * buffer incoming data, possibly as a side-effect of other operations.
+ *
+ * \sa wl_event_loop_fd_func_t
+ * \memberof wl_event_source
+ */
WL_EXPORT struct wl_event_source *
wl_event_loop_add_fd(struct wl_event_loop *loop,
int fd, uint32_t mask,
@@ -145,6 +173,26 @@ wl_event_loop_add_fd(struct wl_event_loop *loop,
return add_source(loop, &source->base, mask, data);
}
+/** Update a file descriptor source's event mask
+ *
+ * \param source The file descriptor event source to update.
+ * \param mask The new mask, a bitwise-or of: \c WL_EVENT_READABLE,
+ * \c WL_EVENT_WRITABLE.
+ * \return 0 on success, -1 on failure.
+ *
+ * This changes which events, readable and/or writable, cause the dispatch
+ * callback to be called on.
+ *
+ * File descriptors are usually writable to begin with, so they do not need to
+ * be polled for writable until a write actually fails. When a write fails,
+ * the event mask can be changed to poll for readable and writable, delivering
+ * a dispatch callback when it is possible to write more. Once all data has
+ * been written, the mask can be changed to poll only for readable to avoid
+ * busy-looping on dispatch.
+ *
+ * \sa wl_event_loop_add_fd()
+ * \memberof wl_event_source
+ */
WL_EXPORT int
wl_event_source_fd_update(struct wl_event_source *source, uint32_t mask)
{
@@ -161,11 +209,15 @@ wl_event_source_fd_update(struct wl_event_source *source,
uint32_t mask)
return epoll_ctl(loop->epoll_fd, EPOLL_CTL_MOD, source->fd, &ep);
}
+/** \cond INTERNAL */
+
struct wl_event_source_timer {
struct wl_event_source base;
wl_event_loop_timer_func_t func;
};
+/** \endcond */
+
static int
wl_event_source_timer_dispatch(struct wl_event_source *source,
struct epoll_event *ep)
@@ -187,6 +239,19 @@ struct wl_event_source_interface timer_source_interface = {
wl_event_source_timer_dispatch,
};
+/** Create a timer event source
+ *
+ * \param loop The event loop that will process the new source.
+ * \param func The timer dispatch function.
+ * \param data User data.
+ * \return A new timer event source.
+ *
+ * The timer is initially disarmed. It needs to be armed with a call to
+ * wl_event_source_timer_update() before it can tr
[wayland + ILM] proxy wrappers usage of wayland 1.11.0 to 1.9.0
Dear All,
I have backported following patches from wayland 1.11.0 to 1.9.0 to
test one crash issue [1] . I am able to backport and start Weston with
it. Is this valid thing to do?
https://cgit.freedesktop.org/wayland/wayland/commit/?id=6d29c0da3cd168e08187cd204d2314188479c0f1
[client: Introduce proxy wrappers]
https://cgit.freedesktop.org/wayland/wayland/commit/?id=6fe12f02e3b4879cd3d5faa08f023cc761d13be9
[client: Fix wl_display_roundtrip_queue() race condition]
https://cgit.freedesktop.org/wayland/wayland/commit/?id=69ec70fb0d3f75f4bcce449238d6297f6a986b5f
[tests/queue-test: Add tests for proxy wrappers] -- not required.
Now If I understand it correctly I need to use/modify code where the
wayland client creates the proxy and sets the queue. One such
components is [2] ILM control library. I tried to do as per the
patches but with it nothing is coming on display even though weston
starts successfully with ivi-shell and ivi-controller.so.
Attached here the modified file. I would like to understand if the
way I used is correct or not? Could someone explain this fix and How
to use it properly for ILM control library? Do I need to add similar
fix in qtwayland 5.5.1 and other such components (e.g. wayland sink
from gstreamer) ?
[1] https://lists.freedesktop.org/archives/wayland-devel/2017-August/034784.html
[2]
https://github.com/GENIVI/wayland-ivi-extension/blob/1.9.1/ivi-layermanagement-api/ilmControl/src/ilm_control_wayland_platform.c
(function: init_control(), line: 1260 )
Thanking you in advance for your time and comments.
Thanks & Regards,
Vikash
/**
*
* Copyright (C) 2013 DENSO CORPORATION
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
*http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*
/
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include "ilm_common.h"
#include "ilm_control_platform.h"
#include "wayland-util.h"
#include "ivi-controller-client-protocol.h"
#include "ivi-input-client-protocol.h"
/* GCC visibility */
#if defined(__GNUC__) && __GNUC__ >= 4
#define ILM_EXPORT __attribute__ ((visibility("default")))
#else
#define ILM_EXPORT
#endif
struct layer_context {
struct wl_list link;
struct ivi_controller_layer *controller;
t_ilm_uint id_layer;
struct ilmLayerProperties prop;
layerNotificationFunc notification;
struct {
struct wl_list list_surface;
struct wl_list link;
} order;
struct wayland_context *ctx;
};
struct screen_context {
struct wl_list link;
struct wl_output *output;
struct ivi_controller_screen *controller;
t_ilm_uint id_from_server;
t_ilm_uint id_screen;
int32_t transform;
struct ilmScreenProperties prop;
struct {
struct wl_list list_layer;
} order;
struct ilm_control_context *ctx;
};
static inline void lock_context(struct ilm_control_context *ctx)
{
pthread_mutex_lock(&ctx->mutex);
}
static inline void unlock_context(struct ilm_control_context *ctx)
{
pthread_mutex_unlock(&ctx->mutex);
}
static int init_control(void);
static struct surface_context* get_surface_context(struct wayland_context *, uint32_t);
void release_instance(void);
static int create_controller_layer(struct wayland_context *ctx, t_ilm_uint width, t_ilm_uint height, t_ilm_layer layerid);
static int32_t
wayland_controller_is_inside_layer_list(struct wl_list *list,
uint32_t id_layer)
{
struct layer_context *ctx_layer = NULL;
wl_list_for_each(ctx_layer, list, link) {
if (ctx_layer->id_layer == id_layer) {
return 1;
}
}
return 0;
}
static struct layer_context*
wayland_controller_get_layer_context(struct wayland_context *ctx,
uint32_t id_layer)
{
struct layer_context *ctx_layer = NULL;
if (ctx->controller == NULL) {
fprintf(stderr, "controller is not initialized in ilmControl\n");
return NULL;
}
wl_list_for_each(ctx_layer, &ctx->list_layer, link) {
if (ctx_layer->id_layer == id_layer) {
return ctx_layer;
}
}
return NULL;
}
static void
output_listener_geometry(void *data,
struct wl_output *output,
int32_t x,
int32_t y,
int32_t physical_
Re: [PATCH weston] libweston-desktop/xwayland: Make sure racy surfaces are properly mapped
On Fri, 21 Jul 2017 18:43:41 +0200
Quentin Glidic wrote:
> On 5/15/17 4:40 PM, Pekka Paalanen wrote:
> > On Mon, 15 May 2017 15:29:29 +0200
> > Quentin Glidic wrote:
> >
> >> From: Quentin Glidic
> >>
> >> Signed-off-by: Quentin Glidic
> >> ---
> >> libweston-desktop/xwayland.c | 10 ++
> >> 1 file changed, 10 insertions(+)
> >>
> >> diff --git a/libweston-desktop/xwayland.c b/libweston-desktop/xwayland.c
> >> index 4f4b453f..4dcb5f03 100644
> >> --- a/libweston-desktop/xwayland.c
> >> +++ b/libweston-desktop/xwayland.c
> >> @@ -61,6 +61,7 @@ struct weston_desktop_xwayland_surface {
> >>const struct weston_xwayland_client_interface *client_interface;
> >>struct weston_geometry next_geometry;
> >>bool has_next_geometry;
> >> + bool committed;
> >>bool added;
> >>enum weston_desktop_xwayland_surface_state state;
> >> };
> >> @@ -99,6 +100,14 @@ weston_desktop_xwayland_surface_change_state(struct
> >> weston_desktop_xwayland_surf
> >>weston_desktop_api_surface_added(surface->desktop,
> >> surface->surface);
> >>surface->added = true;
> >> + if (surface->state == NONE && surface->committed)
> >> + /* We had a race, and wl_surface.commit() was
> >> + * faster, just fake a commit to map the
> >> + * surface */
> >> + weston_desktop_api_committed(surface->desktop,
> >> + surface->surface,
> >> + 0, 0);
> >> +
> >>} else if (surface->added) {
> >>weston_desktop_api_surface_removed(surface->desktop,
> >> surface->surface);
> >> @@ -134,6 +143,7 @@ weston_desktop_xwayland_surface_committed(struct
> >> weston_desktop_surface *dsurfac
> >>struct weston_geometry oldgeom;
> >>
> >>assert(dsurface == surface->surface);
> >> + surface->committed = true;
> >>
> >> #ifdef WM_DEBUG
> >>weston_log("%s: xwayland surface %p\n", __func__, surface);
> >
> > Hi Quentin,
> >
> > thanks for making the patch so fast! It clarified my thoughts.
> >
> > I wonder, could it become a problem to never unset 'committed'? In case
> > something causes XWM or Xwayland to "unmap" the surface and later map
> > again.
> >
> > We'd want to check for "has content", and checking for a buffer is not
> > always right as the renderer may have made a copy and released the
> > buffer, so... weston_surface width and height > 0?
> >
> > Calling weston_desktop_api_commit() sounds like the right solution.
> >
> > Is surface->state reset back to NONE when the surface is unmapped? What
> > about !weston_surface_is_mapped()?
> >
> >
> > I feel I should explain more background for the bug we are trying to
> > fix here, as I have no reliable way to reproduce. Hopefully that
> > inspires a commit message. ;-)
> >
> > The question is about a fundamental race between the Wayland and X11
> > protocol streams for XWM. Wayland carries the surface content, which is
> > latched in with wl_surface.commit that leads to calling into the shell
> > plugin to map the window. X11 carries the window management
> > information, essentially the shell role for the window/surface.
> > Obviously we cannot actually map a window until it has both content and
> > role.
> >
> > So the race is between setting the content and setting the role. IIRC
> > e.g. xdg_shell simply forbids this race, requiring role to be set
> > first. Unfortunately with Xwayland I don't think we have the luxury of
> > that. There is the _XWAYLAND_ALLOW_COMMITS feature which could mitigate
> > the problem, but it is not yet in any xorg-xserver release, and we need
> > to be able to do without it.
> >
> > The actual bug is, that if content is set first, setting the role does
> > not complete mapping the surface. As the surface is not mapped, the frame
> > callbacks are not sent, and Xwayland will never commit again. The
> > window is lost in an unmapped limbo.
> >
> > At least, I believe we have that bug. Actually I am helping to fix this
> > bug on Weston 1.11 which is before the introduction of
> > libweston-desktop. I have had reports of this issue on 1.11, and when I
> > looked at the code in master, I believe the problem is still there, but
> > have not been able to reproduce it. Doesn't help that I'm generally
> > running with _XWAYLAND_ALLOW_COMMITS support too.
>
> Actually, the concepts involved don’t match the code perfectly.
> In libweston-desktop, the commit does *not* depend on content. It just
> happens that Xwayland commit for content only (since the rest is done
> via XWM). The compositor/shell has to deal with NULL-buffer surfaces
> anyway, since wl_shell mandates that.
>
> Mapping the surface needs this sequence:
> 1
Re: [RFC weston 0/9] weston-debug protocol, API, and tool
On Thu, 27 Jul 2017 15:13:22 + "Devadoss, Maniraj (RBEI/ECF3; ADITG/SWG)" wrote: > Hello Pekka, > > Please find my replies. > > > What do you think of the alias idea? > This idea looks good to group the debug scopes. > > > I'm still not sure who or when would be able to push this work forward. > > I am very happy to hear it is a workable idea for you too. > We can complete the pending works and push it forward > Let me summarize the pending tasks > i) Add this protocol as a wayland-protocol >- The protocol can be named as "compositor-debug-unstable-v1.xml", please > let me know if this naming can be improved > i) WIP: parse and print the message arguments for the protocol logger > ii) WIP: add a man page for weston-debug client > iii) Add the command line to weston to stream the bootup logs to given file > before the client connects > iv) Add the scope name to the debug messages > > Please update the list if I miss some tasks. Hi, sorry for the delay, just disappeared for holidays at the time. Yeah, sounds good, nothing else comes to mind. We'll see in patch review then. Thank you very much, pq pgpuNKkUGg3S7.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland 2/3] scanner: Allow adding a prefix to exported symbols
On Fri, 28 Jul 2017 14:06:23 +0100 Emil Velikov wrote: > On 27 July 2017 at 14:01, Pekka Paalanen wrote: > > On Wed, 26 Jul 2017 16:09:32 +0100 > > Emil Velikov wrote: > > > >> On 25 July 2017 at 10:24, Pekka Paalanen wrote: > >> > On Tue, 25 Jul 2017 15:25:58 +0800 > >> > Jonas Ådahl wrote: > >> > > >> >> On Mon, Jul 24, 2017 at 02:16:04PM +0300, Pekka Paalanen wrote: > >> >> > On Mon, 3 Jul 2017 17:16:45 +0800 > >> >> > Jonas Ådahl wrote: > >> >> > > >> >> > > Two different protocols may use interfaces with identical names. > >> >> > > Implementing support for both those protocols would result in symbol > >> >> > > clashes, as wayland-scanner generates symbols from the interface > >> >> > > names. > >> >> > > > >> >> > > Make it possible to avoiding these clashes by adding a way to add a > >> >> > > prefix to the symbols generated by wayland-scanner. Implementations > >> >> > > (servers and clients) can then use these prefix:ed symbols to > >> >> > > implement > >> >> > > different objects with the same name. > >> >> > > > >> >> > > Signed-off-by: Jonas Ådahl > >> >> > > --- > >> >> > > > >> >> > > Something like this would be needed if a compositor/client wants to > >> >> > > implement > >> >> > > xdg-shell unstable v5 alongside xdg-shell stable, unless we want to > >> >> > > rename all > >> >> > > our xdg-shell interfaces. Implementing xdg-shell unstable v6 > >> >> > > alongside > >> >> > > xdg-shell stable does not have this issue. > >> >> > > > >> >> > > See issue raised here: > >> >> > > https://lists.freedesktop.org/archives/wayland-devel/2017-June/034380.html > >> >> > > > >> >> > > > >> >> > > Jonas > >> >> > > > >> >> > > > >> >> > > src/scanner.c | 94 > >> >> > > ++- > >> >> > > 1 file changed, 73 insertions(+), 21 deletions(-) > >> >> > > >> >> > > >> >> > Hi, > >> >> > > >> >> > while this seems to change the ABI symbol names, it does not change > >> >> > the > >> >> > names in the documentation, and it does not change the names of > >> >> > #defines of enums, or the inline functions. That means that this is > >> >> > not > >> >> > enough to fulfill the purpose: being able to use two similarly named > >> >> > but different protocols by adding a prefix. > >> >> > >> >> The idea I had was rather that one would avoid changing any names on > >> >> non-symbols. It'd still be possible to implement both by doing it in > >> >> separate C files. I can see the point in adding the prefix on everything > >> >> though, so I'll provide a patch for that. > >> >> > >> > > >> > Hi, > >> > > >> > recapping the discussion from IRC, we pretty much agreed that prefixing > >> > is not a nice solution. Jonas found out that we cannot actually prefix > >> > everything, because there usually are references to other protocol > >> > things (like you would never want to prefix wl_surface). So it becomes > >> > very hard to prefix things appropriately. ... > Tl:Dr; I think that everything should be prefixed. See below for details. > > - ABI symbols - to prevent symbol collision > - inline/other API - to minimise ambiguity, confusion, plus you can > have multiple implementations in the same translation unit* > > > *Some projects may want to support xdg-shell vX and vX+1 in the same file. > - The inline API from vX may work with vY or vise-versa. Yet it's > easier to pass the wrong object to the inline function. > - One can (and will have) cases, where API foo() is available for > only one version. > - If the function signature (of the inline API) differs the compiler > will barf at you - say vX+1 adds extra argument to function bar() Yes, I agree, which is why I was not too fond of this patch originally. This patch does not prefix API, but only ABI. The difficulty is in what interfaces to prefix as a whole (ABI and API) and what not. As an example, one would never want to prefix wl_surface, yet extension interfaces use wl_surface as a message argument. Jonas, I think we can discriminate between interfaces (protocol object types) defined in the XML file being processed vs. external interfaces from elsewhere (like wl_surface). Would that be good enough for prefixing not just #defines and inline functions but the C types as well? The case where it would not work if one wants to prefix things from both one.xml and two.xml, and two.xml used interfaces defined in one.xml. Is that an acceptable limitation? As a stretch I'd rather avoid for now, there could be an option to prefix all external interfaces with another prefix, but it would not be able to make a difference between things from wayland.xml and one.xml, for instance. Where are we at with the name collision problem in general now? Thanks, pq pgpJjQIBgkrUB.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-de
Re: [PATCH wayland 1/3] Pass input/output files as arguments to wayland-scanner
On Wed, 26 Jul 2017 15:57:19 +0100 Emil Velikov wrote: > On 3 July 2017 at 10:16, Jonas Ådahl wrote: > > When input/output files are passed as arguments to wayland-scanner, > > instead of using stdin/stdout, warning and error messages will contain > > the file name, together with line number, of the warning/error. Doing > > this helps IDEs jump to the correct line. > > > I really like the idea, there is one concern though - some projects do > invoke wayland_scanner directly in their build system. > Thus this patch will break things for them. > > If devs are OK with that (personally I'll say "yes please"), a big fat > warning in the release notes & announcement is due. > > Fwiw the patch is > Reviewed-by: Emil Velikov Pushed: 22be3c7..b88ada0 master -> master Thanks, pq pgpjeDJsDs1d3.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 4/5] build: set the scanner --object-type option
On Fri, 28 Jul 2017 13:23:46 +0100 Emil Velikov wrote: > On 27 July 2017 at 14:36, Pekka Paalanen wrote: > > On Wed, 26 Jul 2017 14:56:20 +0100 > > Emil Velikov wrote: > > > >> From: Emil Velikov > >> > >> Unlike most other scanner users, the core wayland interfaces are > >> public ally available via the libwayland DSO. > >> > >> Signed-off-by: Emil Velikov > >> --- > >> Makefile.am | 2 +- > >> 1 file changed, 1 insertion(+), 1 deletion(-) > >> > >> diff --git a/Makefile.am b/Makefile.am > >> index d0c8bd3..4055d04 100644 > >> --- a/Makefile.am > >> +++ b/Makefile.am > >> @@ -97,7 +97,7 @@ nodist_libwayland_client_la_SOURCES = \ > >> pkgconfig_DATA += src/wayland-client.pc src/wayland-server.pc > >> > >> protocol/%-protocol.c : $(top_srcdir)/protocol/%.xml > >> - $(AM_V_GEN)$(MKDIR_P) $(dir $@) && $(wayland_scanner) code < $< > $@ > >> + $(AM_V_GEN)$(MKDIR_P) $(dir $@) && $(wayland_scanner) > >> --object-type=shared code < $< > $@ > >> > >> protocol/%-server-protocol.h : $(top_srcdir)/protocol/%.xml > >> $(AM_V_GEN)$(MKDIR_P) $(dir $@) && $(wayland_scanner) server-header > >> < $< > $@ > > > > Hi, > > > > looks good, but I wonder if the header commands need the type set as > > well to avoid the warning. > > > My goal was to have the option only for "code", but it seems like the > scanner will throw a warning when client/server-header instances are > missing it. > > I could omit the warning or simply add have --object-type throughout > the Makefile, for consistence. Hi Emil, right. The only argument one way or another that I can think of for now is that it might be slightly more future-proof if all scanner invocations used the same set of options. That way if we need something in headers based on object-type, users would already be set. But I can't think of what it might be so it's a very weak argument. Thanks, pq pgpjOKdfgEDa3.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 3/5] scanner: introduce --object-type option
On Fri, 28 Jul 2017 13:13:48 +0100
Emil Velikov wrote:
> On 27 July 2017 at 14:25, Pekka Paalanen wrote:
> > On Wed, 26 Jul 2017 14:56:19 +0100
> > Emil Velikov wrote:
> >
> >> From: Emil Velikov
> >>
> >> The option is used to indicate how the code will be used - would it be a
> >> part of shared or static one.
> >>
> >> In the former case one needs to export the specific symbols, although
> >> normally people want to statically build the protocol code into their
> >> project.
> >>
> >> If the option is missing a warning is emitted, to point people and do
> >> the right thing.
> >>
> >> Signed-off-by: Emil Velikov
> >> ---
> >> src/scanner.c | 61
> >> ++-
> >> 1 file changed, 56 insertions(+), 5 deletions(-)
> >>
> >> diff --git a/src/scanner.c b/src/scanner.c
> >> index c345ed6..cc45b74 100644
> >> --- a/src/scanner.c
> >> +++ b/src/scanner.c
> >> @@ -57,6 +57,11 @@ enum side {
> >> SERVER,
> >> };
> >>
> >> +enum object_type {
> >> + SHARED,
> >> + STATIC,
> >> +};
> >
> > Hi,
> >
> > I could go with this as well, as long as we have some solution to the
> > original problem of conflicting interface names that Jonas is trying to
> > solve.
> >
> i think the original patch from Jonas, addressed that issue nicely.
> Let's keep that in the respective thread.
Hi Emil,
very good, let's continue that there.
...
> >> static void
> >> -emit_code(struct protocol *protocol)
> >> +emit_code(struct protocol *protocol, enum object_type obj_type)
> >> {
> >> + const char *symbol_visibility;
> >> struct interface *i, *next;
> >> struct wl_array types;
> >> char **p, *prev;
> >> @@ -1728,6 +1740,19 @@ emit_code(struct protocol *protocol)
> >> "#include \n"
> >> "#include \"wayland-util.h\"\n\n");
> >>
> >> + /* When building a shared library symbols must be exported, otherwise
> >> + * we want to have the symbols hidden. */
> >> + if (obj_type == STATIC) {
> >> + symbol_visibility = "WL_PRIVATE";
> >> + printf("#if defined(__GNUC__) && __GNUC__ >= 4\n"
> >> +"#define WL_PRIVATE __attribute__
> >> ((visibility(\"hidden\")))\n"
> >> +"#else\n"
> >> +"#define WL_PRIVATE\n"
> >> +"#endif\n\n");
> >> + } else {
> >> + symbol_visibility = "WL_EXPORT";
> >> + }
> >
> > I wonder... would it be any better to just replace 'WL_EXPORT' and
> > 'extern' with tokens:
> >
> > - LOCAL_INTERFACE_DECL for declarations of symbols that will also be
> > defined in the generated code file
> >
> > - EXTERN_INTERFACE_DECL for declarations of symbols that the generated
> > files will need but the code file will not define, that is,
> > interfaces defined on other XML files.
> >
> > - LOCAL_INTERFACE_DEF for symbol definitions in the generated code file.
> >
> > The exported configuration would then be:
> > LOCAL_INTERFACE_DECL=extern
> > EXTERN_INTERFACE_DECL=extern
> > LOCAL_INTERFACE_DEF=WL_EXPORT
> >
> > That would be far too flexible and no-one would use it right, right?
> >
> I did not introduce separate tokens, since those are (and should be)
> used _only_ in the .c file.
> Personally then do not seem necessary, If you prefer we can add them though.
Ah, no, that was just a wild idea of something completely different. I
meant that the user project would be setting those macros before using
scanner-generated files, and if unset, the scanner-emitted code would
default to the legacy behaviour. That way there would be no visibility
modes in scanner itself. If it's not obviously better, then nevermind.
It certainly has a lot more room to go wrong than your proposal.
...
> > The patch looks pretty much correct to me, if we choose to go this way.
> >
> Glad to hear.
>
> I'll let me know once you guys are settled in on the approach, and
> I'll respin the series with all the comments addressed.
Cool, let's see if we can get the name conflict issue solved, and then
I'll try to remember to ping you.
Thanks,
pq
pgpSXRXjhA2ik.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 2/5] scanner: use tabs for indentation.
On Thu, 27 Jul 2017 16:09:53 +0300 Pekka Paalanen wrote: > On Wed, 26 Jul 2017 14:56:18 +0100 > Emil Velikov wrote: > > > From: Emil Velikov > > > > File uses tabs, barring the few instances fixed with this patch. > > > > Signed-off-by: Emil Velikov > > --- > > src/scanner.c | 6 +++--- > > 1 file changed, 3 insertions(+), 3 deletions(-) > > > > diff --git a/src/scanner.c b/src/scanner.c > > index 517068c..c345ed6 100644 > > --- a/src/scanner.c > > +++ b/src/scanner.c > > @@ -70,9 +70,9 @@ usage(int ret) > > fprintf(stderr, "-h, --help display this help and > > exit.\n" > > "-v, --version print the wayland > > library version that\n" > > " the scanner was built > > against.\n" > > - "-c, --include-core-only include the core > > version of the headers,\n" > > - " that is e.g. > > wayland-client-core.h instead\n" > > - " of > > wayland-client.h.\n"); > > + "-c, --include-core-only include the core > > version of the headers,\n" > > + " that is e.g. > > wayland-client-core.h instead\n" > > + " of > > wayland-client.h.\n"); > > exit(ret); > > } > > > > Reviewed-by: Pekka Paalanen Pushed: 12509e4..22be3c7 master -> master Thanks, pq pgpRJGr6jdrCQ.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 1/5] scanner: remove unused scanner.mk
On Thu, 27 Jul 2017 16:08:25 +0300 Pekka Paalanen wrote: > On Wed, 26 Jul 2017 14:56:17 +0100 > Emil Velikov wrote: > > > From: Emil Velikov > > > > Nothing in the existing codebase references the file. > > > > Signed-off-by: Emil Velikov > > --- > > src/scanner.mk | 8 > > 1 file changed, 8 deletions(-) > > delete mode 100644 src/scanner.mk > > > > diff --git a/src/scanner.mk b/src/scanner.mk > > deleted file mode 100644 > > index 1b6963c..000 > > --- a/src/scanner.mk > > +++ /dev/null > > @@ -1,8 +0,0 @@ > > -%-protocol.c : $(protocoldir)/%.xml > > - $(AM_V_GEN)$(wayland_scanner) code < $< > $@ > > - > > -%-server-protocol.h : $(protocoldir)/%.xml > > - $(AM_V_GEN)$(wayland_scanner) server-header < $< > $@ > > - > > -%-client-protocol.h : $(protocoldir)/%.xml > > - $(AM_V_GEN)$(wayland_scanner) client-header < $< > $@ > > Ha! Indeed. > > Reviewed-by: Pekka Paalanen > Pushed: 0b991b6..12509e4 master -> master Thanks, pq pgpVSL_AuNzXr.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Running multliple fullscreen applications on each of the the DRM connector
On Fri, 28 Jul 2017 08:26:04 -0500 Prabhu S wrote: > Currently I have a DRM modeset master which have multiple (HDMI) connectors. > > I suppose there is a limitation (or security feature) in DRM that only one > user process can be a DRM master and only the master can do drmMode* > operations. > > Wondering how to run multiple fullscreen applications (each for a DRM > connector) with wayland? and whether client will have option to choose the > connector? > > References: > https://dvdhrm.wordpress.com/2013/05/29/drm-render-and-modeset-nodes/ > https://keithp.com/blogs/DRM-lease/ Hi, that is up to the shell protocol extension. wl_shell.set_fullscreen and zxdg_toplevel_v6.set_fullscreen have an output argument. If you have pre-defined set of applications to run, you could also write your own shell extension instead. The DRM leasing protocol for Wayland has not yet been written, AFAIK. Thanks, pq pgpL68wnzOBJP.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland] scanner: Add autoconf macro to check for the proper scanner
On Fri, 18 Aug 2017 11:36:17 +0200
Quentin Glidic wrote:
> On 8/18/17 11:30 AM, Quentin Glidic wrote:
> > From: Quentin Glidic
> >
> > Projects have been using various ways to check for the wayland-scanner,
> > mostly based on their developper own use case, and often not allowing
> > others use cases to work without a workaround.
> >
> > Hopefully this macro will support all use cases without needing user
> > action.
> >
> > Signed-off-by: Quentin Glidic
> > ---
> >
> > Everyone should test this macro for their own project and use cases.
> > Using the ${WAYLAND_SCANNER} variable should just work (assuming you have
> > the proper
> > wayland package built in the expected env). In very very rare cases,
> > setting the
> > WAYLAND_SCANNER variable as a ./configure argument may be needed, but
> > nothing else.
> >
> > Please let me know with enough details if your use case is not working with
> > it.
>
> Forgot the CCs while sending the patch.
>
>
> > wayland-scanner.m4 | 54
> > ++
> > 1 file changed, 54 insertions(+)
> >
> > diff --git a/wayland-scanner.m4 b/wayland-scanner.m4
> > index 4e4222a..37e0548 100644
> > --- a/wayland-scanner.m4
> > +++ b/wayland-scanner.m4
> > @@ -1,3 +1,5 @@
> > +#serial 2
> > +
> > AC_DEFUN([WAYLAND_SCANNER_RULES], [
> > PKG_PROG_PKG_CONFIG
> >
> > @@ -11,3 +13,55 @@ AC_DEFUN([WAYLAND_SCANNER_RULES], [
> >
> > AC_SUBST([wayland_protocoldir], [$1])
> > ])
> > +
> > +
> > +AC_DEFUN([_WL_PROG_WAYLAND_SCANNER_VERSION_CHECK], [
> > +wl_cv_scanner_version=`${WAYLAND_SCANNER} --version 2>&1 | sed
> > 's/^wayland-scanner //'`
> > +AS_VERSION_COMPARE([${wl_cv_scanner_version}],
> > [${wl_cv_scanner_wanted_version}], [], [
> > +wl_cv_scanner_found=yes
> > +], [])
> > +])
> > +
Hi Quentin,
this is nice, but I think it should also have a comment explaining how
it roughly finds a scanner. This is how I understood it:
1. If WAYLAND_SCANNER env var is set and compatible, use it. Otherwise,
2. if cross-compiling and the build pkg-config is found, use the scanner
found via the build pkg-config if compatible. Otherwise,
3. use the scanner found via the default pkg-config if compatible.
Otherwise,
4. use the scanner found in PATH if compatible. Otherwise,
5. fail.
"Compatible" means that the scanner version must be the same as the
libwayland version found for the host via default pkg-config. So we
also depend on the user projects using default pkg-config to find the
wayland-client and wayland-server libs.
It's also good that it is executing wayland-scanner to find out its
version, meaning that if that file is not actually executable on the
build machine, it will automatically not match.
> > +# WL_PROG_WAYLAND_SCANNER()
> > +AC_DEFUN([WL_PROG_WAYLAND_SCANNER], [
> > +AC_REQUIRE([AC_CANONICAL_BUILD])
> > +AC_REQUIRE([PKG_PROG_PKG_CONFIG])
> > +wl_cv_native_pkg_config=
> > +AS_IF([test x${cross_compiling} = xyes], [
> > +wl_cv_native_pkg_config=${build}-pkg-config
> > +AC_PATH_PROGS([wl_cv_native_pkg_config], [${build}-pkg-config])
> > +])
> > +AC_ARG_VAR([WAYLAND_SCANNER], [wayland-scanner executable])
> > +wl_cv_scanner_found=no
> > +wl_cv_scanner_wanted_version=`${PKG_CONFIG} --modversion
> > wayland-server`
> > +AC_MSG_CHECKING([that wayland-client and wayland-server versions are
> > the same])
> > +AS_IF([test ${wl_cv_scanner_wanted_version} = `${PKG_CONFIG}
> > --modversion wayland-client`], [
> > +AC_MSG_RESULT([ok])
> > +], [
> > +AC_MSG_ERROR([mismatch])
> > +])
> > +AC_MSG_CHECKING([for wayland-scanner ${wl_cv_scanner_wanted_version}])
> > +AS_IF([test x${ac_cv_env_WAYLAND_SCANNER_set} = xset], [
> > +_WL_PROG_WAYLAND_SCANNER_VERSION_CHECK()
> > +])
> > +AS_IF([test x${cross_compiling} = xyes -a x${wl_cv_native_pkg_config}
> > != xno], [
Should this line also test that wl_cv_scanner_found==no? Does it not
overwrite the env var setting otherwise?
> > +AS_IF([AC_RUN_LOG([${wl_cv_native_pkg_config} --exists
> > --print-errors wayland-scanner = ${wl_cv_scanner_wanted_version}])], [
> > +WAYLAND_SCANNER=`${wl_cv_native_pkg_config}
> > --variable=wayland_scanner wayland-scanner =
> > ${wl_cv_scanner_wanted_version}`
> > +_WL_PROG_WAYLAND_SCANNER_VERSION_CHECK()
> > +])
> > +])
> > +AS_IF([test x${wl_cv_scanner_found} = xno], [
> > +AS_IF([AC_RUN_LOG([${PKG_CONFIG} --exists --print-errors
> > wayland-scanner = ${wl_cv_scanner_wanted_version}])], [
> > +WAYLAND_SCANNER=`${PKG_CONFIG} --variable=wayland_scanner
> > wayland-scanner = ${wl_cv_scanner_wanted_version}`
> > +_WL_PROG_WAYLAND_SCANNER_VERSION_CHECK()
> > +])
> > +])
> > +AS_IF([test x${wl_cv_scanner_found} = xno], [
> > +AC_PATH_PROG([WAYLAND_SCANNER], [wayland-scanner])
> > +_WL_PROG
[RFC libweston] Head-based output configuration API a.k.a clone mode infrastructure
Hi, I started designing output configuration API changes earlier this year to accommodate the addition of clone mode to Weston, and in particular a very specific setup: sharing the DRM CRTC for more than one encoder/connector. That setup is the cheapest clone mode possible, with the caveat/feature that the cloned heads all have the exact same video timings. I now have a libweston public API draft written in code, which is why I am sending this announcement. The Phabricator task tracking the whole effort is: https://phabricator.freedesktop.org/T7727 and there is a design draft at: https://phabricator.freedesktop.org/w/wayland/weston/atomic-output-config/ I have not followed my draft exactly so far. I have not introduced weston_canvas to replace weston_output, and I suspect I never will as it seems to be just lots of renaming without benefits. Also the API I ended up writing does not follow the draft on all points. The design overview For a recap on what kind of clone modes are theoretically possible, I recommend reading the email quote in T7727. The new output configuration API has a new object: weston_head. A weston_head represents a connector/monitor, while weston_output remains for the CRTC, the active video mode, the framebuffers, the repaint logic, etc. A libweston user creates a weston_output and attaches at least one head to it. Additional heads will become clones by sharing the CRTC. If sharing the CRTC is not possible, attaching the head or enabling the output will fail, in which case the user should create another weston_output to drive the clone head and just specify the desktop area to show accordingly. (The latter mode of cloning does not currently work correctly in Weston due to the damage tracking design.) Atomic configuration over all outputs will likely not be part of the current effort, but I am keeping it in mind to avoid going the opposite direction. Why not simpler? Introducing weston_head causes quite a lot of churn and code motion, so why did I not simply add a thing like weston_output_clone_output(output1, output2) and hook it up by sharing the CRTC if possible and fall back to the "heavy cloning" automatically? I believe such design would be hard to maintain and use. It is not obvious which weston_output should be responsible for the repaint logic. It is possible for the responsible output to get hot-unplugged, in which case the remaining output should take over the repaint logic. It is also unclear what weston_output_enable/disable() etc. should do on each. API-wise it would be possible to e.g. set differing output scales, so there would need to be code to recognize bad attempts and more error handling. If one then sets out to factor out the common bits that are needed per-CRTC instead of per-connector, you basically end up with the head-based design but with a confusing API that does not differentiate between master and slave outputs. The user could not know what actually happens either, and I imagine in some use cases it would be important to know if the CRTC-sharing works or not because it has a very big impact on the performance and the timings (no gen-lock). IOW, this "simpler" solution would not actually be simpler, even though it might save a few lines of code in libweston users at first. The code Here is the branch: https://git.collabora.com/cgit/user/pq/weston.git/log/?h=clonemode-user-API-1 Mind, that there is an arbitrary version of Daniel's atomic modesetting series before my work. I expect to have to make changes in the DRM-backend, and the atomic modesetting will land before clone mode anyway, so I have been working on top of it. I want to highlight a few commits there: https://git.collabora.com/cgit/user/pq/weston.git/commit/?h=clonemode-user-API-1&id=b0a5d3db4e9f03c9d6f70d68095439fe81b4de1c and the following introduce weston_head. https://git.collabora.com/cgit/user/pq/weston.git/commit/?h=clonemode-user-API-1&id=8a511ce3f2812f69bcd81d8c6169e190d740699e introduces the new way to react to hotplug events. https://git.collabora.com/cgit/user/pq/weston.git/commit/?h=clonemode-user-API-1&id=dbc0e54e955e3e5385188e587061e5e156ec800c introduces the new way of creating and destroying outputs. https://git.collabora.com/cgit/user/pq/weston.git/commit/?h=clonemode-user-API-1&id=13b233a18d62bc5ca8150cb8ae86b0332375954c shows what a simple user implementation using the new API will look like. Eventually the DRM frontend will be using it's own code instead of this to offer all the clone mode options. Notice, how the new API will make it possible to force-enable disconnected connectors. (This is another corner-case I have needed in the wild.) If you look at the code in libweston, you will see that the public API is all actually a fake for now, but it does work (well, should, I haven't tested much). I have internally embedded a weston_head in weston_output and just fiddle with those instead of actually implementing the p
Re: [PATCH wayland] scanner: Add autoconf macro to check for the proper scanner
On 8/18/17 11:30 AM, Quentin Glidic wrote:
From: Quentin Glidic
Projects have been using various ways to check for the wayland-scanner,
mostly based on their developper own use case, and often not allowing
others use cases to work without a workaround.
Hopefully this macro will support all use cases without needing user
action.
Signed-off-by: Quentin Glidic
---
Everyone should test this macro for their own project and use cases.
Using the ${WAYLAND_SCANNER} variable should just work (assuming you have the
proper
wayland package built in the expected env). In very very rare cases, setting the
WAYLAND_SCANNER variable as a ./configure argument may be needed, but nothing
else.
Please let me know with enough details if your use case is not working with it.
Forgot the CCs while sending the patch.
wayland-scanner.m4 | 54 ++
1 file changed, 54 insertions(+)
diff --git a/wayland-scanner.m4 b/wayland-scanner.m4
index 4e4222a..37e0548 100644
--- a/wayland-scanner.m4
+++ b/wayland-scanner.m4
@@ -1,3 +1,5 @@
+#serial 2
+
AC_DEFUN([WAYLAND_SCANNER_RULES], [
PKG_PROG_PKG_CONFIG
@@ -11,3 +13,55 @@ AC_DEFUN([WAYLAND_SCANNER_RULES], [
AC_SUBST([wayland_protocoldir], [$1])
])
+
+
+AC_DEFUN([_WL_PROG_WAYLAND_SCANNER_VERSION_CHECK], [
+wl_cv_scanner_version=`${WAYLAND_SCANNER} --version 2>&1 | sed
's/^wayland-scanner //'`
+AS_VERSION_COMPARE([${wl_cv_scanner_version}],
[${wl_cv_scanner_wanted_version}], [], [
+wl_cv_scanner_found=yes
+], [])
+])
+
+# WL_PROG_WAYLAND_SCANNER()
+AC_DEFUN([WL_PROG_WAYLAND_SCANNER], [
+AC_REQUIRE([AC_CANONICAL_BUILD])
+AC_REQUIRE([PKG_PROG_PKG_CONFIG])
+wl_cv_native_pkg_config=
+AS_IF([test x${cross_compiling} = xyes], [
+wl_cv_native_pkg_config=${build}-pkg-config
+AC_PATH_PROGS([wl_cv_native_pkg_config], [${build}-pkg-config])
+])
+AC_ARG_VAR([WAYLAND_SCANNER], [wayland-scanner executable])
+wl_cv_scanner_found=no
+wl_cv_scanner_wanted_version=`${PKG_CONFIG} --modversion wayland-server`
+AC_MSG_CHECKING([that wayland-client and wayland-server versions are the
same])
+AS_IF([test ${wl_cv_scanner_wanted_version} = `${PKG_CONFIG} --modversion
wayland-client`], [
+AC_MSG_RESULT([ok])
+], [
+AC_MSG_ERROR([mismatch])
+])
+AC_MSG_CHECKING([for wayland-scanner ${wl_cv_scanner_wanted_version}])
+AS_IF([test x${ac_cv_env_WAYLAND_SCANNER_set} = xset], [
+_WL_PROG_WAYLAND_SCANNER_VERSION_CHECK()
+])
+AS_IF([test x${cross_compiling} = xyes -a x${wl_cv_native_pkg_config} !=
xno], [
+AS_IF([AC_RUN_LOG([${wl_cv_native_pkg_config} --exists --print-errors
wayland-scanner = ${wl_cv_scanner_wanted_version}])], [
+WAYLAND_SCANNER=`${wl_cv_native_pkg_config}
--variable=wayland_scanner wayland-scanner = ${wl_cv_scanner_wanted_version}`
+_WL_PROG_WAYLAND_SCANNER_VERSION_CHECK()
+])
+])
+AS_IF([test x${wl_cv_scanner_found} = xno], [
+AS_IF([AC_RUN_LOG([${PKG_CONFIG} --exists --print-errors
wayland-scanner = ${wl_cv_scanner_wanted_version}])], [
+WAYLAND_SCANNER=`${PKG_CONFIG} --variable=wayland_scanner
wayland-scanner = ${wl_cv_scanner_wanted_version}`
+_WL_PROG_WAYLAND_SCANNER_VERSION_CHECK()
+])
+])
+AS_IF([test x${wl_cv_scanner_found} = xno], [
+AC_PATH_PROG([WAYLAND_SCANNER], [wayland-scanner])
+_WL_PROG_WAYLAND_SCANNER_VERSION_CHECK()
+])
+AS_IF([test x${wl_cv_scanner_found} = xno], [
+AC_MSG_ERROR([no usable wayland-scanner executable version
${wl_cv_scanner_wanted_version}])
+])
+AC_MSG_RESULT([${WAYLAND_SCANNER}])
+])
--
Quentin “Sardem FF7” Glidic
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH wayland] scanner: Add autoconf macro to check for the proper scanner
From: Quentin Glidic
Projects have been using various ways to check for the wayland-scanner,
mostly based on their developper own use case, and often not allowing
others use cases to work without a workaround.
Hopefully this macro will support all use cases without needing user
action.
Signed-off-by: Quentin Glidic
---
Everyone should test this macro for their own project and use cases.
Using the ${WAYLAND_SCANNER} variable should just work (assuming you have the
proper
wayland package built in the expected env). In very very rare cases, setting the
WAYLAND_SCANNER variable as a ./configure argument may be needed, but nothing
else.
Please let me know with enough details if your use case is not working with it.
wayland-scanner.m4 | 54 ++
1 file changed, 54 insertions(+)
diff --git a/wayland-scanner.m4 b/wayland-scanner.m4
index 4e4222a..37e0548 100644
--- a/wayland-scanner.m4
+++ b/wayland-scanner.m4
@@ -1,3 +1,5 @@
+#serial 2
+
AC_DEFUN([WAYLAND_SCANNER_RULES], [
PKG_PROG_PKG_CONFIG
@@ -11,3 +13,55 @@ AC_DEFUN([WAYLAND_SCANNER_RULES], [
AC_SUBST([wayland_protocoldir], [$1])
])
+
+
+AC_DEFUN([_WL_PROG_WAYLAND_SCANNER_VERSION_CHECK], [
+wl_cv_scanner_version=`${WAYLAND_SCANNER} --version 2>&1 | sed
's/^wayland-scanner //'`
+AS_VERSION_COMPARE([${wl_cv_scanner_version}],
[${wl_cv_scanner_wanted_version}], [], [
+wl_cv_scanner_found=yes
+], [])
+])
+
+# WL_PROG_WAYLAND_SCANNER()
+AC_DEFUN([WL_PROG_WAYLAND_SCANNER], [
+AC_REQUIRE([AC_CANONICAL_BUILD])
+AC_REQUIRE([PKG_PROG_PKG_CONFIG])
+wl_cv_native_pkg_config=
+AS_IF([test x${cross_compiling} = xyes], [
+wl_cv_native_pkg_config=${build}-pkg-config
+AC_PATH_PROGS([wl_cv_native_pkg_config], [${build}-pkg-config])
+])
+AC_ARG_VAR([WAYLAND_SCANNER], [wayland-scanner executable])
+wl_cv_scanner_found=no
+wl_cv_scanner_wanted_version=`${PKG_CONFIG} --modversion wayland-server`
+AC_MSG_CHECKING([that wayland-client and wayland-server versions are the
same])
+AS_IF([test ${wl_cv_scanner_wanted_version} = `${PKG_CONFIG} --modversion
wayland-client`], [
+AC_MSG_RESULT([ok])
+], [
+AC_MSG_ERROR([mismatch])
+])
+AC_MSG_CHECKING([for wayland-scanner ${wl_cv_scanner_wanted_version}])
+AS_IF([test x${ac_cv_env_WAYLAND_SCANNER_set} = xset], [
+_WL_PROG_WAYLAND_SCANNER_VERSION_CHECK()
+])
+AS_IF([test x${cross_compiling} = xyes -a x${wl_cv_native_pkg_config} !=
xno], [
+AS_IF([AC_RUN_LOG([${wl_cv_native_pkg_config} --exists --print-errors
wayland-scanner = ${wl_cv_scanner_wanted_version}])], [
+WAYLAND_SCANNER=`${wl_cv_native_pkg_config}
--variable=wayland_scanner wayland-scanner = ${wl_cv_scanner_wanted_version}`
+_WL_PROG_WAYLAND_SCANNER_VERSION_CHECK()
+])
+])
+AS_IF([test x${wl_cv_scanner_found} = xno], [
+AS_IF([AC_RUN_LOG([${PKG_CONFIG} --exists --print-errors
wayland-scanner = ${wl_cv_scanner_wanted_version}])], [
+WAYLAND_SCANNER=`${PKG_CONFIG} --variable=wayland_scanner
wayland-scanner = ${wl_cv_scanner_wanted_version}`
+_WL_PROG_WAYLAND_SCANNER_VERSION_CHECK()
+])
+])
+AS_IF([test x${wl_cv_scanner_found} = xno], [
+AC_PATH_PROG([WAYLAND_SCANNER], [wayland-scanner])
+_WL_PROG_WAYLAND_SCANNER_VERSION_CHECK()
+])
+AS_IF([test x${wl_cv_scanner_found} = xno], [
+AC_MSG_ERROR([no usable wayland-scanner executable version
${wl_cv_scanner_wanted_version}])
+])
+AC_MSG_RESULT([${WAYLAND_SCANNER}])
+])
--
2.13.4
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Add serial to wl_output::geometry?
Hi, Am Freitag, den 18.08.2017, 10:47 +0300 schrieb Pekka Paalanen: > On Thu, 03 Aug 2017 08:27:06 -0400 > Simon Ser wrote: > > > Hello, > > I'm writing a Wayland client that needs to keep track of screens > > across reboots. I registered a wl_output::geometry event handler. > > This event already has the fields "make" and "model", but is > > missing > > "serial". Is there a way to get an output serial (something like > > "HS3P505873")? Would it be possible to add it to the protocol or is > > it too late? Is there another way to identify screens? > > Hi Simon, > > these are very good questions. I have a vague recollection this has > been discussed before on wayland-devel@, but personally I may have > been > skeptical about the use cases at the time. For reference: https://lists.freedesktop.org/archives/wayland-devel/2017-May/034083.html A lot of points were discussed back then already. > Anyway, nowadays I think adding the physical monitor serial to > wl_output as a new event should be fine. There are some details to > discuss like if the monitor hardware does not provide a reliable > serial, should the compositor maybe manufacture some GUID or just > leave > the serial unset. What about "monitors" that are not physical > devices, > like a window in another window system - should one relay the serial > from the other window system's monitor, manufacture an artificial > GUID > based on e.g. window system connection, or just not send a serial at > all. You could argue that similar concerns apply to "make" and "model", but they only have a very vague description in the protocol. > Maybe it would be best to just say the serial is from a locally > connected monitor hardware (or equivalent), and leave the cases where > the hardware serial is not available or the output is not a local > physical monitor to not send a serial. Also needs to be discussed whether the values should be compatible accross compositors (e.g. make and model are not currently because of their vague definition). Regards, Philipp ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Add serial to wl_output::geometry?
On Thu, 03 Aug 2017 08:27:06 -0400 Simon Ser wrote: > Hello, > I'm writing a Wayland client that needs to keep track of screens > across reboots. I registered a wl_output::geometry event handler. > This event already has the fields "make" and "model", but is missing > "serial". Is there a way to get an output serial (something like > "HS3P505873")? Would it be possible to add it to the protocol or is > it too late? Is there another way to identify screens? Hi Simon, these are very good questions. I have a vague recollection this has been discussed before on wayland-devel@, but personally I may have been skeptical about the use cases at the time. Identifying an output and monitor serial are not exactly equivalent, so what we should have depends on the use case. If you actually want to identify a physical monitor, then serial (if such is available in hardware to begin with!) would be good. If you just wanted to identify an output e.g. based on the physical connector or desktop layout, then serial is obviously not the solution. Anyway, nowadays I think adding the physical monitor serial to wl_output as a new event should be fine. There are some details to discuss like if the monitor hardware does not provide a reliable serial, should the compositor maybe manufacture some GUID or just leave the serial unset. What about "monitors" that are not physical devices, like a window in another window system - should one relay the serial from the other window system's monitor, manufacture an artificial GUID based on e.g. window system connection, or just not send a serial at all. Maybe it would be best to just say the serial is from a locally connected monitor hardware (or equivalent), and leave the cases where the hardware serial is not available or the output is not a local physical monitor to not send a serial. What do you want to identify the physical monitors for, exactly? Thanks, pq pgpt3YA0btnVc.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC wayland-protocols] presentation-time: Add request to subscribe to wl_output presentation timings
On Thu, 17 Aug 2017 17:03:22 +0300 Alexandros Frantzis wrote: > On Thu, Aug 17, 2017 at 11:10:12AM +0300, Pekka Paalanen wrote: > > On Mon, 7 Aug 2017 19:00:40 +0300 > > Alexandros Frantzis wrote: > > > > > The presentation.timing request creates an object that informs the > > > client about the presentation timing of an wl_output in a precise and > > > low-overhead way, without the need to submit any surface content updates. > > > > > ... > > > diff --git a/stable/presentation-time/presentation-time.xml > > > b/stable/presentation-time/presentation-time.xml > > > index a46994c..56a9c9b 100644 > > > --- a/stable/presentation-time/presentation-time.xml > > > +++ b/stable/presentation-time/presentation-time.xml > > > @@ -3,7 +3,7 @@ > > > > > > > > > > > > -Copyright © 2013-2014 Collabora, Ltd. > > > +Copyright © 2013-2017 Collabora, Ltd. > > > > Just checking, the Chromium extension's copyrights don't need to be > > added here, do they? > > Actually, I think we should add them, since the proposed additions are > heavily based on the Chromium protocol, I just forgot to do so for this RFC. > > > > Permission is hereby granted, free of charge, to any person > > > obtaining a > > > copy of this software and associated documentation files (the > > > "Software"), > > > @@ -25,8 +25,8 @@ > > > DEALINGS IN THE SOFTWARE. > > > > > > > > > - > > > - > > > + > > > + > > > > > > > > > > > > @@ -49,6 +49,16 @@ > > >presentation time can differ from the compositor's predicted > > >display update time and the update's target time, especially > > >when the compositor misses its target vertical blanking period. > > > + > > > + > > > + > > > + In some cases it's also useful for clients to know about the > > > + presentation timing of an output without having submitted a > > > + surface content update. For this purpose the 'timing' request > > > + creates an object that is used to inform the client about > > > + the presentation timing of an wl_output in a precise and > > > + low-overhead way. > > > + > > > > > > > > > > > > @@ -122,6 +132,22 @@ > > > > > > > > > > > > + > > > + > > > + > > > + > > > +Create a new timing object that represents a subscription to > > > +presentation timing updates on the given wl_output object. > > > + > > > +The newly created object will signal an update to notify the > > > subscriber > > > +of initial timing parameters as soon as these become available. > > > > If the output was already or becomes destroyed in the compositor, there > > will be no event, right? More below. > > Correct. > > > > + > > > + > > + summary="the wl_output object to subscribe for timings of"/> > > > + > > + summary="the new timing object"/> > > > + > > > + > > > > > > > > > > > > @@ -263,4 +289,40 @@ > > > > > > > > > > > > + > > > > An interface can have an overhead doc as well. It might be a nice place > > to document how a wp_presentation_timing object reacts to: > > > > a) the output being destroyed in the compositor > > > > b) the wl_output object used in wp_presentation.timing request being > >destroyed by the client > > In both cases the timing object just becomes inactive (no events sent) > and should be eventually destroyed by the client. I will add a section > to clarify. Hi Alf, we have used the technical term "inert" to describe objects that are essentially dead and should be destroyed by the client soon (but their use must not cause protocol errors as clients would not be able to guarantee they'll never use them, due to racing between the compositor and the client). > > Another thing is, how will a client know which output's timings it > > should be looking at for a specific wl_surface. The wl_surface enter > > and leave events do not tell that when a surface is on more than one > > output at the same time, the client won't know which one the compositor > > is using for the timings. The client needs to use > > wp_presentation_feedback to know which output it is at any time. > > > > This brings a different idea to my mind: what if the timings were asked > > for a wl_surface instead of a wl_output? The issue with that is > > surfaces that are not currently shown, like ones that are not mapped > > yet, are off-screen, etc. OTOH, maybe the issue is not significant: in > > a multi-output setup, you cannot always know which output a surface > > will be synced to anyway until it actually becomes visible. > > > > Which design would better serve the use cases? > > I think associating the timing with the surface instead of the output is > both a good idea and it's also closer to the spirit of the current > presentation-timing v1 protocol. 'timing' would essentially become a > lighter, permanent and less spam-y version
Re: wl_shm_format documentation
On Thu, 17 Aug 2017 23:20:51 +0200 Fredrik Höglund wrote: > Hi, > > I noticed that the documentation for wl_shm_format doesn't specify whether > formats use premultiplied alpha or not. Is that intentional or an oversight? Hi, I think that's an oversight indeed. I'm actually surprised to not find a single match for "multiplied" in the Wayland repository. All RGB-based formats with alpha are pre-multiplied. For AYUV probably no-one knows. Thanks, pq pgpdXVRiK7qKH.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
