Re: Release schedule
On 2018-06-14 02:08 AM, Pekka Paalanen wrote: > On Wed, 13 Jun 2018 21:05:03 -0400 > ferreiradaselva wrote: > >> Any chance of the XDG decoration protocol being part of this release plan? > > Hi, > > wayland-protocols is not part of this release plan. It is much more > free to release at arbitrary times and usually does not go through a > freeze period either. Right, exactly that - I don't see a weston/wayland release having any impact on XDG decoration protocol in any way. > Unless you mean a Weston implementation of that? Weston isn't always the first to implement new protocol anymore (xdg shell stable, for example), so weston being released without an implementation of XDG decoration won't grief any other compositor wishing to do so. At this point I've seen no other concerns about the proposed schedule on or off list, so let's go with: Alpha - July 10th Beta - July 24th RC1 - August 7th First possible release August 14th. This will be a combined weston + wayland release, but following this one I think it's time to start releasing them independently. That's a discussion we can have in late August. Thanks, Derek > > Thanks, > pq > > > > ___ > 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] .gitlab-ci.yml: collect the distcheck error logs
From: Emil Velikov Currently we issue both check and distcheck, as reportedly there has been cases in the past one works, while the other doesn't. Yet we only collect the check artefacts (test logs). Correct that, by picking the distcheck ones as well. Note: the build-*/wayland*/ directory is purged by distcheck if it runs successfully. Signed-off-by: Emil Velikov --- .gitlab-ci.yml | 1 + 1 file changed, 1 insertion(+) diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml index bc1a005..2489665 100644 --- a/.gitlab-ci.yml +++ b/.gitlab-ci.yml @@ -31,5 +31,6 @@ build-native: when: always paths: - build-*/wayland-*.tar.xz +- build-*/wayland*/_build/sub/*.log - build-*/*.log - prefix-* -- 2.16.0 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH wayland 8/8] fixup! scanner: initialize .{method, event}_count via ARRAY_SIZE
---
tests/data/example-code.c | 73 +
tests/data/small-code-core.c| 5 +--
tests/data/small-code.c | 5 +--
tests/data/small-private-code.c | 5 +--
4 files changed, 46 insertions(+), 42 deletions(-)
diff --git a/tests/data/example-code.c b/tests/data/example-code.c
index 2e1f73b..65d9651 100644
--- a/tests/data/example-code.c
+++ b/tests/data/example-code.c
@@ -146,6 +146,7 @@ static const struct wl_interface *types[] = {
[94] = _surface_interface,
};
+#define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0]))
static const struct wl_message wl_display_requests[] = {
{ .name = "sync", .signature = "n", .types = [8] },
{ .name = "get_registry", .signature = "n", .types = [9] },
@@ -158,8 +159,8 @@ static const struct wl_message wl_display_events[] = {
WL_EXPORT const struct wl_interface wl_display_interface = {
.name = "wl_display", .version = 1,
- .method_count = 2, .methods = wl_display_requests,
- .event_count = 2, .events = wl_display_events,
+ .method_count = ARRAY_SIZE(wl_display_requests), .methods =
wl_display_requests,
+ .event_count = ARRAY_SIZE(wl_display_events), .events =
wl_display_events,
};
static const struct wl_message wl_registry_requests[] = {
@@ -173,8 +174,8 @@ static const struct wl_message wl_registry_events[] = {
WL_EXPORT const struct wl_interface wl_registry_interface = {
.name = "wl_registry", .version = 1,
- .method_count = 1, .methods = wl_registry_requests,
- .event_count = 2, .events = wl_registry_events,
+ .method_count = ARRAY_SIZE(wl_registry_requests), .methods =
wl_registry_requests,
+ .event_count = ARRAY_SIZE(wl_registry_events), .events =
wl_registry_events,
};
static const struct wl_message wl_callback_events[] = {
@@ -183,7 +184,7 @@ static const struct wl_message wl_callback_events[] = {
WL_EXPORT const struct wl_interface wl_callback_interface = {
.name = "wl_callback", .version = 1,
- .event_count = 1, .events = wl_callback_events,
+ .event_count = ARRAY_SIZE(wl_callback_events), .events =
wl_callback_events,
};
static const struct wl_message wl_compositor_requests[] = {
@@ -193,7 +194,7 @@ static const struct wl_message wl_compositor_requests[] = {
WL_EXPORT const struct wl_interface wl_compositor_interface = {
.name = "wl_compositor", .version = 4,
- .method_count = 2, .methods = wl_compositor_requests,
+ .method_count = ARRAY_SIZE(wl_compositor_requests), .methods =
wl_compositor_requests,
};
static const struct wl_message wl_shm_pool_requests[] = {
@@ -204,7 +205,7 @@ static const struct wl_message wl_shm_pool_requests[] = {
WL_EXPORT const struct wl_interface wl_shm_pool_interface = {
.name = "wl_shm_pool", .version = 1,
- .method_count = 3, .methods = wl_shm_pool_requests,
+ .method_count = ARRAY_SIZE(wl_shm_pool_requests), .methods =
wl_shm_pool_requests,
};
static const struct wl_message wl_shm_requests[] = {
@@ -217,8 +218,8 @@ static const struct wl_message wl_shm_events[] = {
WL_EXPORT const struct wl_interface wl_shm_interface = {
.name = "wl_shm", .version = 1,
- .method_count = 1, .methods = wl_shm_requests,
- .event_count = 1, .events = wl_shm_events,
+ .method_count = ARRAY_SIZE(wl_shm_requests), .methods = wl_shm_requests,
+ .event_count = ARRAY_SIZE(wl_shm_events), .events = wl_shm_events,
};
static const struct wl_message wl_buffer_requests[] = {
@@ -231,8 +232,8 @@ static const struct wl_message wl_buffer_events[] = {
WL_EXPORT const struct wl_interface wl_buffer_interface = {
.name = "wl_buffer", .version = 1,
- .method_count = 1, .methods = wl_buffer_requests,
- .event_count = 1, .events = wl_buffer_events,
+ .method_count = ARRAY_SIZE(wl_buffer_requests), .methods =
wl_buffer_requests,
+ .event_count = ARRAY_SIZE(wl_buffer_events), .events = wl_buffer_events,
};
static const struct wl_message wl_data_offer_requests[] = {
@@ -251,8 +252,8 @@ static const struct wl_message wl_data_offer_events[] = {
WL_EXPORT const struct wl_interface wl_data_offer_interface = {
.name = "wl_data_offer", .version = 3,
- .method_count = 5, .methods = wl_data_offer_requests,
- .event_count = 3, .events = wl_data_offer_events,
+ .method_count = ARRAY_SIZE(wl_data_offer_requests), .methods =
wl_data_offer_requests,
+ .event_count = ARRAY_SIZE(wl_data_offer_events), .events =
wl_data_offer_events,
};
static const struct wl_message wl_data_source_requests[] = {
@@ -272,8 +273,8 @@ static const struct wl_message wl_data_source_events[] = {
WL_EXPORT const struct wl_interface wl_data_source_interface = {
.name = "wl_data_source", .version = 3,
- .method_count = 3, .methods = wl_data_source_requests,
- .event_count = 6, .events = wl_data_source_events,
+ .method_count =
[PATCH wayland 6/8] fixup! scanner: use c99 initializers for the interface symbols
---
tests/data/example-code.c | 124 +++-
tests/data/small-code-core.c| 6 +-
tests/data/small-code.c | 6 +-
tests/data/small-private-code.c | 6 +-
4 files changed, 67 insertions(+), 75 deletions(-)
diff --git a/tests/data/example-code.c b/tests/data/example-code.c
index 4a41b8b..2e1f73b 100644
--- a/tests/data/example-code.c
+++ b/tests/data/example-code.c
@@ -157,9 +157,9 @@ static const struct wl_message wl_display_events[] = {
};
WL_EXPORT const struct wl_interface wl_display_interface = {
- "wl_display", 1,
- 2, wl_display_requests,
- 2, wl_display_events,
+ .name = "wl_display", .version = 1,
+ .method_count = 2, .methods = wl_display_requests,
+ .event_count = 2, .events = wl_display_events,
};
static const struct wl_message wl_registry_requests[] = {
@@ -172,9 +172,9 @@ static const struct wl_message wl_registry_events[] = {
};
WL_EXPORT const struct wl_interface wl_registry_interface = {
- "wl_registry", 1,
- 1, wl_registry_requests,
- 2, wl_registry_events,
+ .name = "wl_registry", .version = 1,
+ .method_count = 1, .methods = wl_registry_requests,
+ .event_count = 2, .events = wl_registry_events,
};
static const struct wl_message wl_callback_events[] = {
@@ -182,9 +182,8 @@ static const struct wl_message wl_callback_events[] = {
};
WL_EXPORT const struct wl_interface wl_callback_interface = {
- "wl_callback", 1,
- 0, NULL,
- 1, wl_callback_events,
+ .name = "wl_callback", .version = 1,
+ .event_count = 1, .events = wl_callback_events,
};
static const struct wl_message wl_compositor_requests[] = {
@@ -193,9 +192,8 @@ static const struct wl_message wl_compositor_requests[] = {
};
WL_EXPORT const struct wl_interface wl_compositor_interface = {
- "wl_compositor", 4,
- 2, wl_compositor_requests,
- 0, NULL,
+ .name = "wl_compositor", .version = 4,
+ .method_count = 2, .methods = wl_compositor_requests,
};
static const struct wl_message wl_shm_pool_requests[] = {
@@ -205,9 +203,8 @@ static const struct wl_message wl_shm_pool_requests[] = {
};
WL_EXPORT const struct wl_interface wl_shm_pool_interface = {
- "wl_shm_pool", 1,
- 3, wl_shm_pool_requests,
- 0, NULL,
+ .name = "wl_shm_pool", .version = 1,
+ .method_count = 3, .methods = wl_shm_pool_requests,
};
static const struct wl_message wl_shm_requests[] = {
@@ -219,9 +216,9 @@ static const struct wl_message wl_shm_events[] = {
};
WL_EXPORT const struct wl_interface wl_shm_interface = {
- "wl_shm", 1,
- 1, wl_shm_requests,
- 1, wl_shm_events,
+ .name = "wl_shm", .version = 1,
+ .method_count = 1, .methods = wl_shm_requests,
+ .event_count = 1, .events = wl_shm_events,
};
static const struct wl_message wl_buffer_requests[] = {
@@ -233,9 +230,9 @@ static const struct wl_message wl_buffer_events[] = {
};
WL_EXPORT const struct wl_interface wl_buffer_interface = {
- "wl_buffer", 1,
- 1, wl_buffer_requests,
- 1, wl_buffer_events,
+ .name = "wl_buffer", .version = 1,
+ .method_count = 1, .methods = wl_buffer_requests,
+ .event_count = 1, .events = wl_buffer_events,
};
static const struct wl_message wl_data_offer_requests[] = {
@@ -253,9 +250,9 @@ static const struct wl_message wl_data_offer_events[] = {
};
WL_EXPORT const struct wl_interface wl_data_offer_interface = {
- "wl_data_offer", 3,
- 5, wl_data_offer_requests,
- 3, wl_data_offer_events,
+ .name = "wl_data_offer", .version = 3,
+ .method_count = 5, .methods = wl_data_offer_requests,
+ .event_count = 3, .events = wl_data_offer_events,
};
static const struct wl_message wl_data_source_requests[] = {
@@ -274,9 +271,9 @@ static const struct wl_message wl_data_source_events[] = {
};
WL_EXPORT const struct wl_interface wl_data_source_interface = {
- "wl_data_source", 3,
- 3, wl_data_source_requests,
- 6, wl_data_source_events,
+ .name = "wl_data_source", .version = 3,
+ .method_count = 3, .methods = wl_data_source_requests,
+ .event_count = 6, .events = wl_data_source_events,
};
static const struct wl_message wl_data_device_requests[] = {
@@ -295,9 +292,9 @@ static const struct wl_message wl_data_device_events[] = {
};
WL_EXPORT const struct wl_interface wl_data_device_interface = {
- "wl_data_device", 3,
- 3, wl_data_device_requests,
- 6, wl_data_device_events,
+ .name = "wl_data_device", .version = 3,
+ .method_count = 3, .methods = wl_data_device_requests,
+ .event_count = 6, .events = wl_data_device_events,
};
static const struct wl_message wl_data_device_manager_requests[] = {
@@ -306,9 +303,8 @@ static const struct wl_message
wl_data_device_manager_requests[] = {
};
WL_EXPORT const struct wl_interface
[PATCH wayland 7/8] scanner: initialize .{method, event}_count via ARRAY_SIZE
From: Emil Velikov
Demystify the final magic value within the generated files.
Signed-off-by: Emil Velikov
---
src/scanner.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/src/scanner.c b/src/scanner.c
index 22b1daa..8f469e9 100644
--- a/src/scanner.c
+++ b/src/scanner.c
@@ -1779,6 +1779,7 @@ emit_code(struct protocol *protocol, enum visibility vis)
}
printf("};\n\n");
+ printf("#define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0]))\n");
wl_list_for_each_safe(i, next, >interface_list, link) {
emit_messages(>request_list, i, "requests");
@@ -1790,12 +1791,12 @@ emit_code(struct protocol *protocol, enum visibility
vis)
symbol_visibility, i->name, i->name, i->version);
if (!wl_list_empty(>request_list))
- printf("\t.method_count = %d, .methods =
%s_requests,\n",
- wl_list_length(>request_list), i->name);
+ printf("\t.method_count = ARRAY_SIZE(%s_requests),
.methods = %s_requests,\n",
+ i->name, i->name);
if (!wl_list_empty(>event_list))
- printf("\t.event_count = %d, .events = %s_events,\n",
- wl_list_length(>event_list), i->name);
+ printf("\t.event_count = ARRAY_SIZE(%s_events), .events
= %s_events,\n",
+ i->name, i->name);
printf("};\n\n");
--
2.16.0
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH wayland 4/8] fixup! scanner: use c99 initializers for the request/events arrays
---
tests/data/example-code.c | 238
tests/data/small-code-core.c| 8 +-
tests/data/small-code.c | 8 +-
tests/data/small-private-code.c | 8 +-
4 files changed, 131 insertions(+), 131 deletions(-)
diff --git a/tests/data/example-code.c b/tests/data/example-code.c
index ccfa9ef..4a41b8b 100644
--- a/tests/data/example-code.c
+++ b/tests/data/example-code.c
@@ -147,13 +147,13 @@ static const struct wl_interface *types[] = {
};
static const struct wl_message wl_display_requests[] = {
- { "sync", "n", types + 8 },
- { "get_registry", "n", types + 9 },
+ { .name = "sync", .signature = "n", .types = [8] },
+ { .name = "get_registry", .signature = "n", .types = [9] },
};
static const struct wl_message wl_display_events[] = {
- { "error", "ous", types + 0 },
- { "delete_id", "u", types + 0 },
+ { .name = "error", .signature = "ous", .types = [0] },
+ { .name = "delete_id", .signature = "u", .types = [0] },
};
WL_EXPORT const struct wl_interface wl_display_interface = {
@@ -163,12 +163,12 @@ WL_EXPORT const struct wl_interface wl_display_interface
= {
};
static const struct wl_message wl_registry_requests[] = {
- { "bind", "usun", types + 0 },
+ { .name = "bind", .signature = "usun", .types = [0] },
};
static const struct wl_message wl_registry_events[] = {
- { "global", "usu", types + 0 },
- { "global_remove", "u", types + 0 },
+ { .name = "global", .signature = "usu", .types = [0] },
+ { .name = "global_remove", .signature = "u", .types = [0] },
};
WL_EXPORT const struct wl_interface wl_registry_interface = {
@@ -178,7 +178,7 @@ WL_EXPORT const struct wl_interface wl_registry_interface =
{
};
static const struct wl_message wl_callback_events[] = {
- { "done", "u", types + 0 },
+ { .name = "done", .signature = "u", .types = [0] },
};
WL_EXPORT const struct wl_interface wl_callback_interface = {
@@ -188,8 +188,8 @@ WL_EXPORT const struct wl_interface wl_callback_interface =
{
};
static const struct wl_message wl_compositor_requests[] = {
- { "create_surface", "n", types + 10 },
- { "create_region", "n", types + 11 },
+ { .name = "create_surface", .signature = "n", .types = [10] },
+ { .name = "create_region", .signature = "n", .types = [11] },
};
WL_EXPORT const struct wl_interface wl_compositor_interface = {
@@ -199,9 +199,9 @@ WL_EXPORT const struct wl_interface wl_compositor_interface
= {
};
static const struct wl_message wl_shm_pool_requests[] = {
- { "create_buffer", "nu", types + 12 },
- { "destroy", "", types + 0 },
- { "resize", "i", types + 0 },
+ { .name = "create_buffer", .signature = "nu", .types = [12] },
+ { .name = "destroy", .signature = "", .types = [0] },
+ { .name = "resize", .signature = "i", .types = [0] },
};
WL_EXPORT const struct wl_interface wl_shm_pool_interface = {
@@ -211,11 +211,11 @@ WL_EXPORT const struct wl_interface wl_shm_pool_interface
= {
};
static const struct wl_message wl_shm_requests[] = {
- { "create_pool", "nhi", types + 18 },
+ { .name = "create_pool", .signature = "nhi", .types = [18] },
};
static const struct wl_message wl_shm_events[] = {
- { "format", "u", types + 0 },
+ { .name = "format", .signature = "u", .types = [0] },
};
WL_EXPORT const struct wl_interface wl_shm_interface = {
@@ -225,11 +225,11 @@ WL_EXPORT const struct wl_interface wl_shm_interface = {
};
static const struct wl_message wl_buffer_requests[] = {
- { "destroy", "", types + 0 },
+ { .name = "destroy", .signature = "", .types = [0] },
};
static const struct wl_message wl_buffer_events[] = {
- { "release", "", types + 0 },
+ { .name = "release", .signature = "", .types = [0] },
};
WL_EXPORT const struct wl_interface wl_buffer_interface = {
@@ -239,17 +239,17 @@ WL_EXPORT const struct wl_interface wl_buffer_interface =
{
};
static const struct wl_message wl_data_offer_requests[] = {
- { "accept", "u?s", types + 0 },
- { "receive", "sh", types + 0 },
- { "destroy", "", types + 0 },
- { "finish", "3", types + 0 },
- { "set_actions", "3uu", types + 0 },
+ { .name = "accept", .signature = "u?s", .types = [0] },
+ { .name = "receive", .signature = "sh", .types = [0] },
+ { .name = "destroy", .signature = "", .types = [0] },
+ { .name = "finish", .signature = "3", .types = [0] },
+ { .name = "set_actions", .signature = "3uu", .types = [0] },
};
static const struct wl_message wl_data_offer_events[] = {
- { "offer", "s", types + 0 },
- { "source_actions", "3u", types + 0 },
- { "action", "3u", types + 0 },
+ { .name = "offer", .signature = "s", .types = [0] },
+ { .name = "source_actions", .signature = "3u", .types = [0] },
+ { .name = "action",
[PATCH wayland 5/8] scanner: use c99 initializers for the interface symbols
From: Emil Velikov
Provides some clarity and removes the unnecessary zero/NULL
initialization.
Signed-off-by: Emil Velikov
---
src/scanner.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/src/scanner.c b/src/scanner.c
index fb3c808..22b1daa 100644
--- a/src/scanner.c
+++ b/src/scanner.c
@@ -1786,20 +1786,16 @@ emit_code(struct protocol *protocol, enum visibility
vis)
printf("%s const struct wl_interface "
"%s_interface = {\n"
- "\t\"%s\", %d,\n",
+ "\t.name = \"%s\", .version = %d,\n",
symbol_visibility, i->name, i->name, i->version);
if (!wl_list_empty(>request_list))
- printf("\t%d, %s_requests,\n",
+ printf("\t.method_count = %d, .methods =
%s_requests,\n",
wl_list_length(>request_list), i->name);
- else
- printf("\t0, NULL,\n");
if (!wl_list_empty(>event_list))
- printf("\t%d, %s_events,\n",
+ printf("\t.event_count = %d, .events = %s_events,\n",
wl_list_length(>event_list), i->name);
- else
- printf("\t0, NULL,\n");
printf("};\n\n");
--
2.16.0
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCHv2 wayland 0/8] wayland-scanner: produce code with c99 initializers
Hi all,
Here's a take v2 of the series, with the following changes:
- don't trim trailing NULL entries from the wl_interfaces* array
- updated tests - separate patches to ease review, to be squashed
On the question of why, despite the aesthetics these patches make the
generated files actually understandable by a human being...
Thanks
Emil
Emil Velikov (8):
scanner: use c99 initializers for the wl_interface * array
fixup! scanner: use c99 initializers for the wl_interface * array
scanner: use c99 initializers for the request/events arrays
fixup! scanner: use c99 initializers for the request/events arrays
scanner: use c99 initializers for the interface symbols
fixup! scanner: use c99 initializers for the interface symbols
scanner: initialize .{method,event}_count via ARRAY_SIZE
fixup! scanner: initialize .{method,event}_count via ARRAY_SIZE
src/scanner.c | 32 +--
tests/data/example-code.c | 557
tests/data/small-code-core.c| 31 +--
tests/data/small-code.c | 31 +--
tests/data/small-private-code.c | 31 +--
5 files changed, 339 insertions(+), 343 deletions(-)
--
2.16.0
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH wayland 3/8] scanner: use c99 initializers for the request/events arrays
From: Emil Velikov
Makes things a bit less magical, should you be looking in the file.
Signed-off-by: Emil Velikov
---
src/scanner.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/scanner.c b/src/scanner.c
index 4b49593..fb3c808 100644
--- a/src/scanner.c
+++ b/src/scanner.c
@@ -1675,7 +1675,7 @@ emit_messages(struct wl_list *message_list,
interface->name, suffix);
wl_list_for_each(m, message_list, link) {
- printf("\t{ \"%s\", \"", m->name);
+ printf("\t{ .name = \"%s\", .signature = \"", m->name);
if (m->since > 1)
printf("%d", m->since);
@@ -1714,7 +1714,7 @@ emit_messages(struct wl_list *message_list,
break;
}
}
- printf("\", types + %d },\n", m->type_index);
+ printf("\", .types = [%d] },\n", m->type_index);
}
printf("};\n\n");
--
2.16.0
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH wayland 2/8] fixup! scanner: use c99 initializers for the wl_interface * array
---
tests/data/example-code.c | 190
tests/data/small-code-core.c| 16 ++--
tests/data/small-code.c | 16 ++--
tests/data/small-private-code.c | 16 ++--
4 files changed, 119 insertions(+), 119 deletions(-)
diff --git a/tests/data/example-code.c b/tests/data/example-code.c
index bc03fe5..ccfa9ef 100644
--- a/tests/data/example-code.c
+++ b/tests/data/example-code.c
@@ -49,101 +49,101 @@ extern const struct wl_interface wl_surface_interface;
extern const struct wl_interface wl_touch_interface;
static const struct wl_interface *types[] = {
- NULL,
- NULL,
- NULL,
- NULL,
- NULL,
- NULL,
- NULL,
- NULL,
- _callback_interface,
- _registry_interface,
- _surface_interface,
- _region_interface,
- _buffer_interface,
- NULL,
- NULL,
- NULL,
- NULL,
- NULL,
- _shm_pool_interface,
- NULL,
- NULL,
- _data_source_interface,
- _surface_interface,
- _surface_interface,
- NULL,
- _data_source_interface,
- NULL,
- _data_offer_interface,
- NULL,
- _surface_interface,
- NULL,
- NULL,
- _data_offer_interface,
- _data_offer_interface,
- _data_source_interface,
- _data_device_interface,
- _seat_interface,
- _shell_surface_interface,
- _surface_interface,
- _seat_interface,
- NULL,
- _seat_interface,
- NULL,
- NULL,
- _surface_interface,
- NULL,
- NULL,
- NULL,
- NULL,
- NULL,
- _output_interface,
- _seat_interface,
- NULL,
- _surface_interface,
- NULL,
- NULL,
- NULL,
- _output_interface,
- _buffer_interface,
- NULL,
- NULL,
- _callback_interface,
- _region_interface,
- _region_interface,
- _output_interface,
- _output_interface,
- _pointer_interface,
- _keyboard_interface,
- _touch_interface,
- NULL,
- _surface_interface,
- NULL,
- NULL,
- NULL,
- _surface_interface,
- NULL,
- NULL,
- NULL,
- _surface_interface,
- NULL,
- _surface_interface,
- NULL,
- NULL,
- _surface_interface,
- NULL,
- NULL,
- _surface_interface,
- NULL,
- NULL,
- NULL,
- _subsurface_interface,
- _surface_interface,
- _surface_interface,
- _surface_interface,
- _surface_interface,
+ [0] = NULL,
+ [1] = NULL,
+ [2] = NULL,
+ [3] = NULL,
+ [4] = NULL,
+ [5] = NULL,
+ [6] = NULL,
+ [7] = NULL,
+ [8] = _callback_interface,
+ [9] = _registry_interface,
+ [10] = _surface_interface,
+ [11] = _region_interface,
+ [12] = _buffer_interface,
+ [13] = NULL,
+ [14] = NULL,
+ [15] = NULL,
+ [16] = NULL,
+ [17] = NULL,
+ [18] = _shm_pool_interface,
+ [19] = NULL,
+ [20] = NULL,
+ [21] = _data_source_interface,
+ [22] = _surface_interface,
+ [23] = _surface_interface,
+ [24] = NULL,
+ [25] = _data_source_interface,
+ [26] = NULL,
+ [27] = _data_offer_interface,
+ [28] = NULL,
+ [29] = _surface_interface,
+ [30] = NULL,
+ [31] = NULL,
+ [32] = _data_offer_interface,
+ [33] = _data_offer_interface,
+ [34] = _data_source_interface,
+ [35] = _data_device_interface,
+ [36] = _seat_interface,
+ [37] = _shell_surface_interface,
+ [38] = _surface_interface,
+ [39] = _seat_interface,
+ [40] = NULL,
+ [41] = _seat_interface,
+ [42] = NULL,
+ [43] = NULL,
+ [44] = _surface_interface,
+ [45] = NULL,
+ [46] = NULL,
+ [47] = NULL,
+ [48] = NULL,
+ [49] = NULL,
+ [50] = _output_interface,
+ [51] = _seat_interface,
+ [52] = NULL,
+ [53] = _surface_interface,
+ [54] = NULL,
+ [55] = NULL,
+ [56] = NULL,
+ [57] = _output_interface,
+ [58] = _buffer_interface,
+ [59] = NULL,
+ [60] = NULL,
+ [61] = _callback_interface,
+ [62] = _region_interface,
+ [63] = _region_interface,
+ [64] = _output_interface,
+ [65] = _output_interface,
+ [66] = _pointer_interface,
+ [67] = _keyboard_interface,
+ [68] = _touch_interface,
+ [69] = NULL,
+ [70] = _surface_interface,
+ [71] = NULL,
+ [72] = NULL,
+ [73] = NULL,
+ [74] = _surface_interface,
+ [75] = NULL,
+ [76] = NULL,
+ [77] = NULL,
+ [78] = _surface_interface,
+ [79] = NULL,
+ [80] = _surface_interface,
+ [81] = NULL,
+ [82] = NULL,
+ [83] = _surface_interface,
+ [84] = NULL,
+ [85] = NULL,
+ [86] =
[PATCH wayland 1/8] scanner: use c99 initializers for the wl_interface * array
From: Emil Velikov
Makes it a bit more obvious, should you be reading through the generated
code.
We might even drop the NULL entries (at a later stage) making things
shorter and easier to read.
v2: don't alter the array size by discarding trailing NULL entries
Signed-off-by: Emil Velikov
---
src/scanner.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/src/scanner.c b/src/scanner.c
index 205c28a..4b49593 100644
--- a/src/scanner.c
+++ b/src/scanner.c
@@ -1620,7 +1620,7 @@ emit_null_run(struct protocol *protocol)
int i;
for (i = 0; i < protocol->null_run_length; i++)
- printf("\tNULL,\n");
+ printf("\t[%d] = NULL,\n", i);
}
static void
@@ -1628,6 +1628,7 @@ emit_types(struct protocol *protocol, struct wl_list
*message_list)
{
struct message *m;
struct arg *a;
+ int index;
wl_list_for_each(m, message_list, link) {
if (m->all_null) {
@@ -1638,21 +1639,23 @@ emit_types(struct protocol *protocol, struct wl_list
*message_list)
m->type_index =
protocol->null_run_length + protocol->type_index;
protocol->type_index += m->arg_count;
+ index = m->type_index;
wl_list_for_each(a, >arg_list, link) {
switch (a->type) {
case NEW_ID:
case OBJECT:
if (a->interface_name)
- printf("\t&%s_interface,\n",
- a->interface_name);
+ printf("\t[%d] = &%s_interface,\n",
+ index, a->interface_name);
else
- printf("\tNULL,\n");
+ printf("\t[%d] = NULL,\n", index);
break;
default:
- printf("\tNULL,\n");
+ printf("\t[%d] = NULL,\n", index);
break;
}
+ index++;
}
}
}
--
2.16.0
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
RE: Issue with initial window position
Hi, Thank you all.Will try this and get back to you asap. Thanks, Prasanth From: Ucan, Emre (ADITG/ESB) [eu...@de.adit-jv.com] Sent: 14 June 2018 17:52 To: PrasanthKumar P.A. Cc: wayland-devel@lists.freedesktop.org; Pekka Paalanen Subject: RE: Issue with initial window position Hi, You can use IVI Shell with wayland-ivi-extension to realize your use-case. Please check this: https://at.projects.genivi.org/wiki/display/PROJ/Wayland+IVI+Extension+Design Best regards Emre Ucan Engineering Software Base (ADITG/ESB) Tel. +49 5121 49 6937 > -Original Message- > From: wayland-devel [mailto:wayland-devel- > boun...@lists.freedesktop.org] On Behalf Of PrasanthKumar P.A. > Sent: Donnerstag, 14. Juni 2018 14:09 > To: Pekka Paalanen > Cc: wayland-devel@lists.freedesktop.org > Subject: RE: Issue with initial window position > > Hi, > Thank you for your quick response. > These are our concerns. > Our application is a HMI that is to be deployed on IMX8 board. > By design we need to place some QT Qml windows on specified x y > coordinates on the screen .How can we achieve this ? > > Also I am interested on (If your target environment is not a desktop, then > the design could be > different). Can you please comment on this. > > Thanks, > Prasanth > > From: Pekka Paalanen [ppaala...@gmail.com] > Sent: 14 June 2018 16:45 > To: PrasanthKumar P.A. > Cc: wayland-devel@lists.freedesktop.org > Subject: Re: Issue with initial window position > > On Thu, 14 Jun 2018 10:39:57 + > PrasanthKumar P.A. wrote: > > > Dear All, > > > > I have a Qt Qml application which contains several windows (Qml > > windows). I have set the initial positions x,y for these windows but > > none of these windows are coming in the corresponding coordinates . > > Hi, > > this is expected. Wayland on desktops has no official way to position > windows from the client by global or per-output x,y coordinates. This > is by design for desktops. On the desktop, the window manager is the > only one that knows enough to be able to position windows correctly. > > Weston decides the initial window position by random. Other compositors > use other algorithms. > > If your target environment is not a desktop, then the design could be > different. > > Why do you want your client to position the window specifically by > coordinates? > > How is it possible that your client can even pick sensible coordinates? > > Why do you want your app to pick the initial position instead of the > window manager? > > > Thanks, > pq > > > Confidentiality Statement / Disclaimer : This message and any attachments is > intended for the sole use of the intended recipient. It may contain > confidential information. Any unauthorized use, dissemination or > modification is strictly prohibited. If you are not the intended recipient, > please notify the sender immediately then delete it from all your systems, > and do not copy, use or print. Internet communications are not secure and it > is the responsibility of the recipient to make sure that it is virus/malicious > code exempt. > > The company/sender cannot be responsible for any unauthorized alterations > or modifications made to the contents. If you require any form of > confirmation of the contents, please contact the company/sender. The > company/sender is not liable for any errors or omissions in the content of > this message. > > > ___ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/wayland-devel Confidentiality Statement / Disclaimer : This message and any attachments is intended for the sole use of the intended recipient. It may contain confidential information. Any unauthorized use, dissemination or modification is strictly prohibited. If you are not the intended recipient, please notify the sender immediately then delete it from all your systems, and do not copy, use or print. Internet communications are not secure and it is the responsibility of the recipient to make sure that it is virus/malicious code exempt. The company/sender cannot be responsible for any unauthorized alterations or modifications made to the contents. If you require any form of confirmation of the contents, please contact the company/sender. The company/sender is not liable for any errors or omissions in the content of this message. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Issue with initial window position
On Thu, 14 Jun 2018 12:09:03 + PrasanthKumar P.A. wrote: > Hi, > Thank you for your quick response. > These are our concerns. > Our application is a HMI that is to be deployed on IMX8 board. > By design we need to place some QT Qml windows on specified x y > coordinates on the screen .How can we achieve this ? Usually you run a compositor that knows to place your special windows correctly, perhaps with some aid from a custom protocol extension that tells the compositor what kind of window it is. If a client knows at what coordinates its window should go, then the compositor would know that as well if it just knows the detailed type of each window. The compositor always knows at least as much as any client, because on Wayland clients are by default isolated from each other: no client knows what else is on the screen. Only an entity that knows what else is on screen will be able to position windows correctly. The compositor necessarily is one such an entity. Desktop systems have no closed design and there one cannot know beforehand what else might be on the screen, and for containment and privacy reasons there is no protocol for an arbitrary client to even find out. If the compositor is placing windows freely in a VR environment, then a client trying to position its window by x,y coordinates is meaningless. The design principle is to give the window manager enough semantical information to manage windows correctly, instead of letting clients fight with the window manager. > Also I am interested on (If your target environment is not a desktop, > then the design could be different). Can you please comment on this. The family of IVI protocol extensions for Wayland is an example of a non-desktop design. Systems with essentially closed design the components on screen can be defined before-hand, and therefore the system designer can choose their positions. How those positions are then realized becomes an implementation detail which is often solved by some protocols, (custom) Wayland extensions or otherwise. Thanks, pq pgpvMntimiDha.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
RE: Issue with initial window position
Hi, You can use IVI Shell with wayland-ivi-extension to realize your use-case. Please check this: https://at.projects.genivi.org/wiki/display/PROJ/Wayland+IVI+Extension+Design Best regards Emre Ucan Engineering Software Base (ADITG/ESB) Tel. +49 5121 49 6937 > -Original Message- > From: wayland-devel [mailto:wayland-devel- > boun...@lists.freedesktop.org] On Behalf Of PrasanthKumar P.A. > Sent: Donnerstag, 14. Juni 2018 14:09 > To: Pekka Paalanen > Cc: wayland-devel@lists.freedesktop.org > Subject: RE: Issue with initial window position > > Hi, > Thank you for your quick response. > These are our concerns. > Our application is a HMI that is to be deployed on IMX8 board. > By design we need to place some QT Qml windows on specified x y > coordinates on the screen .How can we achieve this ? > > Also I am interested on (If your target environment is not a desktop, then > the design could be > different). Can you please comment on this. > > Thanks, > Prasanth > > From: Pekka Paalanen [ppaala...@gmail.com] > Sent: 14 June 2018 16:45 > To: PrasanthKumar P.A. > Cc: wayland-devel@lists.freedesktop.org > Subject: Re: Issue with initial window position > > On Thu, 14 Jun 2018 10:39:57 + > PrasanthKumar P.A. wrote: > > > Dear All, > > > > I have a Qt Qml application which contains several windows (Qml > > windows). I have set the initial positions x,y for these windows but > > none of these windows are coming in the corresponding coordinates . > > Hi, > > this is expected. Wayland on desktops has no official way to position > windows from the client by global or per-output x,y coordinates. This > is by design for desktops. On the desktop, the window manager is the > only one that knows enough to be able to position windows correctly. > > Weston decides the initial window position by random. Other compositors > use other algorithms. > > If your target environment is not a desktop, then the design could be > different. > > Why do you want your client to position the window specifically by > coordinates? > > How is it possible that your client can even pick sensible coordinates? > > Why do you want your app to pick the initial position instead of the > window manager? > > > Thanks, > pq > > > Confidentiality Statement / Disclaimer : This message and any attachments is > intended for the sole use of the intended recipient. It may contain > confidential information. Any unauthorized use, dissemination or > modification is strictly prohibited. If you are not the intended recipient, > please notify the sender immediately then delete it from all your systems, > and do not copy, use or print. Internet communications are not secure and it > is the responsibility of the recipient to make sure that it is virus/malicious > code exempt. > > The company/sender cannot be responsible for any unauthorized alterations > or modifications made to the contents. If you require any form of > confirmation of the contents, please contact the company/sender. The > company/sender is not liable for any errors or omissions in the content of > this message. > > > ___ > 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
RE: Issue with initial window position
Hi, Thank you for your quick response. These are our concerns. Our application is a HMI that is to be deployed on IMX8 board. By design we need to place some QT Qml windows on specified x y coordinates on the screen .How can we achieve this ? Also I am interested on (If your target environment is not a desktop, then the design could be different). Can you please comment on this. Thanks, Prasanth From: Pekka Paalanen [ppaala...@gmail.com] Sent: 14 June 2018 16:45 To: PrasanthKumar P.A. Cc: wayland-devel@lists.freedesktop.org Subject: Re: Issue with initial window position On Thu, 14 Jun 2018 10:39:57 + PrasanthKumar P.A. wrote: > Dear All, > > I have a Qt Qml application which contains several windows (Qml > windows). I have set the initial positions x,y for these windows but > none of these windows are coming in the corresponding coordinates . Hi, this is expected. Wayland on desktops has no official way to position windows from the client by global or per-output x,y coordinates. This is by design for desktops. On the desktop, the window manager is the only one that knows enough to be able to position windows correctly. Weston decides the initial window position by random. Other compositors use other algorithms. If your target environment is not a desktop, then the design could be different. Why do you want your client to position the window specifically by coordinates? How is it possible that your client can even pick sensible coordinates? Why do you want your app to pick the initial position instead of the window manager? Thanks, pq Confidentiality Statement / Disclaimer : This message and any attachments is intended for the sole use of the intended recipient. It may contain confidential information. Any unauthorized use, dissemination or modification is strictly prohibited. If you are not the intended recipient, please notify the sender immediately then delete it from all your systems, and do not copy, use or print. Internet communications are not secure and it is the responsibility of the recipient to make sure that it is virus/malicious code exempt. The company/sender cannot be responsible for any unauthorized alterations or modifications made to the contents. If you require any form of confirmation of the contents, please contact the company/sender. The company/sender is not liable for any errors or omissions in the content of this message. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland 1/3] doc: move Contributing
On Thu, 14 Jun 2018 10:58:00 +0100 Daniel Stone wrote: > Hi Pekka, > > On Wed, 13 Jun 2018 at 14:33, Pekka Paalanen wrote: > > Gitlab expects a CONTRIBUTING.md in the root directory, so move our > > guide there. > > > > Conversion to proper markup is a follow-up patch. > > Thanks for these; both series are: > Reviewed-by: Daniel Stone Hi, I implemented Peter's suggestion of using 8 spaces and a note, and pushed. wayland: 7846d4b..630c25f master -> master wayland.freedesktop.org: 978d89e..f045c5c master -> master Thanks, pq pgpoaF98Mcj7n.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Issue with initial window position
On Thu, 14 Jun 2018 10:39:57 + PrasanthKumar P.A. wrote: > Dear All, > > I have a Qt Qml application which contains several windows (Qml > windows). I have set the initial positions x,y for these windows but > none of these windows are coming in the corresponding coordinates . Hi, this is expected. Wayland on desktops has no official way to position windows from the client by global or per-output x,y coordinates. This is by design for desktops. On the desktop, the window manager is the only one that knows enough to be able to position windows correctly. Weston decides the initial window position by random. Other compositors use other algorithms. If your target environment is not a desktop, then the design could be different. Why do you want your client to position the window specifically by coordinates? How is it possible that your client can even pick sensible coordinates? Why do you want your app to pick the initial position instead of the window manager? Thanks, pq pgpyi2GrWLvnU.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Wayland content-protection extension
On Wed, Jun 13, 2018 at 12:34 PM, Nautiyal, Ankit K wrote: > Hi All, > > I am working on wayland content-protection protocol extension, to enable > content-protection (HDCP1.4, HDCP2.2) in wayland. > DRM layer already has support for HDCP1.4 and patches for HDCP2.2 are in > review : https://patchwork.freedesktop.org/series/39596/ > > As per the IRC discussion on #wayland about content protection extension for > Wayland (yesterday, 12th June 2018) , please find below the agreed points: > Hi Ankit, Thanks for working on this, overall I agree with your design, which provides a first level of security when more advanced output protection enforcement is not available. I missed the discussion on IRC so I'm sorry if my comments are reduntant. I see one problem with this approach of hiding the output state to the client: there is no way to choose the content in advance based on the output protection capabilities. Most content providers have the same content available in multiple qualities, and the better qualities will be available based on the device and output capabilities. Since the client has no way of knowing on which output the video surface will be shown, the maximum protection level supported by all outputs should be exposed to the client, and the client can then determine if it's worth switching to a higher quality, and if there's a chance it will be displayed on at least one output. Regards, -Arnaud > On exposing connector info to the clients: > > The Client cannot request for content protection on a specific connector. > Wayland does not expose connector information to the clients. Client cannot > put a window on a specific connector. > Compositor always decides where the surfaces are to be shown. There is no > way for a client to audit that the compositor is doing the right thing, > compositor is trusted to begin with and there's no reason to inspect it. > > > On encryption of the content: > > The client will provide unencrypted data to the compositor. The Kernel > encrypts the content just before transmitting through the wire. > Once the Sink (the monitor), is authenticated to be HDCP compliant, the > display engine will encrypt the data and send to the sink, where it will be > decrypted. > > > Level of protection required by a client, depends on the type of content > sent by the client to the compositor: > > The Content sent by a client app can be : > > Type 0 : Supported by HDCP1.4, and HDCP2.2 > Type 1: Supported by only HDCP2.2 > > Clients just request for content protection and provide the content type ie > Type-0 or Type-1 to the compositor. > The compositor will check through all connectors of the intended surface > receivers and make sure all connectors support the given content type. > > In case if some connector/s do not support a given content type, there are > multiple strategy the compositor can follow: > > do not show the protected content on any of the connector, return > "content_protection failure" to the client. > show protected content on the supporting connectors, reduce image quality on > unprotected connectors, and return "content_protection_success" to the > client. > > The display driver will take the call for providing best possible protection > for a given content type. It will never provide information to the > compositor, about which content protection protocol is used, i.e. compositor > will only know if the connector supports a particular content-type, it would > never know if HDCP1.4 or 2.2 is employed. > > > Scope of the protocol extension: > > The protocol helps client to request for content protection. The client > needs to provide the content type. > It provides the client with events for successful/unsuccessful content > protection enablement. > Helps client to disable the content protection, and provide with success/ > fail events. > The policy for showing the protected content with low quality, or stop > showing the content on unprotected connectors is out of scope for the > protocol. > > At best it can provide some guidelines/ specifications, but there’s no way > to ensure that. > > > Note: Some things that are still open, but will be discussed later: > > SRM table (list of backlisted Monitors/Sinks) which need to be sent from the > client side. > Downstream topology handling by the compositor, in case of, HDCP repeaters. > > > > Thanks & Regards, > Ankit > > > ___ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/wayland-devel > -- Arnaud ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Issue with initial window position
Dear All,
I have a Qt Qml application which contains several windows (Qml windows). I
have set the initial positions x,y for these windows but none of these windows
are coming in the corresponding coordinates .Each time when I restart the
application the windows are coming in the random positions .I tested this with
a single window qml application and that too is having the same problem .
I have tried several things from the qt qml application side but failed I have
posted this in Qt forum but couldnt find a proper solution.
https://forum.qt.io/topic/90936/qml-windows-not-coming-on-specified-x-y-coordinates
https://stackoverflow.com/questions/50460064/qml-windows-not-coming-on-specified-x-y-coordinates
I have came in to a conclusion that the issue is from the underlying wayland
side .I am using weston version 3.0.0 and qt 5.8 .
Is there any thing that can done with wayland api.Can you please guide me to a
solution.I have attached the code I have used.
Thanks,
Prasanth
Confidentiality Statement / Disclaimer : This message and any attachments is
intended for the sole use of the intended recipient. It may contain
confidential information. Any unauthorized use, dissemination or modification
is strictly prohibited. If you are not the intended recipient, please notify
the sender immediately then delete it from all your systems, and do not copy,
use or print. Internet communications are not secure and it is the
responsibility of the recipient to make sure that it is virus/malicious code
exempt.
The company/sender cannot be responsible for any unauthorized alterations or
modifications made to the contents. If you require any form of confirmation of
the contents, please contact the company/sender. The company/sender is not
liable for any errors or omissions in the content of this message.
import QtQuick 2.3
import QtQuick.Window 2.2
import QtQuick.Controls 1.4
Window {
id:idParent
visible: true
x:0
y:0
height: 1080
width:1920
flags: Qt.FramelessWindowHint
Window
{
id:idW1
x:0
y:0
flags: Qt.FramelessWindowHint
width:960
height: 1080
color: "red"
visible: true
}
Window
{
id:idW2
flags: Qt.FramelessWindowHint
x:960
y:0
width:960
height: 1080
color: "yellow"
visible: true
}
Component.onCompleted: {
console.log(" width "+Screen.width+ " height "+ Screen.height +" idW1 x
"+idW1.x+" idW1.y "+idW1.y+" idW1.height "+ idW1.height +" idW1.Width "+
idW1.width +" idW2 x "+idW2.x+" idW2.y "+idW2.y+" idW2.height "+ idW2.height
+" idW1.Width "+ idW1.width)
}
}
int main(int argc, char *argv[])
{
QGuiApplication app(argc, argv);
QQmlApplicationEngine engine;
engine.load(QUrl(QStringLiteral("qrc:/main.qml")));
return app.exec();
}___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: how to handle the last_error of wl_display
On Thu, 14 Jun 2018 16:59:35 +0800 zou lan wrote: > Dear pekka & All: > > I find a wayland application report error about allocate memory fail. > I check the code, after request to weston to allocate dma buffer, it call > wl_display_roundtrip(). > But this function return very fast, it doesn't block until the create > events back. > > I suspect the display->last_error is not 0. Then the wl_display_roundtrip() > return fast because of the last_error. Does it right? Hi, sounds plausible. > I find the following log: > > wl_display@1: error 0: invalid object 10 Your application has a bug. > Does the application need to handle the display errors? How could I make > the last_error not impact wl_display_roundtrip? All protocol errors are always fatal: they cause the client to be disconnected and render the client wl_display unusable. The application can only report the error somewhere and quit. Protocol errors always imply a bug. Usually the bug is in the client code, but it could be in compositor code as well. Thanks, pq pgpSpLSsWqGge.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: is there anyway to get which compositor did the client "wl_display" object connected?
On Thu, 14 Jun 2018 16:59:54 +0800 (CST)
tugouxp <13824125...@163.com> wrote:
> hi:
>
> thanks for you answer.
>
> i need this on webkitgtk debug scenario, webkitgtk has a nested
> compositor, it seems the "webprocess" of webkit need both connect the
> nest compositer and the system compositors, so there are two some of
> objecet sets with same client type. for example:
>
>
> i dont know which compositor the "wl_compositor_create_surface"
> performs on? is there any way to know this?
>
Not really, no, sorry. You could possibly make case for adding some ABI
to libwayland-client to help identify the wl_display, but since you
already wrap the wl_display in a C++ object anyway, you could just have
an id field there.
There doesn't seem to be anything helpful in wl_proxy. It wouldn't be
unthinkable to add wl_proxy_get_display() to return the associated
wl_display. Knowing that a thing is a wl_proxy, you could already
inspect the private fields to find out the wl_display in a debugger.
Thanks,
pq
>
> 118 WlUniquePtr PlatformDisplayWayland::createSurface()
> const
> 119 {
> 120 if (!m_compositor)
> 121 ¦ return nullptr;
> 122
> 123 return WlUniquePtr wl_surface>(wl_compositor_create_surface(m_compositor.get()));
> 124 }
>
>
> thanks for your support!
>
>
>
>
>
>
>
> At 2018-06-14 15:15:25, "Pekka Paalanen" wrote:
> >On Thu, 14 Jun 2018 10:30:35 +0800 (CST)
> >tugouxp <13824125...@163.com> wrote:
> >
> >> hi folks:
> >>there are scenario that when more than one compositor (such as nested
> >> compositor" ) exists.
> >>
> >>
> >> how to distinguish which server do the client "wl_display*" object
> >> connected? is there any way to do this?
> >
> >Hi,
> >
> >I think you could get the socket fd and fstat() it, but aside that I
> >don't recall anything. There might not even be a file if the connection
> >was created with socketpair(). I'm not sure if you can somehow get the
> >pid of the server process, maybe you can. There is no protocol for
> >identifying the server, but if this is about an app-internal server,
> >you could easily write tiny a protocol extension to identify your
> >internal server from anything else.
> >
> >What do you want to use it for?
> >
> >
> >Thanks,
> >pq
pgpY28F_CINoR.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 1/3] doc: move Contributing
Hi Pekka, On Wed, 13 Jun 2018 at 14:33, Pekka Paalanen wrote: > Gitlab expects a CONTRIBUTING.md in the root directory, so move our > guide there. > > Conversion to proper markup is a follow-up patch. Thanks for these; both series are: Reviewed-by: Daniel Stone Cheers, Daniel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland-web 2/2] index: add link to Gitlab repositories
On Thu, 14 Jun 2018 08:53:51 +1000 Peter Hutterer wrote: > On Wed, Jun 13, 2018 at 04:32:26PM +0300, Pekka Paalanen wrote: > > From: Pekka Paalanen > > > > We migrated some. > > > > Signed-off-by: Pekka Paalanen > > --- > > index.html | 3 ++- > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > diff --git a/index.html b/index.html > > index 90b1dcf..adade70 100644 > > --- a/index.html > > +++ b/index.html > > @@ -40,7 +40,8 @@ embedded and mobile use cases. > > Software: > > > >Releases > > - https://cgit.freedesktop.org/wayland;>Wayland git > > repositories > > + https://gitlab.freedesktop.org/wayland;>Wayland > > repositories (Gitlab.freedesktop.org is the upstream) > > s/Gitlab/gitlab/ > > Reviewed-by: Peter Hutterer for the whole series > though Thanks, I've pushed this one already: 61d3cb8..978d89e master -> master Cheers, pq > > Cheers, >Peter > > > + https://cgit.freedesktop.org/wayland;>Old Wayland git > > repositories (mirrors and those that are not in Gitlab) > >Building Weston > >X clients on Wayland > >Extras: some apps and debugging tools > > -- > > 2.16.4 > > > > ___ > > wayland-devel mailing list > > wayland-devel@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/wayland-devel > > pgp9bJrkyBgIJ.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re:Re: is there anyway to get which compositor did the client "wl_display" object connected?
hi:
thanks for you answer.
i need this on webkitgtk debug scenario, webkitgtk has a nested compositor,
it seems the "webprocess" of webkit need both connect the nest compositer and
the system compositors, so there are two some of objecet sets with same client
type. for example:
i dont know which compositor the "wl_compositor_create_surface" performs on?
is there any way to know this?
118 WlUniquePtr PlatformDisplayWayland::createSurface() const
119 {
120 if (!m_compositor)
121 ¦ return nullptr;
122
123 return WlUniquePtr(wl_compositor_create_surface(m_compositor.get()));
124 }
thanks for your support!
At 2018-06-14 15:15:25, "Pekka Paalanen" wrote:
>On Thu, 14 Jun 2018 10:30:35 +0800 (CST)
>tugouxp <13824125...@163.com> wrote:
>
>> hi folks:
>>there are scenario that when more than one compositor (such as nested
>> compositor" ) exists.
>>
>>
>> how to distinguish which server do the client "wl_display*" object
>> connected? is there any way to do this?
>
>Hi,
>
>I think you could get the socket fd and fstat() it, but aside that I
>don't recall anything. There might not even be a file if the connection
>was created with socketpair(). I'm not sure if you can somehow get the
>pid of the server process, maybe you can. There is no protocol for
>identifying the server, but if this is about an app-internal server,
>you could easily write tiny a protocol extension to identify your
>internal server from anything else.
>
>What do you want to use it for?
>
>
>Thanks,
>pq
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
how to handle the last_error of wl_display
Dear pekka & All: I find a wayland application report error about allocate memory fail. I check the code, after request to weston to allocate dma buffer, it call wl_display_roundtrip(). But this function return very fast, it doesn't block until the create events back. I suspect the display->last_error is not 0. Then the wl_display_roundtrip() return fast because of the last_error. Does it right? I find the following log: wl_display@1: error 0: invalid object 10 Does the application need to handle the display errors? How could I make the last_error not impact wl_display_roundtrip? Thank you. Best Regards Nancy ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC PATCH wayland 3/3] contributing: reformat code examples
On Thu, 14 Jun 2018 08:53:19 +1000
Peter Hutterer wrote:
> On Wed, Jun 13, 2018 at 04:32:24PM +0300, Pekka Paalanen wrote:
> > From: Pekka Paalanen
> >
> > Before, the code examples looked good in the file, but a hard tab was
> > rendered as 4 spaces by Gitlab.
> >
> > Now, Gitlab renders the code examples like they should look, with 8-wide
> > tabs, but the file looks awful.
> >
> > Signed-off-by: Pekka Paalanen
> > ---
> >
> > Is it better with or without this patch?
>
> IMO it's worse, it makes the source file unreadable.
>
> Depends who you consider the main reference, the .md file itself or the
> online rendered one. I don't know if there's a clear preference for either.
> fwiw, I opted for replacing all tabs with spaces in the libinput
> CODING_STYLE document (i.e. make the rendered one look correct), with this
> warning at the top:
>
> **Note: this file uses spaces due to markdown rendering issues for tabs.
> Code must be implemented using tabs.**
Hi Peter,
I like that idea, I'll go for it.
Also, I used the tags because at least worked with them. I
didn't try with ``` if it'd work, but I do like ``` more than
.
Thanks,
pq
>
> Cheers,
>Peter
>
> >
> > You can see the result in:
> > https://gitlab.freedesktop.org/pq/wayland/blob/61f169d24af699643708d22f728890151994d05e/CONTRIBUTING.md
> >
> > CONTRIBUTING.md | 36 ++--
> > 1 file changed, 18 insertions(+), 18 deletions(-)
> >
> > diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
> > index b22fdef..0c2990e 100644
> > --- a/CONTRIBUTING.md
> > +++ b/CONTRIBUTING.md
> > @@ -134,19 +134,19 @@ try to follow the rules below.
> > static int
> > my_function(void)
> > {
> > - int a = 0;
> > -
> > - if (a)
> > - b();
> > - else
> > - c();
> > -
> > - if (a) {
> > - b();
> > - c();
> > - } else {
> > - d();
> > - }
> > +int a = 0;
> > +
> > +if (a)
> > +b();
> > +else
> > +c();
> > +
> > +if (a) {
> > +b();
> > +c();
> > +} else {
> > +d();
> > +}
> > }
> >
> >
> > @@ -158,12 +158,12 @@ my_function(void)
> >sense;
> >
> >
> > - long_variable_name =
> > - function_with_a_really_long_name(parameter1, parameter2,
> > -parameter3, parameter4);
> > +long_variable_name =
> > +function_with_a_really_long_name(parameter1, parameter2,
> > + parameter3, parameter4);
> >
> > - x = function_with_a_really_long_name(parameter1, parameter2,
> > -parameter3, parameter4);
> > +x = function_with_a_really_long_name(parameter1, parameter2,
> > + parameter3, parameter4);
> >
> >
> > Conduct
> > --
> > 2.16.4
> >
> > ___
> > wayland-devel mailing list
> > wayland-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/wayland-devel
> >
pgpY4JV77Feqh.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 1/3] doc: move Contributing
On Thu, 14 Jun 2018 08:48:10 +1000 Peter Hutterer wrote: > On Wed, Jun 13, 2018 at 04:32:22PM +0300, Pekka Paalanen wrote: > > From: Pekka Paalanen > > > > Gitlab expects a CONTRIBUTING.md in the root directory, so move our > > guide there. > > > > Conversion to proper markup is a follow-up patch. > > > > Signed-off-by: Pekka Paalanen > > --- > > doc/Contributing => CONTRIBUTING.md | 0 > > Makefile.am | 2 +- > > doc/Makefile.am | 2 -- > > 3 files changed, 1 insertion(+), 3 deletions(-) > > rename doc/Contributing => CONTRIBUTING.md (100%) > > > > diff --git a/doc/Contributing b/CONTRIBUTING.md > > similarity index 100% > > rename from doc/Contributing > > rename to CONTRIBUTING.md > > diff --git a/Makefile.am b/Makefile.am > > index 741db5e..697c517 100644 > > --- a/Makefile.am > > +++ b/Makefile.am > > @@ -121,7 +121,7 @@ BUILT_SOURCES = \ > > > > CLEANFILES = $(BUILT_SOURCES) doc/doxygen/doxygen_sqlite3.db > > DISTCLEANFILES = src/wayland-version.h > > -EXTRA_DIST = > > +EXTRA_DIST = CONTRIBUTING.md > > just a general comment - is that something we need to have in the tarball? > contributing from a tarball is something we should discourage. Hi, that's a good point. On the other hand, the instructions demand using git, wouldn't that be enough? Once we get meson, it's going to be in the tar-ball anyway AFAIU. I've also experienced how leaving files out of the tar-ball will make downstream backport patching more inconvenient, because one needs to drop the hunks that touch files that do not exist in the tar-ball. Thanks, pq > > Cheers, >Peter > > > > > > > > > diff --git a/doc/Makefile.am b/doc/Makefile.am > > index 14637af..1efd3e2 100644 > > --- a/doc/Makefile.am > > +++ b/doc/Makefile.am > > @@ -1,3 +1 @@ > > SUBDIRS = doxygen publican man > > - > > -EXTRA_DIST = Contributing > > -- > > 2.16.4 > > > > ___ > > wayland-devel mailing list > > wayland-devel@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/wayland-devel > > pgpUKBkE6m_zc.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: is there anyway to get which compositor did the client "wl_display" object connected?
On Thu, 14 Jun 2018 10:30:35 +0800 (CST) tugouxp <13824125...@163.com> wrote: > hi folks: >there are scenario that when more than one compositor (such as nested > compositor" ) exists. > > > how to distinguish which server do the client "wl_display*" object connected? > is there any way to do this? Hi, I think you could get the socket fd and fstat() it, but aside that I don't recall anything. There might not even be a file if the connection was created with socketpair(). I'm not sure if you can somehow get the pid of the server process, maybe you can. There is no protocol for identifying the server, but if this is about an app-internal server, you could easily write tiny a protocol extension to identify your internal server from anything else. What do you want to use it for? Thanks, pq pgpojtQVuRWWJ.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Release schedule
On Wed, 13 Jun 2018 21:05:03 -0400 ferreiradaselva wrote: > Any chance of the XDG decoration protocol being part of this release plan? Hi, wayland-protocols is not part of this release plan. It is much more free to release at arbitrary times and usually does not go through a freeze period either. Unless you mean a Weston implementation of that? Thanks, pq pgpTiIS3mBmq9.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
