Re: [PATCH] protocol: add set_scaling_filter request to wl_surface interface
On Fri, 20 Dec 2019 12:34:42 +0530 Sameer Lattannavar wrote: > This is an extension for wl_surface interface to support > setting scaling filter. Client can request set_scaling_filter. > > Protocol implementation posted at: > https://lists.freedesktop.org/archives/wayland-devel/2019-December/041098.html > > Signed-off-by: Sameer Lattannavar > --- > protocol/wayland.xml | 27 +++ > 1 file changed, 27 insertions(+) > > diff --git a/protocol/wayland.xml b/protocol/wayland.xml > index f1a13b7..3bb4df6 100644 > --- a/protocol/wayland.xml > +++ b/protocol/wayland.xml > @@ -1715,6 +1715,33 @@ > > > > + > + > + > + Blurry outputs during upscaling the video buffer, is a generic > + issue of graphics industry. One of the major reason behind this > + blurriness is the interpolation of pixel values used by most of the > + upscaling hardwares. > + > + Nearest-neighbor is a scaling_filter type, which works by filling in the > + missing color values in the upscaled image with that of the > + coordinate-mapped nearest source pixel value. > + > + Nearest-neighbor can produce (almost) non-blurry scaling outputs when > + the scaling ratio is complete integer. For example: > + - input buffer resolution: 1280x720(HD) > + - output buffer resolution: 3840x2160(UHD/4K) > + - scaling ratio (h) = 3840/1280 = 3 > + - scaling ratio (v) = 2160/720 = 3 > + > + In such scenarios, we should try to pick Nearest-neighbor as scaling > + method when possible. > + > + +summary="Positive scaling filter for interpretting type > +of filter to be used for integer scaling"/> > + > + > > Hi, why is this something that the client should be able to set? Why not have the compositor choose the method automatically based on e.g. content and output resolutions where it can take into account all the image processing, unlike a client ever could? The compositor itself is already choosing the scaling methods for surfaces it decides or needs to scale itself (due to output scale, buffer scale, wp_viewporter, fractional scaling, etc.). Since KMS planes are just a compositor implementation detail of how to realize the composition, the compositor will want to use the same scaling method in KMS as it uses with its renderer (e.g. OpenGL). Assuming the above questions are answered and the answers properly justified, this should be a new extension in wayland-protocols (like e.g. wp_viewporter is) and not on wl_surface in wayland.xml. We do not extend the wayland.xml interfaces unless it is absolutely necessary. We want to keep the fundamental protocol interfaces generic, simple and maintainable. Please also do all your Wayland, wayland-protocols, and Weston patch submissions in Gitlab as per the Contribution guidelines in each repository. Thanks, pq pgpHynGPCfEvz.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH] protocol: add set_scaling_filter request to wl_surface interface
This is an extension for wl_surface interface to support setting scaling filter. Client can request set_scaling_filter. Protocol implementation posted at: https://lists.freedesktop.org/archives/wayland-devel/2019-December/041098.html Signed-off-by: Sameer Lattannavar --- protocol/wayland.xml | 27 +++ 1 file changed, 27 insertions(+) diff --git a/protocol/wayland.xml b/protocol/wayland.xml index f1a13b7..3bb4df6 100644 --- a/protocol/wayland.xml +++ b/protocol/wayland.xml @@ -1715,6 +1715,33 @@ + + + + Blurry outputs during upscaling the video buffer, is a generic + issue of graphics industry. One of the major reason behind this + blurriness is the interpolation of pixel values used by most of the + upscaling hardwares. + + Nearest-neighbor is a scaling_filter type, which works by filling in the + missing color values in the upscaled image with that of the + coordinate-mapped nearest source pixel value. + + Nearest-neighbor can produce (almost) non-blurry scaling outputs when + the scaling ratio is complete integer. For example: + - input buffer resolution: 1280x720(HD) + - output buffer resolution: 3840x2160(UHD/4K) + - scaling ratio (h) = 3840/1280 = 3 + - scaling ratio (v) = 2160/720 = 3 + + In such scenarios, we should try to pick Nearest-neighbor as scaling + method when possible. + + + + -- 2.17.1 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
[RFC weston 2/3] drm-backend: drm-backend changes for setting scaling_fitler
Modify existing drm-backend to set_scaling_filter property that
client has requested compositor to do.
drm-backend calls drmset property api of libdrm to do so.
Signed-off-by: Sameer Lattannavar
---
libweston/backend-drm/drm-internal.h | 18
libweston/backend-drm/drm.c | 41 ++--
libweston/backend-drm/kms.c | 14 ++
3 files changed, 71 insertions(+), 2 deletions(-)
diff --git a/libweston/backend-drm/drm-internal.h
b/libweston/backend-drm/drm-internal.h
index 2384a9ac..6cda84f1 100644
--- a/libweston/backend-drm/drm-internal.h
+++ b/libweston/backend-drm/drm-internal.h
@@ -224,12 +224,24 @@ enum wdrm_dpms_state {
WDRM_DPMS_STATE__COUNT
};
+enum wdrm_scaling_filters {
+ WDRM_SCALING_FILTER_DEFAULT,
+ WDRM_SCALING_FILTER_MEDIUM,
+ WDRM_SCALING_FILTER_BILINEAR,
+ WDRM_SCALING_FILTER_NN,
+ WDRM_SCALING_FILTER_NN_IS_ONLY,
+ WDRM_SCALING_FILTER_EDGE_ENHANCE,
+ WDRM_SCALING_FILTER_INVALID,
+ WDRM_SCALING_FILTER__COUNT
+};
+
/**
* List of properties attached to DRM CRTCs
*/
enum wdrm_crtc_property {
WDRM_CRTC_MODE_ID = 0,
WDRM_CRTC_ACTIVE,
+ WDRM_SCALING_FILTER,
WDRM_CRTC__COUNT
};
@@ -484,6 +496,12 @@ struct drm_output {
/* Holds the properties for the CRTC */
struct drm_property_info props_crtc[WDRM_CRTC__COUNT];
+ /*To flag if HW supports the Scaling filter as one of the CRTC
+*properties for scailing the output
+*/
+ bool flag_scaling_filter;
+ int scaling_filter_type;
+
bool page_flip_pending;
bool atomic_complete_pending;
bool destroy_pending;
diff --git a/libweston/backend-drm/drm.c b/libweston/backend-drm/drm.c
index e0b1cbd7..6e6ddd72 100644
--- a/libweston/backend-drm/drm.c
+++ b/libweston/backend-drm/drm.c
@@ -768,7 +768,7 @@ drm_plane_create(struct drm_backend *b, const drmModePlane
*kplane,
WDRM_PLANE_TYPE__COUNT);
zpos_range_values =
-
drm_property_get_range_values(>props[WDRM_PLANE_ZPOS],
+
drm_property_get_range_values(>props[WDRM_PLANE_ZPOS],
props);
if (zpos_range_values) {
@@ -1120,6 +1120,34 @@ drm_set_dpms(struct weston_output *output_base, enum
dpms_enum level)
weston_log("drm_set_dpms: couldn't disable output?\n");
}
+/*
+ * If we are upscaling, and the scaling ratios are integer, we can
+ * pick nearest-neighbour method in HW for scaling, which produces
+ * blurless outputs in such scenarios.
+ */
+static void
+drm_set_scaling_filter(struct weston_output *output_base,
+ enum wdrm_scaling_filters filter)
+{
+ weston_log("drm_set_integer_scaling: to set the scaling_filter\n");
+ struct drm_output *output = to_drm_output(output_base);
+ struct drm_backend *b = to_drm_backend(output_base->compositor);
+ int ret;
+
+ if (output->flag_scaling_filter) {
+ ret = drmModeObjectSetProperty(b->drm.fd, output->crtc_id,
+ DRM_MODE_OBJECT_CRTC,
+ output->props_crtc->prop_id,
+ output->scaling_filter_type);
+ if (ret) {
+ weston_log("drmModeObjectSetProperty: FAILED!!!\n");
+ output->scaling_filter_type =
+ WDRM_SCALING_FILTER_DEFAULT;
+ }
+ weston_log("drmModeObjectSetProperty: Succeeded\n");
+ }
+}
+
static const char * const connector_type_names[] = {
[DRM_MODE_CONNECTOR_Unknown] = "Unknown",
[DRM_MODE_CONNECTOR_VGA] = "VGA",
@@ -1592,7 +1620,7 @@ drm_output_init_crtc(struct drm_output *output,
drmModeRes *resources)
{
struct drm_backend *b = to_drm_backend(output->base.compositor);
drmModeObjectPropertiesPtr props;
- int i;
+ int i, x;
assert(output->crtc_id == 0);
@@ -1614,6 +1642,14 @@ drm_output_init_crtc(struct drm_output *output,
drmModeRes *resources)
}
drm_property_info_populate(b, crtc_props, output->props_crtc,
WDRM_CRTC__COUNT, props);
+ if (output->props_crtc) {
+ for (x = 0; x < WDRM_CRTC__COUNT; x++) {
+ if (strcmp(output->props_crtc->name, "SCALING_FILTERS"))
+ continue;
+ output->flag_scaling_filter = true;
+ output->scaling_filter_type = WDRM_SCALING_FILTER_NN;
+ }
+ }
drmModeFreeObjectProperties(props);
output->scanout_plane =
@@ -1732,6 +1768,7 @@ drm_output_enable(struct weston_output *base)
output->base.set_dpms = drm_set_dpms;
output->base.switch_mode = drm_output_switch_mode;
[RFC weston 1/3] libweston: add set_scaling_filter API and implementation
set_scaling_filter is a libweston API for setting scaling filter and
wayland protocol extension implementation for setting crtc property as
per client's request.
Signed-off-by: Sameer Lattannavar
---
include/libweston/libweston.h | 7 +++
libweston/compositor.c| 25 -
2 files changed, 31 insertions(+), 1 deletion(-)
diff --git a/include/libweston/libweston.h b/include/libweston/libweston.h
index dc54b170..12e25c67 100644
--- a/include/libweston/libweston.h
+++ b/include/libweston/libweston.h
@@ -321,6 +321,13 @@ struct weston_output {
bool enabled; /**< is in the output_list, not pending list */
int scale;
+ /*
+* set_scaling_filter: this function pointer calls into
+* drm_scaling_filter to set CRTC property to NN filter to get
+* non-blurry frames for Pixel-Art games.
+*/
+ void (*set_scaling_filter)(struct weston_output *output, int filter);
+
int (*enable)(struct weston_output *output);
int (*disable)(struct weston_output *output);
diff --git a/libweston/compositor.c b/libweston/compositor.c
index dbc64927..28f5054c 100644
--- a/libweston/compositor.c
+++ b/libweston/compositor.c
@@ -3753,6 +3753,28 @@ surface_set_buffer_scale(struct wl_client *client,
surface->pending.buffer_viewport.changed = 1;
}
+static void
+surface_set_scaling_filter(struct wl_client *client,
+ struct wl_resource *resource,
+ int scaling_filter)
+{
+ struct weston_surface *surface = wl_resource_get_user_data(resource);
+ struct weston_output *w_output;
+
+ if (scaling_filter < 0) {
+ wl_resource_post_error(resource,
+ WL_SURFACE_ERROR_INVALID_SCALE,
+ "Supported Scaling Filter not selected",
+ "(%d' specified)", scaling_filter);
+ return;
+ }
+ wl_list_for_each(w_output, >compositor->output_list, link) {
+ weston_log("Scaling_filter: weston_output Name: %s\n",
+ w_output->name);
+ w_output->set_scaling_filter(w_output, scaling_filter);
+ }
+}
+
static const struct wl_surface_interface surface_interface = {
surface_destroy,
surface_attach,
@@ -3763,7 +3785,8 @@ static const struct wl_surface_interface
surface_interface = {
surface_commit,
surface_set_buffer_transform,
surface_set_buffer_scale,
- surface_damage_buffer
+ surface_damage_buffer,
+ surface_set_scaling_filter
};
static void
--
2.17.1
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
[RFC weston 0/3] add scaling filter support
Background: Blurry outputs during upscaling the video buffer, is a generic problem of graphics industry. One of the major reason behind this blurriness is the interpolation of pixel values used by most of the upscaling hardware. Nearest-neighbor is a scaling filter type, which works by filling in the missing color values in the upscaled image with that of the coordinate-mapped nearest source pixel value. Nearest-neighbor can produce (almost) non-blurry scaling outputs when the scaling ratio is complete integer. For example: - input buffer resolution: 1280x720(HD) - output buffer resolution: 3840x2160(UHD/4K) - scaling ratio (h) = 3840/1280 = 3 - scaling ratio (v) = 2160/720 = 3 In such scenarios, we should try to pick Nearest-neighbor as scaling method when possible. This patch series: To address this feature kernel driver exposes new CRTC property called "SCALING_FILTERS" and gives an option to userspace to set it based on the use cases. Kernel RFC can be found here: https://patchwork.freedesktop.org/series/68378/ This patchset add support for utilizing CRTC scaling filter property based on client's usecase. Sameer Lattannavar (3): libweston: add set_scaling_filter API and implementation drm-backend: drm-backend changes for setting scaling_fitler client: image client requesting for scaling filter type. clients/image.c | 49 +++- clients/window.c | 7 clients/window.h | 4 +++ include/libweston/libweston.h| 7 libweston/backend-drm/drm-internal.h | 18 ++ libweston/backend-drm/drm.c | 41 +-- libweston/backend-drm/kms.c | 14 libweston/compositor.c | 25 +- 8 files changed, 154 insertions(+), 11 deletions(-) -- 2.17.1 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
[RFC weston 3/3] client: image client requesting for scaling filter type.
Modify existing sample weston client image application to add
a scaling_filter request through commandline parameter.
Signed-off-by: Sameer Lattannavar
---
clients/image.c | 49
clients/window.c | 7 +++
clients/window.h | 4
3 files changed, 52 insertions(+), 8 deletions(-)
diff --git a/clients/image.c b/clients/image.c
index 0a8fb5b5..b1bc5637 100644
--- a/clients/image.c
+++ b/clients/image.c
@@ -44,6 +44,17 @@
#include "window.h"
#include "shared/cairo-util.h"
+enum weston_scaling_filters {
+ WDRM_SCALING_FILTER_DEFAULT = 0,
+ WDRM_SCALING_FILTER_MEDIUM,
+ WDRM_SCALING_FILTER_BILINEAR,
+ WDRM_SCALING_FILTER_NN,
+ WDRM_SCALING_FILTER_NN_IS_ONLY,
+ WDRM_SCALING_FILTER_EDGE_ENHANCE,
+ WDRM_SCALING_FILTER_INVALID,
+ WDRM_SCALING_FILTER__COUNT
+};
+
struct image {
struct window *window;
struct widget *widget;
@@ -355,6 +366,8 @@ close_handler(void *data)
free(image);
}
+int request_scaling_filter;
+
static struct image *
image_create(struct display *display, const char *filename,
int *image_counter)
@@ -402,20 +415,38 @@ image_create(struct display *display, const char
*filename,
widget_set_axis_handler(image->widget, axis_handler);
window_set_key_handler(image->window, key_handler);
widget_schedule_resize(image->widget, 500, 400);
+ if (request_scaling_filter)
+ window_set_scaling_filter(image->window,
+ WDRM_SCALING_FILTER_NN);
return image;
}
+static void
+usage()
+{
+ fprintf(stderr, "Usage: weston-image [OPTIONS]\n\n");
+ fprintf(stderr, "Options:"
+ "-is \t Image to display withi \t"
+ "scaling filter type for integer scaling\n"
+ " ...\n"
+ "-h\tThis help text\n\n");
+
+ exit(0);
+}
+
int
main(int argc, char *argv[])
{
struct display *d;
int i;
int image_counter = 0;
-
- if (argc <= 1 || argv[1][0]=='-') {
- printf("Usage: %s image...\n", argv[0]);
- return 1;
+ for (i = 0; i < argc; i++) {
+ if (strcmp("-is", argv[i]) == 0 && argc == 3) {
+ request_scaling_filter = 1;
+ } else if (argc <= 1 || (strcmp("-h", argv[i]) == 0)
+ || (strcmp("-help", argv[i]) == 0))
+ usage();
}
d = display_create(, argv);
@@ -424,10 +455,12 @@ main(int argc, char *argv[])
strerror(errno));
return -1;
}
-
- for (i = 1; i < argc; i++)
- image_create(d, argv[i], _counter);
-
+ if (request_scaling_filter) {
+ image_create(d, argv[2], _counter);
+ } else {
+ for (i = 1; i < argc; i++)
+ image_create(d, argv[i], _counter);
+ }
if (image_counter > 0)
display_run(d);
diff --git a/clients/window.c b/clients/window.c
index 2bd303ee..03ec80ab 100644
--- a/clients/window.c
+++ b/clients/window.c
@@ -1505,6 +1505,13 @@ window_set_buffer_scale(struct window *window,
scale);
}
+void
+window_set_scaling_filter(struct window *window,
+ int scaling_filter)
+{
+ wl_surface_set_scaling_filter(window->main_surface->surface,
+ scaling_filter);
+}
uint32_t
window_get_buffer_scale(struct window *window)
{
diff --git a/clients/window.h b/clients/window.h
index c66dd065..f86c579c 100644
--- a/clients/window.h
+++ b/clients/window.h
@@ -345,6 +345,10 @@ void
window_set_buffer_scale(struct window *window,
int32_t scale);
+void
+window_set_scaling_filter(struct window *window,
+ int scaling_filter);
+
uint32_t
window_get_output_scale(struct window *window);
--
2.17.1
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Popups over desktop toolbar
Hi, this is most likely mutter questing, but I'll try it anyway. Is it possible to position popup above the desktop toolbar like XWayland or X11 do? Screenshots worth thousands words: Wayland popup: https://ibb.co/0jtsj51 vs. XWayland popup: https://ibb.co/G0HTRVC -- Jan Horak Senior Software Engineer Red Hat ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: XDG_RUNTIME_DIR on a system with no "logins"
On Thu, 19 Dec 2019 10:33:09 + Alan Griffiths wrote: > On 19/12/2019 10:28, Guillermo Rodriguez wrote: > > Uhm. I am not sure I can switch to systemd at this point. > > How does this (Weston being ready / not ready) look like from the client > > side? > > > > i.e. if I want to make sure the client is launched once Weston is ready, > > 1. Is there any way to manually check whether Weston is ready? (e.g. > > some sentinel file being created or similar) > > or failing that, > > 2. Is there any recognizable error code if the client tries to launch > > before Weston is ready (so that I can wait a bit and retry) > > I can't answer specifically for Weston, but I imagine this would be the > same for any Wayland compositor. > > With our IoT solutions we wait for the $XDG_RUNTIME_DIR/$WAYLAND_DISPLAY > file (or $XDG_RUNTIME_DIR/wayland-0) file before trying to connect. The > server ought to be ready once that has been created. Yes, I can't think of why that wouldn't work, at least if you ensure the socket file does not exist before you start Weston. IIRC there is also a lock file to go with the socket file, but I am unsure how to make use of that without making Weston fail. You'd want to check the lock file is flock()'d (the compositor is using it, so it should be ready) but you don't want to lock it yourself (that would prevent Weston from using the socket). The failure mode of "Weston not ready yet" is that the client cannot connect: wl_display_connect() fails. I don't remember the function error codes, and you'd need the client toolkit to forward that error specifically anyway, so I'm not sure it is possible to differentiate between connection error and other errors from a launch script too easily. Thanks, pq pgpar2ecEuY36.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Floating windows in input-method
Hi Silvan, On Mon, 16 Dec 2019 20:56:12 +0100 "Silvan Jegen" wrote: > Hi > > Simon Ser wrote: > > Hi Dorota, > > > > On Sunday, December 15, 2019 7:55 PM, Dorota Czaplejewicz > > wrote: > > > > > Hi all, > > > > > > in order to give this change more traction, I've been thinking about > > > slimming down the protocol, and removing floating windows from this > > > revision. > > > > > > This would make the protocol easier to implement, and since we > > > already have an implementation missing this feature in wlroots, also > > > effectively verified. We've been successfully using the protocol on > > > the Librem 5, and completion windows seem like something possible to > > > mimic using a protocol like layer-shell, and in the phone case, this > > > would be the desirable way to do it. > > > > > > Since floating windows are usually used for CJK languages on the > > > desktop, can I get some opinions? Do you think the protocol would be > > > useful and an improvement over the v1 even if it didn't initially > > > include floating windows? > > > > I think this is a good idea. > > > > Doing this would ease protocol review and make it so the implementation > > matches the protocol. The extra floating window bits can be added > > later anyway, and we'll be able to discuss what's the best way to > > implement them. > > Would the floating windows be added in a new version of the input-method > protocol or do you think a new protocol would be used for that? > It belongs to the same protocol, the input popup doesn't make sense if it isn't a response to an earlier activation of a text input, so a any floating window protocol would have to be tightly bound to input_method anyway. > As Dorota mentioned, for CJK languages those are very > important. Unfortunately I didn't get very far trying to implement a > version of the input_popup [0][1] but I would like to know where their > protocol should be added in your opinion. > Hope that clarifies it. Cheers, Dorota > > Cheers, > > Silvan > > > [0] https://github.com/Shugyousha/wlroots/commits/popupsurface > [1] > https://lists.sr.ht/~sircmpwn/public-inbox/%3C2DLX6MQ13DS0R.25O72Q0XN9BGC%40homearch.localdomain%3E > > > > Btw, we are now using GitLab for wayland-protocols development: feel > > free to submit your patch there (and potentially your earlier pending > > patches too!). > > > > Thanks, > > > > Simon > > > > > Thanks, > > > Dorota Czaplejewicz > > > > > > On Thu, 4 Oct 2018 20:00:13 + > > > Dorota Czaplejewicz dorota.czaplejew...@puri.sm wrote: > > > > > > > This protocol is based on v1, current text-input-v3, and wl_keyboard > > > > version 6. > > > > The pieces passing data relevant to the application on the other side > > > > of the compositor are a mirror copy of text-input-v3 events and > > > > requests. > > > > Compared to input-method-v1: > > > > > > > > - assumes that once preedit is displayed, no selection can be active, > > > > removing some selection handling > > > > - follow text-input and removes language indicators > > > > - explicitly attaches to seats > > > > - removes "commit" text which would replace the preedit string > > > > automatically in case it wasn't "confirmed" (whatever it means) > > > > - adds double-buffering in the same places as text-input-v3 > > > > - drops input_method_context and places its functionality directly in > > > > input_method > > > > - removes the ability to move the cursor position outside of preedit. > > > > It still allows to delete a larger chunk of text and replace it with a > > > > preedit > > > > - doesn't allow for sending of keyboard events to the compositor > > > > - doesn't define any surfaces except for a special > > > > compositor-positioned popup > > > > > > > > Hi, > > > > continuing the RFC, I think this protocol is actually workable now, and > > > > I'm sending this with the PATCH qualifier. > > > > The practical verification came in the form of a partial wlroots > > > > implementation [0]. The formal issues (chiefly stemming from > > > > copy-pasting things at night) have been pointed out to me by Simon, and > > > > corrected. > > > > The major unverified parts are keyboard grabs and popup surfaces, which > > > > I will verify next. > > > > Changes compared to the RFC: > > > > > > > > - fixed so many confusing typos > > > > - renamed preedit_text request to set_preedit_text > > > > - described what happens when things get destroyed > > > > - defined the role of input_popup sorface and forbade it from being > > > > deleted > > > > - copied wl_keyboard to serve as the keyboard grab interface > > > > > > > > I hope you can help me find the remaining issues and turn this > > > > interface into reality! > > > > Cheers, > > > > Dorota Czaplejewicz > > > > Makefile.am | 1 + > > > > unstable/input-method/input-method-unstable-v2.xml | 490 > > > > + > > > > 2 files changed, 491 insertions(+) > > > > create mode
Re: XDG_RUNTIME_DIR on a system with no "logins"
On Thursday 2019-12-19 11:13, Guillermo Rodriguez Garcia wrote: >> >> If you used systemd, Weston has integration for that, both startup >> notification to ensure dependent services are started only after >> Weston is ready and socket activation should you choose to want >> that. > >Uhm. I am not sure I can switch to systemd at this point. >How does this (Weston being ready / not ready) look like from the client side? sd_notify works by sending a AF_LOCAL datagram to a predefined or custom socket, you just need a suitable listener. Thinking socat here (which would not execute anything, just print it). ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: XDG_RUNTIME_DIR on a system with no "logins"
On 19/12/2019 10:28, Guillermo Rodriguez wrote: > Uhm. I am not sure I can switch to systemd at this point. > How does this (Weston being ready / not ready) look like from the client side? > > i.e. if I want to make sure the client is launched once Weston is ready, > 1. Is there any way to manually check whether Weston is ready? (e.g. > some sentinel file being created or similar) > or failing that, > 2. Is there any recognizable error code if the client tries to launch > before Weston is ready (so that I can wait a bit and retry) I can't answer specifically for Weston, but I imagine this would be the same for any Wayland compositor. With our IoT solutions we wait for the $XDG_RUNTIME_DIR/$WAYLAND_DISPLAY file (or $XDG_RUNTIME_DIR/wayland-0) file before trying to connect. The server ought to be ready once that has been created. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
XDG_RUNTIME_DIR on a system with no "logins"
El jue., 19 dic. 2019 a las 9:15, Pekka Paalanen () escribió: > > On Wed, 18 Dec 2019 13:10:14 +0100 > Guillermo Rodriguez wrote: > > > In my application I need to run several clients, and each one is started > > from a separate SysV init script. I guess that I will need to define the > > XDG_RUNTIME_DIR env var to point to this "made up" location in each > > script. A bit ugly... > > Hi, > > yes I guess, and SysV init scripts have other downsides: if you > use them to launch both Weston and the clients, you may have hard > time making sure the clients are launched only after Weston is > ready to accept them. Unfortunately Weston's own auto-launch > feature has not materialized yet, although it has been discussed and > should likely use the XDG desktop files for it. Even then, it > would be a one-shot thing, not restarting the clients if they quit. > > If you used systemd, Weston has integration for that, both startup > notification to ensure dependent services are started only after > Weston is ready and socket activation should you choose to want > that. Uhm. I am not sure I can switch to systemd at this point. How does this (Weston being ready / not ready) look like from the client side? i.e. if I want to make sure the client is launched once Weston is ready, 1. Is there any way to manually check whether Weston is ready? (e.g. some sentinel file being created or similar) or failing that, 2. Is there any recognizable error code if the client tries to launch before Weston is ready (so that I can wait a bit and retry) Thanks, Guillermo Rodriguez Garcia guille.rodrig...@gmail.com ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: XDG_RUNTIME_DIR on a system with no "logins"
On Wed, 18 Dec 2019 13:10:14 +0100 Guillermo Rodriguez wrote: > In my application I need to run several clients, and each one is started > from a separate SysV init script. I guess that I will need to define the > XDG_RUNTIME_DIR env var to point to this "made up" location in each > script. A bit ugly... Hi, yes I guess, and SysV init scripts have other downsides: if you use them to launch both Weston and the clients, you may have hard time making sure the clients are launched only after Weston is ready to accept them. Unfortunately Weston's own auto-launch feature has not materialized yet, although it has been discussed and should likely use the XDG desktop files for it. Even then, it would be a one-shot thing, not restarting the clients if they quit. If you used systemd, Weston has integration for that, both startup notification to ensure dependent services are started only after Weston is ready and socket activation should you choose to want that. Thanks, pq pgpHY2C7HUxc9.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
