Re: [PATCH v2] server: add wl_display_destroy_clients()
> Original Message
>Subject: Re: [PATCH v2] server: add wl_display_destroy_clients()
>Local Time: December 13, 2017 12:11 PM
>UTC Time: December 13, 2017 11:11 AM
>From: ppaala...@gmail.com
>To: emersion
>wayland-devel@lists.freedesktop.org
>
>On Wed, 13 Dec 2017 11:51:19 +0100
> emersion cont...@emersion.fr wrote:
>>Bug [1] reported that wl_display_destroy() doesn't destroy clients, so
>> client socket file descriptors are being kept open until the compositor
>> process exits.
>>Patch [2] proposed to destroy clients in wl_display_destroy(). The
>> patch was not accepted because doing so changes the ABI.
>>Thus, a new wl_display_destroy_clients() function is added in this
>> patch. It should be called by compositors right before
>> wl_display_destroy().
>>[1] https://bugs.freedesktop.org/show_bug.cgi?id=99142
>> [2] https://patchwork.freedesktop.org/patch/128832/
>>Signed-off-by: emersion cont...@emersion.fr
>>
>>v2: change commit message, add docs, use a safer approach when iterating
>> over the client list
>>src/wayland-server-core.h | 3 +++
>> src/wayland-server.c | 38 ++
>> 2 files changed, 41 insertions(+)
>>diff --git a/src/wayland-server-core.h b/src/wayland-server-core.h
>> index fd458c5..2e725d9 100644
>> --- a/src/wayland-server-core.h
>> +++ b/src/wayland-server-core.h
>> @@ -214,6 +214,9 @@ wl_display_run(struct wl_display *display);
>> void
>> wl_display_flush_clients(struct wl_display *display);
>>+void
>> +wl_display_destroy_clients(struct wl_display *display);
>> +
>> struct wl_client;
>>typedef void (*wl_global_bind_func_t)(struct wl_client *client, void *data,
>> diff --git a/src/wayland-server.c b/src/wayland-server.c
>> index 82a3b01..33df413 100644
>> --- a/src/wayland-server.c
>> +++ b/src/wayland-server.c
>> @@ -1264,6 +1264,44 @@ wl_display_flush_clients(struct wl_display *display)
>> }
>> }
>>+/** Destroy all clients connected to the display
>> - -
>> - - \param display The display object
>> - -
>> - - This function should be called right before wl_display_destroy() to
>> ensure
>> - - all client resources are closed properly. Destroying a client from
>> within
>> - - wl_display_destroy_clients() is safe, but creating one will leak
>> resources
>> - - and raise a warning.
>> - -
>> - - \memberof wl_display
>> - */
>> +WL_EXPORT void
>> +wl_display_destroy_clients(struct wl_display *display)
>> +{
>> - struct wl_list tmp_client_list, *pos;
>> - struct wl_client *client;
>> -
>> - /* Move the whole client list to a temporary head because some new clients
>> - - might be added to the original head. */
>> - wl_list_init(&tmp_client_list);
>> - wl_list_insert_list(&tmp_client_list, &display->client_list);
>> - wl_list_init(&display->client_list);
>> -
>> - /* wl_list_for_each_safe isn't enough here: it fails if the next client is
>> - - destroyed by the destroy handler of the current one. */
>> - while (!wl_list_empty(&tmp_client_list)) {
>> - pos = tmp_client_list.next;
>>
>> - client = wl_container_of(pos, client, link);
>>
>> -
>> - wl_client_destroy(client);
>>
>> - }
>> -
>> - if (!wl_list_empty(&display->client_list)) {
>> - wl_log("wl_display_destroy_clients: cannot destroy all clients because "
>>
>> - "new ones were created by destroy callbacks\n");
>>
>> - }
>> +}
>> -
>>static int
>> socket_data(int fd, uint32_t mask, void *data)
>> {
>
> Hi,
>
> very good!
>
> Reviewed-by: Pekka Paalanen pekka.paala...@collabora.co.uk
Thanks for your review!
> Do you have your compositor now calling this without issues?
Yes! I've tested the new function and it works properly. Here's the patch:
https://github.com/emersion/wlroots/commit/71d344cc616021a1d1ed6e075f8c7e0d15b0deb0
> It would be awesome to have a test in the libwayland test suite calling
> this function and checking a client gets destroyed, especially as we
> don't have Weston using this yet.
I'll try to make another patch for this.
> Thanks,
> pq
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH v2] server: add wl_display_destroy_clients()
> Original Message >Subject: Re: [PATCH v2] server: add wl_display_destroy_clients() >Local Time: December 13, 2017 1:39 PM >UTC Time: December 13, 2017 12:39 PM >From: ppaala...@gmail.com >To: Simon Ser >wayland-devel@lists.freedesktop.org > >On Wed, 13 Dec 2017 06:59:10 -0500 >Simon Ser wrote: > >> > Original Message >> >Subject: Re: [PATCH v2] server: add wl_display_destroy_clients() >> >Local Time: December 13, 2017 12:11 PM >> >UTC Time: December 13, 2017 11:11 AM >> >From: ppaala...@gmail.com >> >To: emersion >> >wayland-devel@lists.freedesktop.org >> > >> >On Wed, 13 Dec 2017 11:51:19 +0100 >> > emersion cont...@emersion.fr wrote: >> >>Bug [1] reported that wl_display_destroy() doesn't destroy clients, so >> >> client socket file descriptors are being kept open until the compositor >> >> process exits. >> >>Patch [2] proposed to destroy clients in wl_display_destroy(). The >> >> patch was not accepted because doing so changes the ABI. >> >>Thus, a new wl_display_destroy_clients() function is added in this >> >> patch. It should be called by compositors right before >> >> wl_display_destroy(). >> >>[1] https://bugs.freedesktop.org/show_bug.cgi?id=99142 >> >> [2] https://patchwork.freedesktop.org/patch/128832/ >> >>Signed-off-by: emersion cont...@emersion.fr > >Hi, > >ah, your real name is Simon Ser? We need it in the Signed-off-by tag >for the tag to be valid, do you mind if I fix it while eventually landing >this patch? > >The Linux kernel patch submission guidelines say it's required, nick >names won't do. Yes, my real name is Simon Ser. Sorry, I wasn't aware of this rule. I'm fine with you fixing it. >> > >> > Hi, >> > >> > very good! >> > >> > Reviewed-by: Pekka Paalanen pekka.paala...@collabora.co.uk >> >> Thanks for your review! >> >> > Do you have your compositor now calling this without issues? >> >> Yes! I've tested the new function and it works properly. Here's the patch: >> https://github.com/emersion/wlroots/commit/71d344cc616021a1d1ed6e075f8c7e0d15b0deb0 > >Cool. > >> > It would be awesome to have a test in the libwayland test suite calling >> > this function and checking a client gets destroyed, especially as we >> > don't have Weston using this yet. >> >> I'll try to make another patch for this. > >Appreciated. > > >Thanks, >pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH] RFC: server: implement wl_priv_signal_emit without emit_list
This is a RFC to be able to run tests and check that this approach
is working. The end goal is to remove wl_priv_signal completely and
implement a safe wl_signal_emit.
---
What do you think of this approach? It passes all the tests.
src/wayland-private.h | 1 -
src/wayland-server.c | 31 ---
2 files changed, 16 insertions(+), 16 deletions(-)
diff --git a/src/wayland-private.h b/src/wayland-private.h
index 12b9032..ad58226 100644
--- a/src/wayland-private.h
+++ b/src/wayland-private.h
@@ -238,7 +238,6 @@ zalloc(size_t s)
struct wl_priv_signal {
struct wl_list listener_list;
- struct wl_list emit_list;
};
void
diff --git a/src/wayland-server.c b/src/wayland-server.c
index 7225b4e..d587816 100644
--- a/src/wayland-server.c
+++ b/src/wayland-server.c
@@ -1912,7 +1912,6 @@ void
wl_priv_signal_init(struct wl_priv_signal *signal)
{
wl_list_init(&signal->listener_list);
- wl_list_init(&signal->emit_list);
}
/** Add a listener to a signal
@@ -1947,9 +1946,6 @@ wl_priv_signal_get(struct wl_priv_signal *signal,
wl_notify_func_t notify)
wl_list_for_each(l, &signal->listener_list, link)
if (l->notify == notify)
return l;
- wl_list_for_each(l, &signal->emit_list, link)
- if (l->notify == notify)
- return l;
return NULL;
}
@@ -1966,25 +1962,30 @@ wl_priv_signal_emit(struct wl_priv_signal *signal, void
*data)
{
struct wl_listener *l;
struct wl_list *pos;
+ struct wl_listener cursor;
+ struct wl_listener end;
- wl_list_insert_list(&signal->emit_list, &signal->listener_list);
- wl_list_init(&signal->listener_list);
-
- /* Take every element out of the list and put them in a temporary list.
-* This way, the 'it' func can remove any element it wants from the list
-* without troubles, because we always get the first element, not the
-* one after the current, which may be invalid.
+ /* Add two special markers: one cursor and one end marker. This way, we
know
+* that we've already called listeners on the left of the cursor and
that we
+* don't want to call listeners on the right of the end marker. The 'it'
+* function can remove any element it wants from the list without
troubles.
* wl_list_for_each_safe tries to be safe but it fails: it works fine
* if the current item is removed, but not if the next one is. */
- while (!wl_list_empty(&signal->emit_list)) {
- pos = signal->emit_list.next;
+ wl_list_insert(&signal->listener_list, &cursor.link);
+ wl_list_insert(signal->listener_list.prev, &end.link);
+
+ while (cursor.link.next != &end.link) {
+ pos = cursor.link.next;
l = wl_container_of(pos, l, link);
- wl_list_remove(pos);
- wl_list_insert(&signal->listener_list, pos);
+ wl_list_remove(&cursor.link);
+ wl_list_insert(pos, &cursor.link);
l->notify(l, data);
}
+
+ wl_list_remove(&cursor.link);
+ wl_list_remove(&end.link);
}
/** \endcond INTERNAL */
--
2.16.1
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] RFC: server: implement wl_priv_signal_emit without emit_list
Bump! Can you give me feedback please? Having a safe wl_signal_emit would
greatly benefit libwayland users.
---
Simon Ser
https://emersion.fr
Original Message
On January 28, 2018 6:37 PM, Simon Ser wrote:
>
>This is a RFC to be able to run tests and check that this approach
> is working. The end goal is to remove wl_priv_signal completely and
> implement a safe wl_signal_emit.
>
>What do you think of this approach? It passes all the tests.
> src/wayland-private.h | 1 -
> src/wayland-server.c | 31 ---
> 2 files changed, 16 insertions(+), 16 deletions(-)
>
> diff --git a/src/wayland-private.h b/src/wayland-private.h
> index 12b9032..ad58226 100644
> --- a/src/wayland-private.h
> +++ b/src/wayland-private.h
> @@ -238,7 +238,6 @@ zalloc(size_t s)
>
> struct wl_priv_signal {
> struct wl_list listener_list;
> - struct wl_list emit_list;
> };
>
> void
> diff --git a/src/wayland-server.c b/src/wayland-server.c
> index 7225b4e..d587816 100644
> --- a/src/wayland-server.c
> +++ b/src/wayland-server.c
> @@ -1912,7 +1912,6 @@ void
> wl_priv_signal_init(struct wl_priv_signal *signal)
> {
> wl_list_init(&signal->listener_list);
>
> - wl_list_init(&signal->emit_list);
>}
>
> /** Add a listener to a signal
> @@ -1947,9 +1946,6 @@ wl_priv_signal_get(struct wl_priv_signal *signal,
> wl_notify_func_t notify)
> wl_list_for_each(l, &signal->listener_list, link)
> if (l->notify == notify)
>
> return l;
>
> - wl_list_for_each(l, &signal->emit_list, link)
>
> - if (l->notify == notify)
>
>
> - return l;
>
>
> return NULL;
> }
> @@ -1966,25 +1962,30 @@ wl_priv_signal_emit(struct wl_priv_signal *signal,
> void *data)
> {
> struct wl_listener *l;
> struct wl_list *pos;
> - struct wl_listener cursor;
>
> - struct wl_listener end;
>
>
> - wl_list_insert_list(&signal->emit_list, &signal->listener_list);
>
> - wl_list_init(&signal->listener_list);
>
> -
>
> - /* Take every element out of the list and put them in a temporary list.
>
> -
> - This way, the 'it' func can remove any element it wants from the list
>
>
> -
> - without troubles, because we always get the first element, not the
>
>
> -
> - one after the current, which may be invalid.
>
>
> - /* Add two special markers: one cursor and one end marker. This way, we know
>
> -
> - that we've already called listeners on the left of the cursor and that we
>
>
> -
> - don't want to call listeners on the right of the end marker. The 'it'
>
>
> -
> - function can remove any element it wants from the list without troubles.
>
> - wl_list_for_each_safe tries to be safe but it fails: it works fine
>
> - if the current item is removed, but not if the next one is. */
>
>
> - while (!wl_list_empty(&signal->emit_list)) {
>
> - pos = signal->emit_list.next;
>
>
> - wl_list_insert(&signal->listener_list, &cursor.link);
>
> - wl_list_insert(signal->listener_list.prev, &end.link);
>
> -
>
> - while (cursor.link.next != &end.link) {
>
> - pos = cursor.link.next;
> l = wl_container_of(pos, l, link);
>
>
> - wl_list_remove(pos);
>
>
> - wl_list_insert(&signal->listener_list, pos);
>
>
> - wl_list_remove(&cursor.link);
>
>
> - wl_list_insert(pos, &cursor.link);
>
>
> l->notify(l, data);
>}
>
> -
>
> - wl_list_remove(&cursor.link);
>
> - wl_list_remove(&end.link);
> }
>
> /** \endcond INTERNAL */
> --
> 2.16.1
>
>
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH] core: implement a safe wl_signal_emit
The previous implementation tried to be safe but wasn't: a
listener couldn't remove the next one.
This removes the need for wl_priv_signal. newsignal-test is now
merged into signal-test.
---
This is followup of "RFC: server: implement wl_priv_signal_emit without
emit_list" [1] which removes wl_priv_signal.
[1]:
https://lists.freedesktop.org/archives/wayland-devel/2018-January/036711.html
Makefile.am | 3 -
src/wayland-private.h | 17 ---
src/wayland-server-core.h | 28 +++-
src/wayland-server.c | 141 ---
tests/newsignal-test.c| 337 --
tests/signal-test.c | 222 +-
6 files changed, 270 insertions(+), 478 deletions(-)
delete mode 100644 tests/newsignal-test.c
diff --git a/Makefile.am b/Makefile.am
index 322d6b8..5db0347 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -171,7 +171,6 @@ built_test_programs = \
socket-test \
queue-test \
signal-test \
- newsignal-test \
resources-test \
message-test\
headers-test\
@@ -252,8 +251,6 @@ queue_test_LDADD = libtest-runner.la
signal_test_SOURCES = tests/signal-test.c
signal_test_LDADD = libtest-runner.la
# wayland-server.c is needed here to access wl_priv_* functions
-newsignal_test_SOURCES = tests/newsignal-test.c src/wayland-server.c
-newsignal_test_LDADD = libtest-runner.la
resources_test_SOURCES = tests/resources-test.c
resources_test_LDADD = libtest-runner.la
message_test_SOURCES = tests/message-test.c
diff --git a/src/wayland-private.h b/src/wayland-private.h
index 12b9032..e2803ee 100644
--- a/src/wayland-private.h
+++ b/src/wayland-private.h
@@ -236,23 +236,6 @@ zalloc(size_t s)
return calloc(1, s);
}
-struct wl_priv_signal {
- struct wl_list listener_list;
- struct wl_list emit_list;
-};
-
-void
-wl_priv_signal_init(struct wl_priv_signal *signal);
-
-void
-wl_priv_signal_add(struct wl_priv_signal *signal, struct wl_listener
*listener);
-
-struct wl_listener *
-wl_priv_signal_get(struct wl_priv_signal *signal, wl_notify_func_t notify);
-
-void
-wl_priv_signal_emit(struct wl_priv_signal *signal, void *data);
-
void
wl_connection_close_fds_in(struct wl_connection *connection, int max);
diff --git a/src/wayland-server-core.h b/src/wayland-server-core.h
index 2e725d9..965bb39 100644
--- a/src/wayland-server-core.h
+++ b/src/wayland-server-core.h
@@ -462,10 +462,34 @@ wl_signal_get(struct wl_signal *signal, wl_notify_func_t
notify)
static inline void
wl_signal_emit(struct wl_signal *signal, void *data)
{
- struct wl_listener *l, *next;
+ struct wl_listener *l;
+ struct wl_list *pos;
+ struct wl_listener cursor;
+ struct wl_listener end;
+
+ /* Add two special markers: one cursor and one end marker. This way, we
know
+* that we've already called listeners on the left of the cursor and
that we
+* don't want to call listeners on the right of the end marker. The 'it'
+* function can remove any element it wants from the list without
troubles.
+* wl_list_for_each_safe tries to be safe but it fails: it works fine
+* if the current item is removed, but not if the next one is. */
+ wl_list_insert(&signal->listener_list, &cursor.link);
+ cursor.notify = NULL;
+ wl_list_insert(signal->listener_list.prev, &end.link);
+ end.notify = NULL;
+
+ while (cursor.link.next != &end.link) {
+ pos = cursor.link.next;
+ l = wl_container_of(pos, l, link);
+
+ wl_list_remove(&cursor.link);
+ wl_list_insert(pos, &cursor.link);
- wl_list_for_each_safe(l, next, &signal->listener_list, link)
l->notify(l, data);
+ }
+
+ wl_list_remove(&cursor.link);
+ wl_list_remove(&end.link);
}
typedef void (*wl_resource_destroy_func_t)(struct wl_resource *resource);
diff --git a/src/wayland-server.c b/src/wayland-server.c
index eb1e500..c41f8e9 100644
--- a/src/wayland-server.c
+++ b/src/wayland-server.c
@@ -76,10 +76,10 @@ struct wl_client {
struct wl_resource *display_resource;
struct wl_list link;
struct wl_map objects;
- struct wl_priv_signal destroy_signal;
+ struct wl_signal destroy_signal;
struct ucred ucred;
int error;
- struct wl_priv_signal resource_created_signal;
+ struct wl_signal resource_created_signal;
};
struct wl_display {
@@ -95,8 +95,8 @@ struct wl_display {
struct wl_list client_list;
struct wl_list protocol_loggers;
- struct wl_priv_signal destroy_signal;
- struct wl_priv_signal create_client_signal;
+ struct wl_signal destroy_signal;
+
[PATCH wayland-protocols] unstable: add xdg-toplevel-decoration protocol
This adds a new protocol to negotiate server- and client-side rendering of window decorations for xdg-toplevels. --- This is inspired by a protocol from KDE[0] which has been implemented in KDE and Sway and was submitted for consideration in 2017[1]. This patch provides an updated protocol with those concerns taken into account. This was iterated on privately between representatives of Sway and wlroots (Simon Ser and Drew DeVault), KDE (David Edmundson), and Mir (Alan Griffiths). A proof-of-concept of a client and server implementation is available at [2]. [0] https://github.com/KDE/kwayland/blob/master/src/client/protocols/server-decoration.xml [1] https://lists.freedesktop.org/archives/wayland-devel/2017-October/035564.html [2] https://github.com/swaywm/wlroots/pull/638 Makefile.am| 1 + unstable/xdg-toplevel-decoration/README| 4 + .../xdg-toplevel-decoration-unstable-v1.xml| 127 + 3 files changed, 132 insertions(+) create mode 100644 unstable/xdg-toplevel-decoration/README create mode 100644 unstable/xdg-toplevel-decoration/xdg-toplevel-decoration-unstable-v1.xml diff --git a/Makefile.am b/Makefile.am index 4b9a901..07744e9 100644 --- a/Makefile.am +++ b/Makefile.am @@ -17,6 +17,7 @@ unstable_protocols = \ unstable/keyboard-shortcuts-inhibit/keyboard-shortcuts-inhibit-unstable-v1.xml \ unstable/xdg-output/xdg-output-unstable-v1.xml \ unstable/input-timestamps/input-timestamps-unstable-v1.xml \ + unstable/xdg-toplevel-decoration/xdg-toplevel-decoration-unstable-v1.xml \ $(NULL) stable_protocols = \ diff --git a/unstable/xdg-toplevel-decoration/README b/unstable/xdg-toplevel-decoration/README new file mode 100644 index 000..e927110 --- /dev/null +++ b/unstable/xdg-toplevel-decoration/README @@ -0,0 +1,4 @@ +xdg_toplevel_decoration protocol + +Maintainers: +Simon Ser diff --git a/unstable/xdg-toplevel-decoration/xdg-toplevel-decoration-unstable-v1.xml b/unstable/xdg-toplevel-decoration/xdg-toplevel-decoration-unstable-v1.xml new file mode 100644 index 000..acc1ed2 --- /dev/null +++ b/unstable/xdg-toplevel-decoration/xdg-toplevel-decoration-unstable-v1.xml @@ -0,0 +1,127 @@ + + + +Copyright © 2018 Simon Ser + +Permission is hereby granted, free of charge, to any person obtaining a +copy of this software and associated documentation files (the "Software"), +to deal in the Software without restriction, including without limitation +the rights to use, copy, modify, merge, publish, distribute, sublicense, +and/or sell copies of the Software, and to permit persons to whom the +Software is furnished to do so, subject to the following conditions: + +The above copyright notice and this permission notice (including the next +paragraph) shall be included in all copies or substantial portions of the +Software. + +THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR +IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, +FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL +THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER +LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING +FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER +DEALINGS IN THE SOFTWARE. + + + + + This interface permits choosing between client-side and server-side + window decorations for a toplevel surface. + + A window decoration is a user interface component used to move, resize and + change a window's state. It can be managed either by the client (part of + the surface) or by the server. + + By advertizing this interface the server anounces support for server-side + window decorations. + + Warning! The protocol described in this file is experimental and + backward incompatible changes may be made. Backward compatible changes + may be added together with the corresponding interface version bump. + Backward incompatible changes are done by bumping the version number in + the protocol and interface names and resetting the interface version. + Once the protocol is to be declared stable, the 'z' prefix and the + version number in the protocol and interface names are removed and the + interface version number is reset. + + + + + + + + + +Destroy the decoration manager. + + + + + +Create a new decoration object associated with the given toplevel. + +Creating a zxdg_toplevel_decoration_v1 from a xdg_toplevel which has a +buffer attached or committed is a
Re: [PATCH wayland-protocols] unstable: add xdg-toplevel-decoration protocol
Hi Mike, I don't think a compositor supporting the protocol means that it always wants SSDs. For instance, I can imagine a DE like GNOME supporting it: - Allowing clients that prefer SSDs to use SSDs, so that toolkits like GLFW or winit and apps like mpv don't have to draw decorations that'll look alien and don't respect the user's preferences - But still preferring CSDs, so that GTK+ apps can use them Also, the CSD mode allows the client to do not draw decorations at all. Regards, On March 1, 2018 7:01 PM, Mike Blumenkrantz wrote: > Hi, > > This patch is certainly an improvement upon the previous protocol draft which > I reviewed, but it still does not address the most significant issue that I > pointed out, which is that it both is too complex and lacks features. Why is > there any "mode" when this is a protocol for enabling server-side > decorations? By using the protocol in a server or client, you are enabling > server-side decoration; why would there be any mention of client-side at all? > If the compositor, for whatever reason, decides to do a runtime disable of > SSD then it can simply destroy the global. > > Please see again my mail on this topic from the previous thread: > https://lists.freedesktop.org/archives/wayland-devel/2018-January/036495.html > > Regards, > > Mike > > On Sun, Feb 18, 2018 at 3:01 PM Simon Ser wrote: > > > This adds a new protocol to negotiate server- and client-side rendering of > > > > window decorations for xdg-toplevels. > > > > \-\-\- > > > > This is inspired by a protocol from KDE\[0\] which has been implemented in > > KDE > > > > and Sway and was submitted for consideration in 2017\[1\]. This patch > > provides an > > > > updated protocol with those concerns taken into account. > > > > This was iterated on privately between representatives of Sway and wlroots > > > > (Simon Ser and Drew DeVault), KDE (David Edmundson), and Mir (Alan > > Griffiths). > > > > A proof-of-concept of a client and server implementation is available at > > \[2\]. > > > > \[0\] > > https://github.com/KDE/kwayland/blob/master/src/client/protocols/server-decoration.xml > > > > \[1\] > > https://lists.freedesktop.org/archives/wayland-devel/2017-October/035564.html > > > > \[2\] https://github.com/swaywm/wlroots/pull/638 > > > > Makefile.am | 1 + > > > > unstable/xdg-toplevel-decoration/README | 4 + > > > > .../xdg-toplevel-decoration-unstable-v1.xml | 127 > > + > > > > 3 files changed, 132 insertions(+) > > > > create mode 100644 unstable/xdg-toplevel-decoration/README > > > > create mode 100644 > > unstable/xdg-toplevel-decoration/xdg-toplevel-decoration-unstable-v1.xml > > > > diff --git a/Makefile.am b/Makefile.am > > > > index 4b9a901..07744e9 100644 > > > > \-\-\- a/Makefile.am > > > > \+\+\+ b/Makefile.am > > > > @@ -17,6 +17,7 @@ unstable_protocols = > > \ > > > > > > unstable/keyboard-shortcuts-inhibit/keyboard-shortcuts-inhibit-unstable-v1.xml > > \ > > > > unstable/xdg-output/xdg-output-unstable-v1.xml > > \ > > > > unstable/input-timestamps/input-timestamps-unstable-v1.xml \ > > > > + > > unstable/xdg-toplevel-decoration/xdg-toplevel-decoration-unstable-v1.xml > > \ > > > > $(NULL) > > > > stable_protocols = > > \ > > > > diff --git a/unstable/xdg-toplevel-decoration/README > > b/unstable/xdg-toplevel-decoration/README > > > > new file mode 100644 > > > > index 000..e927110 > > > > \-\-\- /dev/null > > > > \+\+\+ b/unstable/xdg-toplevel-decoration/README > > > > @@ -0,0 +1,4 @@ > > > > +xdg\_toplevel\_decoration protocol > > > > + > > > > +Maintainers: > > > > +Simon Ser > > > > diff --git > > a/unstable/xdg-toplevel-decoration/xdg-toplevel-decoration-unstable-v1.xml > > b/unstable/xdg-toplevel-decoration/xdg-toplevel-decoration-unstable-v1.xml > > > > new file mode 100644 > > > > index 000..acc1ed2 > > > > \-\-\- /dev/null > > > > \+\+\+ > > b/unstable/xdg-toplevel-decoration/xdg-toplevel-de
[PATCH wayland-protcols v2] unstable: add xdg-toplevel-decoration protocol
This adds a new protocol to negotiate server- and client-side rendering of window decorations for xdg-toplevels. This allows compositors that want to draw decorations themselves to send their preference to clients, and clients that prefer server-side decorations to request them. This is inspired by a protocol from KDE [1] which has been implemented in KDE and Sway and was submitted for consideration in 2017 [2]. This patch provides an updated protocol with those concerns taken into account. Signed-off-by: Simon Ser Reviewed-by: Drew DeVault Reviewed-by: David Edmundson Reviewed-by: Alan Griffiths Reviewed-by: Tony Crisci [1] https://github.com/KDE/kwayland/blob/master/src/client/protocols/server-decoration.xml [2] https://lists.freedesktop.org/archives/wayland-devel/2017-October/035564.html --- This was iterated on privately between representatives of Sway and wlroots (Simon Ser, Drew DeVault and Tony Crisci), KDE and Qt (David Edmundson), and Mir (Alan Griffiths). A proof-of-concept of a client and server implementation is available at [1]. Changes from v1 to v2: moved the enum above in the protocol, added Signed-off-by and Reviewed-by tags, updated the commit message. [1] https://github.com/swaywm/wlroots/pull/638 Makefile.am| 1 + unstable/xdg-toplevel-decoration/README| 4 + .../xdg-toplevel-decoration-unstable-v1.xml| 127 + 3 files changed, 132 insertions(+) create mode 100644 unstable/xdg-toplevel-decoration/README create mode 100644 unstable/xdg-toplevel-decoration/xdg-toplevel-decoration-unstable-v1.xml diff --git a/Makefile.am b/Makefile.am index 4b9a901..07744e9 100644 --- a/Makefile.am +++ b/Makefile.am @@ -17,6 +17,7 @@ unstable_protocols = \ unstable/keyboard-shortcuts-inhibit/keyboard-shortcuts-inhibit-unstable-v1.xml \ unstable/xdg-output/xdg-output-unstable-v1.xml \ unstable/input-timestamps/input-timestamps-unstable-v1.xml \ + unstable/xdg-toplevel-decoration/xdg-toplevel-decoration-unstable-v1.xml \ $(NULL) stable_protocols = \ diff --git a/unstable/xdg-toplevel-decoration/README b/unstable/xdg-toplevel-decoration/README new file mode 100644 index 000..e927110 --- /dev/null +++ b/unstable/xdg-toplevel-decoration/README @@ -0,0 +1,4 @@ +xdg_toplevel_decoration protocol + +Maintainers: +Simon Ser diff --git a/unstable/xdg-toplevel-decoration/xdg-toplevel-decoration-unstable-v1.xml b/unstable/xdg-toplevel-decoration/xdg-toplevel-decoration-unstable-v1.xml new file mode 100644 index 000..acc1ed2 --- /dev/null +++ b/unstable/xdg-toplevel-decoration/xdg-toplevel-decoration-unstable-v1.xml @@ -0,0 +1,127 @@ + + + +Copyright © 2018 Simon Ser + +Permission is hereby granted, free of charge, to any person obtaining a +copy of this software and associated documentation files (the "Software"), +to deal in the Software without restriction, including without limitation +the rights to use, copy, modify, merge, publish, distribute, sublicense, +and/or sell copies of the Software, and to permit persons to whom the +Software is furnished to do so, subject to the following conditions: + +The above copyright notice and this permission notice (including the next +paragraph) shall be included in all copies or substantial portions of the +Software. + +THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR +IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, +FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL +THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER +LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING +FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER +DEALINGS IN THE SOFTWARE. + + + + + This interface permits choosing between client-side and server-side + window decorations for a toplevel surface. + + A window decoration is a user interface component used to move, resize and + change a window's state. It can be managed either by the client (part of + the surface) or by the server. + + By advertizing this interface the server anounces support for server-side + window decorations. + + Warning! The protocol described in this file is experimental and + backward incompatible changes may be made. Backward compatible changes + may be added together with the corresponding interface version bump. + Backward incompatible changes are done by bumping the version number in + the protocol and interface names and resetting the interface version. + Once the protocol is to be declared stable, the 'z' pref
Re: [PATCH wayland-protocols] unstable: add xdg-toplevel-decoration protocol
Hi, Thanks for taking time reviewing the protocol and suggesting an alternative design. On March 2, 2018 4:36 PM, Mike Blumenkrantz wrote: > Hi, > > I agree with your point regarding a SSD-capable compositor not always wanting > them, and certainly I can see the usefulness for cases such as what you've > cited. However, in the example you provided, it's easy enough for an > application to determine what desktop it's running in and then determine > whether to use SSD--if the compositor implements and advertises this protocol > then it's ultimately a client decision whether to use it. I don't think "detecting the desktop environment" is a good idea. Some other DEs (elementary, Unity) might also prefer GTK+ CSDs even if they're not GNOME, and - supposing there's a good way to know which DE is currently running - hardcoding the names of DEs is a slippery slope. > My issue is in the inconsistency of the protocol that has been proposed here. > This is a protocol for enabling SSD; there should be no need for anything > related to CSD, and I don't think there is a need for clients to have any > form of protocol request to toggle between CSD and SSD. This is not a protocol to enable SSDs, this is a protocol to negotiate client- or server-side decorations. This is stated in the protocol description. > Based on your assertion that borderless mode would be achieved in this > protocol in the CSD mode, I would raise the counterpoint that in this case > the client should just destroy the zxdg\_toplevel\_decoration_v1 object > which, according to the destroy request, would revert to the surface using > CSD anyway, furthering my assessment that there is indeed no need for any > mention of CSD in the protocol requests. This is racy - there will be frames with both client-side and server-side decorations. > This change allows for everything except the destroy request to be removed > from zxdg\_toplevel\_decoration_v1, greatly simplifying the protocol as well > as implementations of it. The case of the compositor "ignoring" the request > to create SSD also becomes moot as well, since all that would mean is the > compositor has chosen to use a borderless state at this time (e.g., tiling > layout) which is irrelevant to the client anyway. I don't understand your last point. A tiling layout would be exposed as SSD to the client. > This aside, there's some other items of note here, such as the lack of > precision related to when the change in decoration management state takes > effect: most likely it should be applied on the next surface commit? I think > this should be specified in the zxdg\_toplevel\_decoration_v1 interface > description. Also, I would think that destroying the > zxdg\_toplevel\_decoration\_manager\_v1 object while any > zxdg\_toplevel\_decoration_v1 objects exist should be a client error, but > this is similarly not specified anywhere. The protocol integrates with the xdg-shell configuration mechanism, and I've been using the same wording as xdg-shell. xdg-toplevel-decoration just adds one property to the set of double-buffered xdg-surface properties (just like xdg-toplevel adds properties to xdg-surface). There are a bunch of "See xdg_surface.configure" in the description and as an extension of xdg-shell the protocol assumes the reader knows how xdg-shell works. > Regards, > > Mike > > On Thu, Mar 1, 2018 at 1:18 PM Simon Ser wrote: > > > Hi Mike, > > > > I don't think a compositor supporting the protocol means that it always > > wants SSDs. For instance, I can imagine a DE like GNOME supporting it: > > > > - Allowing clients that prefer SSDs to use SSDs, so that toolkits like GLFW > > or winit and apps like mpv don't have to draw decorations that'll look > > alien and don't respect the user's preferences > > - But still preferring CSDs, so that GTK+ apps can use them > > > > Also, the CSD mode allows the client to do not draw decorations at all. > > > > Regards, > > > > On March 1, 2018 7:01 PM, Mike Blumenkrantz > > wrote: > > > Hi, > > > > > > This patch is certainly an improvement upon the previous protocol draft > > > which I reviewed, but it still does not address the most significant > > > issue that I pointed out, which is that it both is too complex and lacks > > > features. Why is there any "mode" when this is a protocol for enabling > > > server-side decorations? By using the protocol in a server or client, you > > > are enabling server-side decoration; why would there be any mention of > > > client-side at all? If
Re: [PATCH wayland-protcols v2] unstable: add xdg-toplevel-decoration protocol
On March 3, 2018 12:14 PM, Quentin Glidic wrote: > On 3/2/18 4:33 PM, Simon Ser wrote: > > This adds a new protocol to negotiate server- and client-side rendering of > > window decorations for xdg-toplevels. This allows compositors that want > > to draw decorations themselves to send their preference to clients, and > > clients that prefer server-side decorations to request them. > > > > This is inspired by a protocol from KDE [1] which has been implemented in > > KDE and Sway and was submitted for consideration in 2017 [2]. This patch > > provides an updated protocol with those concerns taken into account. > > > > Signed-off-by: Simon Ser > > Reviewed-by: Drew DeVault > > Reviewed-by: David Edmundson > > Reviewed-by: Alan Griffiths > > Reviewed-by: Tony Crisci > > > > [1] > > https://github.com/KDE/kwayland/blob/master/src/client/protocols/server-decoration.xml > > [2] > > https://lists.freedesktop.org/archives/wayland-devel/2017-October/035564.html > > This is a nice protocol, and I would implement it (in clients) in its > current form, but I still have a few comments. Thanks for your comments! > > --- > > > > This was iterated on privately between representatives of Sway and wlroots > > (Simon Ser, Drew DeVault and Tony Crisci), KDE and Qt (David Edmundson), > > and Mir (Alan Griffiths). > > > > A proof-of-concept of a client and server implementation is available at > > [1]. > > > > Changes from v1 to v2: moved the enum above in the protocol, added > > Signed-off-by and Reviewed-by tags, updated the commit message. > > > > [1] https://github.com/swaywm/wlroots/pull/638 > > > > Makefile.am| 1 + > > unstable/xdg-toplevel-decoration/README| 4 + > > .../xdg-toplevel-decoration-unstable-v1.xml| 127 > > + > > 3 files changed, 132 insertions(+) > > create mode 100644 unstable/xdg-toplevel-decoration/README > > create mode 100644 > > unstable/xdg-toplevel-decoration/xdg-toplevel-decoration-unstable-v1.xml > > > > diff --git a/Makefile.am b/Makefile.am > > index 4b9a901..07744e9 100644 > > --- a/Makefile.am > > +++ b/Makefile.am > > @@ -17,6 +17,7 @@ unstable_protocols = > > \ > > > > unstable/keyboard-shortcuts-inhibit/keyboard-shortcuts-inhibit-unstable-v1.xml > > \ > > unstable/xdg-output/xdg-output-unstable-v1.xml > > \ > > unstable/input-timestamps/input-timestamps-unstable-v1.xml \ > > + > > unstable/xdg-toplevel-decoration/xdg-toplevel-decoration-unstable-v1.xml > > \ > > $(NULL) > > > > stable_protocols = > > \ > > diff --git a/unstable/xdg-toplevel-decoration/README > > b/unstable/xdg-toplevel-decoration/README > > new file mode 100644 > > index 000..e927110 > > --- /dev/null > > +++ b/unstable/xdg-toplevel-decoration/README > > @@ -0,0 +1,4 @@ > > +xdg_toplevel_decoration protocol > > + > > +Maintainers: > > +Simon Ser > > diff --git > > a/unstable/xdg-toplevel-decoration/xdg-toplevel-decoration-unstable-v1.xml > > b/unstable/xdg-toplevel-decoration/xdg-toplevel-decoration-unstable-v1.xml > > new file mode 100644 > > index 000..acc1ed2 > > --- /dev/null > > +++ > > b/unstable/xdg-toplevel-decoration/xdg-toplevel-decoration-unstable-v1.xml > > @@ -0,0 +1,127 @@ > > + > > + > > + > > +Copyright © 2018 Simon Ser > > + > > +Permission is hereby granted, free of charge, to any person obtaining a > > +copy of this software and associated documentation files (the > > "Software"), > > +to deal in the Software without restriction, including without > > limitation > > +the rights to use, copy, modify, merge, publish, distribute, > > sublicense, > > +and/or sell copies of the Software, and to permit persons to whom the > > +Software is furnished to do so, subject to the following conditions: > > + > > +The above copyright notice and this permission notice (including the > > next > > +paragraph) shall be included in all copies or substantial portions of > > the > > +Software. > > + > > +THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, > > EXPRESS OR > > +IMPLIED, INCLUDI
Re: [PATCH wayland-protcols v2] unstable: add xdg-toplevel-decoration protocol
‐‐‐ Original Message ‐‐‐ On March 11, 2018 10:17 PM, Quentin Glidic wrote: > > > > > > Last but not least: it should be much much clearer that the compositor > > > is in charge here. This is not about magic SSD, clients must support CSD > > > in all cases and should not error out if this global is not here. And > > > even then, it may want CSD in some cases. > > > > I've added this in the protocol description: > > > > > Note that even if the server supports server-side window decorations, > > > clients > > > must still support client-side decorations. > > I think people already got that part, though it does no harm to say it > again, but I was speaking about the configure event. It may happen atany time > and the client must be prepared (e.g for the cases you mentioned). Right. Added: A configure event can be sent at any time, not necessarily in reply to a set_mode request. Sending a v3 now. > Cheers, > > > - > > Quentin “Sardem FF7” Glidic > > 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-protcols v3] unstable: add xdg-toplevel-decoration protocol
This adds a new protocol to negotiate server- and client-side rendering of window decorations for xdg-toplevels. This allows compositors that want to draw decorations themselves to send their preference to clients, and clients that prefer server-side decorations to request them. This is inspired by a protocol from KDE [1] which has been implemented in KDE and Sway and was submitted for consideration in 2017 [2]. This patch provides an updated protocol with those concerns taken into account. Signed-off-by: Simon Ser Reviewed-by: Drew DeVault Reviewed-by: David Edmundson Reviewed-by: Alan Griffiths Reviewed-by: Tony Crisci [1] https://github.com/KDE/kwayland/blob/master/src/client/protocols/server-decoration.xml [2] https://lists.freedesktop.org/archives/wayland-devel/2017-October/035564.html --- This was iterated on privately between representatives of Sway and wlroots (Simon Ser, Drew DeVault and Tony Crisci), KDE and Qt (David Edmundson), and Mir (Alan Griffiths). A proof-of-concept of a client and server implementation is available at [1]. Changes from v2 to v3: fix typos, clarify xdg_toplevel_decoration.destroy semantics, clarify that clients always need to support CSD and can receive configure events at any time. [1] https://github.com/swaywm/wlroots/pull/638 Makefile.am| 1 + unstable/xdg-toplevel-decoration/README| 4 + .../xdg-toplevel-decoration-unstable-v1.xml| 132 + 3 files changed, 137 insertions(+) create mode 100644 unstable/xdg-toplevel-decoration/README create mode 100644 unstable/xdg-toplevel-decoration/xdg-toplevel-decoration-unstable-v1.xml diff --git a/Makefile.am b/Makefile.am index 4b9a901..07744e9 100644 --- a/Makefile.am +++ b/Makefile.am @@ -17,6 +17,7 @@ unstable_protocols = \ unstable/keyboard-shortcuts-inhibit/keyboard-shortcuts-inhibit-unstable-v1.xml \ unstable/xdg-output/xdg-output-unstable-v1.xml \ unstable/input-timestamps/input-timestamps-unstable-v1.xml \ + unstable/xdg-toplevel-decoration/xdg-toplevel-decoration-unstable-v1.xml \ $(NULL) stable_protocols = \ diff --git a/unstable/xdg-toplevel-decoration/README b/unstable/xdg-toplevel-decoration/README new file mode 100644 index 000..e927110 --- /dev/null +++ b/unstable/xdg-toplevel-decoration/README @@ -0,0 +1,4 @@ +xdg_toplevel_decoration protocol + +Maintainers: +Simon Ser diff --git a/unstable/xdg-toplevel-decoration/xdg-toplevel-decoration-unstable-v1.xml b/unstable/xdg-toplevel-decoration/xdg-toplevel-decoration-unstable-v1.xml new file mode 100644 index 000..a34cb73 --- /dev/null +++ b/unstable/xdg-toplevel-decoration/xdg-toplevel-decoration-unstable-v1.xml @@ -0,0 +1,132 @@ + + + +Copyright © 2018 Simon Ser + +Permission is hereby granted, free of charge, to any person obtaining a +copy of this software and associated documentation files (the "Software"), +to deal in the Software without restriction, including without limitation +the rights to use, copy, modify, merge, publish, distribute, sublicense, +and/or sell copies of the Software, and to permit persons to whom the +Software is furnished to do so, subject to the following conditions: + +The above copyright notice and this permission notice (including the next +paragraph) shall be included in all copies or substantial portions of the +Software. + +THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR +IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, +FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL +THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER +LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING +FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER +DEALINGS IN THE SOFTWARE. + + + + + This interface permits choosing between client-side and server-side + window decorations for a toplevel surface. + + A window decoration is a user interface component used to move, resize and + change a window's state. It can be managed either by the client (part of + the surface) or by the server. + + By advertising this interface the server announces support for server-side + window decorations. Note that even if the server supports server-side + window decorations, clients must still support client-side decorations. + + Warning! The protocol described in this file is experimental and + backward incompatible changes may be made. Backward compatible changes + may be added together with the corresponding interface version bump. + Backward incompatible changes are done by b
Re: [PATCH wayland-protcols v3] unstable: add xdg-toplevel-decoration protocol
On March 14, 2018 10:22 AM, Peter Hutterer wrote: > sorry about the delay, but better late than too late ;) No problem, thanks for your review! > On Sun, Mar 11, 2018 at 05:53:42PM -0400, Simon Ser wrote: > > This adds a new protocol to negotiate server- and client-side rendering of > > window decorations for xdg-toplevels. This allows compositors that want > > to draw decorations themselves to send their preference to clients, and > > clients that prefer server-side decorations to request them. > > > > This is inspired by a protocol from KDE [1] which has been implemented in > > KDE and Sway and was submitted for consideration in 2017 [2]. This patch > > provides an updated protocol with those concerns taken into account. > > > > Signed-off-by: Simon Ser > > Reviewed-by: Drew DeVault > > Reviewed-by: David Edmundson > > Reviewed-by: Alan Griffiths > > Reviewed-by: Tony Crisci > > > > [1] > > https://github.com/KDE/kwayland/blob/master/src/client/protocols/server-decoration.xml > > [2] > > https://lists.freedesktop.org/archives/wayland-devel/2017-October/035564.html > > --- > > > > This was iterated on privately between representatives of Sway and wlroots > > (Simon Ser, Drew DeVault and Tony Crisci), KDE and Qt (David Edmundson), > > and Mir (Alan Griffiths). > > > > A proof-of-concept of a client and server implementation is available at > > [1]. > > > > Changes from v2 to v3: fix typos, clarify xdg_toplevel_decoration.destroy > > semantics, clarify that clients always need to support CSD and can receive > > configure events at any time. > > > > [1] https://github.com/swaywm/wlroots/pull/638 > > > > Makefile.am| 1 + > > unstable/xdg-toplevel-decoration/README| 4 + > > .../xdg-toplevel-decoration-unstable-v1.xml| 132 > > + > > 3 files changed, 137 insertions(+) > > create mode 100644 unstable/xdg-toplevel-decoration/README > > create mode 100644 > > unstable/xdg-toplevel-decoration/xdg-toplevel-decoration-unstable-v1.xml > > > > diff --git a/Makefile.am b/Makefile.am > > index 4b9a901..07744e9 100644 > > --- a/Makefile.am > > +++ b/Makefile.am > > @@ -17,6 +17,7 @@ unstable_protocols = > > \ > > > > unstable/keyboard-shortcuts-inhibit/keyboard-shortcuts-inhibit-unstable-v1.xml > > \ > > unstable/xdg-output/xdg-output-unstable-v1.xml > > \ > > unstable/input-timestamps/input-timestamps-unstable-v1.xml \ > > + > > unstable/xdg-toplevel-decoration/xdg-toplevel-decoration-unstable-v1.xml > > \ > > $(NULL) > > > > stable_protocols = > > \ > > diff --git a/unstable/xdg-toplevel-decoration/README > > b/unstable/xdg-toplevel-decoration/README > > new file mode 100644 > > index 000..e927110 > > --- /dev/null > > +++ b/unstable/xdg-toplevel-decoration/README > > @@ -0,0 +1,4 @@ > > +xdg_toplevel_decoration protocol > > + > > +Maintainers: > > +Simon Ser > > diff --git > > a/unstable/xdg-toplevel-decoration/xdg-toplevel-decoration-unstable-v1.xml > > b/unstable/xdg-toplevel-decoration/xdg-toplevel-decoration-unstable-v1.xml > > new file mode 100644 > > index 000..a34cb73 > > --- /dev/null > > +++ > > b/unstable/xdg-toplevel-decoration/xdg-toplevel-decoration-unstable-v1.xml > > @@ -0,0 +1,132 @@ > > + > > + > > + > > +Copyright © 2018 Simon Ser > > + > > +Permission is hereby granted, free of charge, to any person obtaining a > > +copy of this software and associated documentation files (the > > "Software"), > > +to deal in the Software without restriction, including without > > limitation > > +the rights to use, copy, modify, merge, publish, distribute, > > sublicense, > > +and/or sell copies of the Software, and to permit persons to whom the > > +Software is furnished to do so, subject to the following conditions: > > + > > +The above copyright notice and this permission notice (including the > > next > > +paragraph) shall be included in all copies or substantial portions of > > the > > +Software. > > + > > +THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, > > EXPRESS OR > > +IMPLIED, INCLUDI
Re: [PATCH wayland-protcols v3] unstable: add xdg-toplevel-decoration protocol
On March 14, 2018 7:33 PM, Drew DeVault wrote:
> On 2018-03-14 6:41 AM, Simon Ser wrote:
> > > Since we assume CSD by default, this implies that any client must be able
> > > to
> > > do CSD, which should be explicitly stated here.
> >
> > It's already stated in the protocol description ("Note that even if
> > the server supports server-side window decorations, clients must still
> > support client-side decorations"). Is it necessary to write it one
> > more time here?
>
> I don't think this is right. The protocol has nothing to say at all
> about decorations, client side or not. A Wayland surface without CSD is
> a valid Wayland surface on any compositor. I don't think we need to
> explicitly require clients to handle CSD for that reason.
You're right, xdg-shell does mention client-side decorations, but never makes
them mandatory. Clients not having decorations can use xdg-toplevel.
However, the situation we'd like to avoid is clients wanting decorations not
implementing CSD at all and relying on this protocol to show them via SSD. What
about rewording this sentence to:
Note that even if the server supports server-side window decorations, clients
having decorations must still support client-side decorations.
> The assumption is that the compositor implementing this protocol will
> support both.
>
> --
> Drew DeVault
---
Simon Ser
https://emersion.fr
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland-protcols v2] unstable: add xdg-toplevel-decoration protocol
On March 15, 2018 4:15 PM, Emil Velikov wrote: > On 2 March 2018 at 15:33, Simon Ser wrote: > > This adds a new protocol to negotiate server- and client-side rendering of > > window decorations for xdg-toplevels. This allows compositors that want > > to draw decorations themselves to send their preference to clients, and > > clients that prefer server-side decorations to request them. > > > > This is inspired by a protocol from KDE [1] which has been implemented in > > KDE and Sway and was submitted for consideration in 2017 [2]. This patch > > provides an updated protocol with those concerns taken into account. > > > > Signed-off-by: Simon Ser > > Reviewed-by: Drew DeVault > > Reviewed-by: David Edmundson > > Reviewed-by: Alan Griffiths > > Reviewed-by: Tony Crisci > > > More of a fly-by comment. > > Having a quick look does not list any of these R-B tags making it to the list. > Was it done in private, or I failed at searching? Yeah, it was done prior to submission to wayland-devel. See the commentary below the commit message: > This was iterated on privately between representatives of Sway and wlroots > (Simon Ser, Drew DeVault and Tony Crisci), KDE and Qt (David Edmundson), and > Mir (Alan Griffiths). > If the former - it's very concerning practise. > > -Emil ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland-protcols v3] unstable: add xdg-toplevel-decoration protocol
On March 16, 2018 1:22 PM, Pekka Paalanen wrote: > > > I'm missing a comment that describes what happens if the xdg_toplevel is > > > destroyed. There is some object dependency here that needs to be stated. > > > Do > > > we need an event here? Or are we assuming that clients are smart enough to > > > keep track of destroy events. Either way - needs to be explicitly stated. > > > > > > > What about requiring clients to destroy the zxdg_toplevel_decoration_v1 > > before > > the xdg_toplevel? > > Hi, > > you can, but then you need an error code for clients that get it wrong. > > A common convention is to instead say that zxdg_toplevel_decoration_v1 > becomes "inert" when the associated xdg_toplevel is destroyed. It means > the object will not send any events, and all requests except destroy > will be ignored. This approach is often used with racy cases where > requiring a single order of actions is not possible, and it comes with > the disadvantage of needing to define what happens if you pass an inert > object of this type as an argument in some other interface, or if the > inert object had requests that create more objects. Thanks for the explanation! > Both ways are possible. You may want to check how xdg_toplevel deals > with xdg_surface destruction and how xdg_surface deals with wl_surface > destruction. Maybe consistency would be the best plan? The protocol states that: "An xdg_surface must only be destroyed after its role object has been destroyed". But it doesn't define any error type for protocol violations. I didn't find anything about the relationship between xdg_surface and xdg_surface. So I'm not sure what to do to be consistent with xdg-shell. The options are: - Become inert - Send an error on the decoration object - Automatically destroying the decoration when the toplevel is destroyed? I'll just go with becoming inert for now. Let me know what you think. > Thanks, > pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland-protcols v3] unstable: add xdg-toplevel-decoration protocol
On March 22, 2018 6:37 AM, Peter Hutterer wrote: > so, random thought: instead of talking about decorations or not (which isn't > what we really care about) talk about window management and who does it. I think we really do mean "decorations" and not "window management". Decorations are used for window management, but their scope is larger - they are also user interface components. For instance, I can think of GNOME [1] and elementary OS' [2] dialogs, which do have decorations (rounded corners, shadows) but for which decorations cannot be used for window management operations (they are purely aesthetic). So the client drawing these dialogs and not using SSDs doesn't provide any window management operation widget, but at the same time draws decorations. Such a client using SSDs (via the decoration protocol) probably shouldn't draw rounded corners nor shadows. That's why I think using the "SSD/no SSD" vocabulary is more accurate. What do you think? [1] https://developer.gnome.org/hig/stable/dialogs.html.en#message-dialogs [2] https://elementary.io/docs/human-interface-guidelines#dialogs --- Simon Ser https://emersion.fr ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland-protcols v3] unstable: add xdg-toplevel-decoration protocol
On March 22, 2018 2:39 PM, Simon McVittie wrote: > Those dialogs still have all the window-management operation widgets that > the application designer wants them to have - that just happens to mean > "none" in this case. > > Contrast with the same dialogs in a SSD environment, where they get all > the window-management operation widgets that the *window manager* > designer wants them to have (which might be different). What I want to say is that in SSD mode, requiring clients not to draw window management widgets allows them to draw decorations not useful for window management such as shadows and rounded corners, which is not what we want. Meanwhile, requiring clients not to draw decorations in SSD mode prevents them from drawing these and is really what we want. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH wayland-protocols v4] unstable: add xdg-toplevel-decoration protocol
This adds a new protocol to negotiate server-side rendering of window decorations for xdg-toplevels. This allows compositors that want to draw decorations themselves to send their preference to clients, and clients that prefer server-side decorations to request them. This is inspired by a protocol from KDE [1] which has been implemented in KDE and Sway and was submitted for consideration in 2017 [2]. This patch provides an updated protocol with those concerns taken into account. Signed-off-by: Simon Ser Reviewed-by: Drew DeVault Reviewed-by: David Edmundson Reviewed-by: Alan Griffiths Reviewed-by: Tony Crisci [1] https://github.com/KDE/kwayland/blob/master/src/client/protocols/server-decoration.xml [2] https://lists.freedesktop.org/archives/wayland-devel/2017-October/035564.html --- This was iterated on privately between representatives of Sway and wlroots (Simon Ser, Drew DeVault and Tony Crisci), KDE and Qt (David Edmundson), and Mir (Alan Griffiths). A proof-of-concept of a client and server implementation is available at [1]. Changes from v3 to v4: - Updated the definition of decorations to remove unnecessary constraints (Eike) - Fix ambiguity in zxdg_toplevel_decoration_v1 description (Peter) - Specify that the decoration object must be destroyed before the toplevel (Pekka, Peter) - Changed decoration mode enum to "client_side" and "server_side" (Peter) - Replaced "server" with "compositor" in preferred_mode event description (Peter) - State that the mode sent by the compositor with the configure event must be obeyed (Peter) - Reword client-side decorations description (Eike) [1] https://github.com/swaywm/wlroots/pull/638 Makefile.am| 1 + unstable/xdg-toplevel-decoration/README| 4 + .../xdg-toplevel-decoration-unstable-v1.xml| 139 + 3 files changed, 144 insertions(+) create mode 100644 unstable/xdg-toplevel-decoration/README create mode 100644 unstable/xdg-toplevel-decoration/xdg-toplevel-decoration-unstable-v1.xml diff --git a/Makefile.am b/Makefile.am index 4b9a901..07744e9 100644 --- a/Makefile.am +++ b/Makefile.am @@ -17,6 +17,7 @@ unstable_protocols = \ unstable/keyboard-shortcuts-inhibit/keyboard-shortcuts-inhibit-unstable-v1.xml \ unstable/xdg-output/xdg-output-unstable-v1.xml \ unstable/input-timestamps/input-timestamps-unstable-v1.xml \ + unstable/xdg-toplevel-decoration/xdg-toplevel-decoration-unstable-v1.xml \ $(NULL) stable_protocols = \ diff --git a/unstable/xdg-toplevel-decoration/README b/unstable/xdg-toplevel-decoration/README new file mode 100644 index 000..e927110 --- /dev/null +++ b/unstable/xdg-toplevel-decoration/README @@ -0,0 +1,4 @@ +xdg_toplevel_decoration protocol + +Maintainers: +Simon Ser diff --git a/unstable/xdg-toplevel-decoration/xdg-toplevel-decoration-unstable-v1.xml b/unstable/xdg-toplevel-decoration/xdg-toplevel-decoration-unstable-v1.xml new file mode 100644 index 000..8fbc688 --- /dev/null +++ b/unstable/xdg-toplevel-decoration/xdg-toplevel-decoration-unstable-v1.xml @@ -0,0 +1,139 @@ + + + +Copyright © 2018 Simon Ser + +Permission is hereby granted, free of charge, to any person obtaining a +copy of this software and associated documentation files (the "Software"), +to deal in the Software without restriction, including without limitation +the rights to use, copy, modify, merge, publish, distribute, sublicense, +and/or sell copies of the Software, and to permit persons to whom the +Software is furnished to do so, subject to the following conditions: + +The above copyright notice and this permission notice (including the next +paragraph) shall be included in all copies or substantial portions of the +Software. + +THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR +IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, +FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL +THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER +LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING +FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER +DEALINGS IN THE SOFTWARE. + + + + + This interface allows a compositor to announce support for server-side + decorations and optionally express a preference for using them. + + A window decoration is a set of window controls as deemed appropriate by + the party managing them, such as user interface components used to move, + resize and change a window's state. + + A client can use this protocol to request being decorated by a suppo
Re: [PATCH v2 2/3] server: Add special case destroy signal emitter
> In the past much code (weston, efl/enlightenment, mutter) has
> freed structures containing wl_listeners from destroy handlers
> without first removing the listener from the signal. As the
> destroy notifier only fires once, this has largely gone
> unnoticed until recently.
>
> Other code does not (Qt, wlroots) - and removes itself from
> the signal before free.
>
> If somehow a destroy signal is listened to by code from both
> kinds of callers, those that free will corrupt the lists for
> those that don't, and Bad Things will happen.
>
> To avoid these bad things, remove every item from the signal list
> during destroy emit, and put it in a list all its own. This way
> whether the listener is removed or not has no impact on the
> following emits.
>
> Signed-off-by: Derek Foreman
Thanks for looking into this, I think it's a great idea to add this behaviour to
the ABI. This patch LGTM.
Reviewed-by: Simon Ser
> ---
>
> Changes since v1:
> In v1 I went through some ugly steps to ensure wl_priv_signal_get()
> worked. It seems this is actually a useless requirement, and the
> code is prettier without it.
>
> src/wayland-private.h | 3 +++
> src/wayland-server.c | 46 +++---
> 2 files changed, 46 insertions(+), 3 deletions(-)
>
> diff --git a/src/wayland-private.h b/src/wayland-private.h
> index 12b9032..29516ec 100644
> --- a/src/wayland-private.h
> +++ b/src/wayland-private.h
> @@ -253,6 +253,9 @@ wl_priv_signal_get(struct wl_priv_signal *signal,
> wl_notify_func_t notify);
> void
> wl_priv_signal_emit(struct wl_priv_signal *signal, void *data);
>
> +void
> +wl_priv_signal_final_emit(struct wl_priv_signal *signal, void *data);
> +
> void
> wl_connection_close_fds_in(struct wl_connection *connection, int max);
>
> diff --git a/src/wayland-server.c b/src/wayland-server.c
> index eb1e500..8c3b800 100644
> --- a/src/wayland-server.c
> +++ b/src/wayland-server.c
> @@ -682,7 +682,7 @@ destroy_resource(void *element, void *data, uint32_t
> flags)
> /* Don't emit the new signal for deprecated resources, as that would
>* access memory outside the bounds of the deprecated struct */
> if (!resource_is_deprecated(resource))
> - wl_priv_signal_emit(&resource->destroy_signal, resource);
> + wl_priv_signal_final_emit(&resource->destroy_signal, resource);
>
> if (resource->destroy)
> resource->destroy(resource);
> @@ -841,7 +841,7 @@ wl_client_destroy(struct wl_client *client)
> {
> uint32_t serial = 0;
>
> - wl_priv_signal_emit(&client->destroy_signal, client);
> + wl_priv_signal_final_emit(&client->destroy_signal, client);
>
> wl_client_flush(client);
> wl_map_for_each(&client->objects, destroy_resource, &serial);
> @@ -1089,7 +1089,7 @@ wl_display_destroy(struct wl_display *display)
> struct wl_socket *s, *next;
> struct wl_global *global, *gnext;
>
> - wl_priv_signal_emit(&display->destroy_signal, display);
> + wl_priv_signal_final_emit(&display->destroy_signal, display);
>
> wl_list_for_each_safe(s, next, &display->socket_list, link) {
> wl_socket_destroy(s);
> @@ -2025,6 +2025,46 @@ wl_priv_signal_emit(struct wl_priv_signal *signal,
> void *data)
> }
> }
>
> +/** Emit the signal for the last time, calling all the installed listeners
> + *
> + * Iterate over all the listeners added to this \a signal and call
> + * their \a notify function pointer, passing on the given \a data.
> + * Removing or adding a listener from within wl_priv_signal_emit()
> + * is safe, as is freeing the structure containing the listener.
> + *
> + * A large body of external code assumes it's ok to free a destruction
> + * listener without removing that listener from the list. Mixing code
> + * that acts like this and code that doesn't will result in list
> + * corruption.
> + *
> + * We resolve this by removing each item from the list and isolating it
> + * in another list. We discard it completely after firing the notifier.
> + * This should allow interoperability between code that unlinks its
> + * destruction listeners and code that just frees structures they're in.
> + *
> + */
> +void
> +wl_priv_signal_final_emit(struct wl_priv_signal *signal, void *data)
> +{
> + struct wl_listener *l;
> + struct wl_list *pos;
> +
> + /* During a destructor notifier isolate every list item before
> + * notifying. This renders harmless the long standing misuse
> + * of f
Re: [PATCH wayland-protocols v4] unstable: add xdg-toplevel-decoration protocol
(Re-sending the message because I forgot to reply to the list) On April 13, 2018 2:56 PM, Jonas Ådahl wrote: > Another thing to consider is whether non-toplevels ever want a similar > kind of protocol? It is not something we need to go into much further > details now, but it would be easy to add into this protocol by just > renaming the directory under unstable/ and the XML file to > "xdg-decorations" or something. Would we have another type of surface > that needs similar functionality, we could add that as a separate pair > of interfaces. I'm not sure it's a good idea to add decorations to non-toplevel surfaces. I can't think of a use-case for popups. We don't know yet what kind of xdg-surface will be added later, so I think we can't really design a protocol that would work for this unknown use-case and we'd better create a new protocol instead. > Is this the consensus as well? Because if it should be possible, there > are those things I mentioned to consider regarding capabilities. A > potential mode could for example be to outsource drawing shadow or > something. As Drew, I think the complexity isn't worth it. Compositors wanting to draw shadows around clients will get into more issues (e.g. getting the shape of the window). > Ignoring that for a bit, I guess the reason for allowing the compositor > to disregard the set mode to be that a client might not know whether > request ssd or csd? Especially in the example you gave above. Then what > is the purpose of the set_mode request at all? The set_mode request allows the client to communicate its preference, but still allow the compositor to override it. For instance, a GTK+ client with a titlebar containing widgets might prefer CSD, but could still accept to use SSD by turning the titlebar into a toolbar. That would work well in tiling compositors when moving a window between a tiled container and a floating container: the compositor could accept the set_mode request in floating mode and enforce SSD in tiled mode. We could imagine another compositor letting clients decorate themselves if they want to in tiled mode, in which case the compositor would send preferred_mode events when switching between tiled and floating containers. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCHv4] Add name event to xdg-output
On April 18, 2018 9:57 AM, Jonas Ådahl wrote: > Replying to both Pekka and Drew at the same time here: > > On Mon, Apr 16, 2018 at 11:14:51AM -0400, Drew DeVault wrote: > > On 2018-04-16 2:57 PM, Jonas Ådahl wrote: > > > I'd still like a bit more clarification about what to expect of this > > > string. What I'm trying to avoid is one compositor sending "eDP-1" while > > > another sends "Built-in Display". For example, the first is suitable for > > > command line interfaces (e.g. movie-player --fullscreen-on HDMI-2), but > > > the second is suitable for GUI's (e.g. a widget for selecting what > > > monitor to play a movie on). If it can be either one, I don't see its > > > usefulness in a generic client. > > > > I'm explicitly not trying to avoid that. To me it's acceptable that one > > compositor uses "eDP-1" and another uses "Built-in Display". > > I'd be more fine if the expectation was clear that the string is > suitable for a graphical user interface and not as a keyword in a > command line or something similar. > > […] > > Because it may result in unnecessary inconveniences and bugs. If > "console-movie-player" starts using a "human readable description" as a > command > line argument because it's unclear what to expect from it, but > gnome-shell provides a descriptive string that may very well change, > that is localized etc, it's suddenly very unsuitable for how it the use > case the "consolemovie-player" intended to use it for. > > Another thing to note is that a human readable description ala "Built-in > Display" or "Dell HD123456 24"" may not even be unique. I agree with Jonas here. Maybe we could add two fields: - "codename", restricted to alphanumeric + hyphens characters (to reflect the current informal practice to name outputs like "VGA-1"), specified to be unique and persistent. These could be used in configuration files. - "description", specified to be human-readable and not necessarily unique. These could be used in user interfaces. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland-protocols v4] unstable: add xdg-toplevel-decoration protocol
On April 18, 2018 10:28 AM, Jonas Ådahl wrote: > > I'm not sure it's a good idea to add decorations to non-toplevel surfaces. I > > can't think of a use-case for popups. We don't know yet what kind of > > xdg-surface will be added later, so I think we can't really design a > > protocol > > that would work for this unknown use-case and we'd better create a new > > protocol > > instead. > > That's not what I suggested. I just suggested to make room for potential > future xdg_surface based surface types by renaming a directory and a > file. We should indeed not bother with adding any more complexity to > popups and not-yet-thought-of surface types. Oh, sorry, I thought you wanted to allow clients to create xdg-decoration objects for arbitrary xdg-surfaces. What you said makes much more sense now: it will just allow to add new interfaces to the protocol for future xdg-surfaces. Yeah, I'm definitely on board with that. > While I don't think it makes sense to do this in GTK+ (we can't just > mess around with applications widget trees however we want) but I can > accept that it may be a theoretical possibility for a theoretical > toolkit. You could also decide to style the titlebar differently, for instance hiding the window title and reducing padding. But of course all of this is up to the client. > How do you imagine avoiding state transitions that don't result in > incorrect intermediate state? If a compositor changes the preferred > mode, does it wait some arbitrary time to see if client replies with a > new set_mode request? Or how else would one avoid sending a new > configuration given the changed tiled-ness without knowing what the > client prefers? I don't think "wait[ing] some arbitrary time" is an acceptable behaviour. Instead, I think the compositor has two choices: - Either it decides to respect the client's choice (because it allows both CSD and SSD in this situation), in which case it just sends preferred_mode and lets the client send (or do not send) a set_mode request. - Either it decides to enforce a particular mode (because it only allows for one mode in this situation), in which case it just sends configure. This "I want to know the client's preferred mode before I decide if I force one mode or let the client choose" behaviour is a little weird. > Wouldn't it be better to have actual clients that'd actually use this > part of the protocol before writing it down? We could still move forward > with a vastly simpler protocol without the set_mode and set_preferred, > and just have the mode enum and configure (so that the compositor can > switch between csd and ssd when tiling/untiling or whatever) that works > with the all available clients we have today. We could always do this and add preferred_mode & set_mode later. Note that the current test client uses this part of the protocol (it can be configured to use the compositor's preferred mode or use its own preferred mode), but it's just a test client. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland-protocols v4] unstable: add xdg-toplevel-decoration protocol
On April 18, 2018 1:05 PM, Jonas Ådahl wrote: > Since the issue is more of a race condition kind of issue, it might not > be easily reproducable with a demo client, but must be solved by coming > up with a type of negotiation that doesn't result in incorrect > intermediate states for example the one described above. > > A race free protocol is what we need though, to continue with the "every > frame is perfect" concept we are striving for. I see where you're getting at and agree with you. I can think of a fix which would make it mandatory for clients to issue a set_mode request after receiving a preferred_mode event. A serial is probably needed for this. What do you think? Like you said, it's probably better to take preferred_mode/set_mode out of the protocol for now, move forward and add them later (making sure there's no race). I'll send a v5 with the renaming and the simplification. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH wayland-protocols v5] unstable: add xdg-decoration protocol
This adds a new protocol to negotiate server-side rendering of window decorations for xdg-toplevels. This allows compositors that want to draw decorations themselves to send their preference to clients, and clients that prefer server-side decorations to request them. This is inspired by a protocol from KDE [1] which has been implemented in KDE and Sway and was submitted for consideration in 2017 [2]. This patch provides an updated protocol with those concerns taken into account. Signed-off-by: Simon Ser Reviewed-by: Drew DeVault Reviewed-by: David Edmundson Reviewed-by: Alan Griffiths Reviewed-by: Tony Crisci Reviewed-by: Eike Hein [1] https://github.com/KDE/kwayland/blob/master/src/client/protocols/server-decoration.xml [2] https://lists.freedesktop.org/archives/wayland-devel/2017-October/035564.html --- This was iterated on privately between representatives of Sway and wlroots (Simon Ser, Drew DeVault and Tony Crisci), KDE and Qt (David Edmundson), and Mir (Alan Griffiths). A proof-of-concept of a client and server implementation is available at [1]. Changes from v4 to v5: - Renamed the protocol to xdg-decoration for future extensions (Jonas) - Removed the preferred_mode event and the set_mode request for now because of a race (Jonas) [1] https://github.com/swaywm/wlroots/pull/638 Makefile.am | 1 + unstable/xdg-decoration/README| 4 + .../xdg-decoration-unstable-v1.xml| 115 ++ 3 files changed, 120 insertions(+) create mode 100644 unstable/xdg-decoration/README create mode 100644 unstable/xdg-decoration/xdg-decoration-unstable-v1.xml diff --git a/Makefile.am b/Makefile.am index 4b9a901..71909d8 100644 --- a/Makefile.am +++ b/Makefile.am @@ -17,6 +17,7 @@ unstable_protocols = \ unstable/keyboard-shortcuts-inhibit/keyboard-shortcuts-inhibit-unstable-v1.xml \ unstable/xdg-output/xdg-output-unstable-v1.xml \ unstable/input-timestamps/input-timestamps-unstable-v1.xml \ + unstable/xdg-decoration/xdg-decoration-unstable-v1.xml \ $(NULL) stable_protocols = \ diff --git a/unstable/xdg-decoration/README b/unstable/xdg-decoration/README new file mode 100644 index 000..e927110 --- /dev/null +++ b/unstable/xdg-decoration/README @@ -0,0 +1,4 @@ +xdg_toplevel_decoration protocol + +Maintainers: +Simon Ser diff --git a/unstable/xdg-decoration/xdg-decoration-unstable-v1.xml b/unstable/xdg-decoration/xdg-decoration-unstable-v1.xml new file mode 100644 index 000..935f1f5 --- /dev/null +++ b/unstable/xdg-decoration/xdg-decoration-unstable-v1.xml @@ -0,0 +1,115 @@ + + + +Copyright © 2018 Simon Ser + +Permission is hereby granted, free of charge, to any person obtaining a +copy of this software and associated documentation files (the "Software"), +to deal in the Software without restriction, including without limitation +the rights to use, copy, modify, merge, publish, distribute, sublicense, +and/or sell copies of the Software, and to permit persons to whom the +Software is furnished to do so, subject to the following conditions: + +The above copyright notice and this permission notice (including the next +paragraph) shall be included in all copies or substantial portions of the +Software. + +THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR +IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, +FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL +THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER +LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING +FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER +DEALINGS IN THE SOFTWARE. + + + + + This interface allows a compositor to announce support for server-side + decorations and optionally express a preference for using them. + + A window decoration is a set of window controls as deemed appropriate by + the party managing them, such as user interface components used to move, + resize and change a window's state. + + A client can use this protocol to request being decorated by a supporting + compositor. + + If compositor and client do not negotiate the use of a server-side + decoration using this protocol, clients continue to self-decorate as they + see fit. + + Warning! The protocol described in this file is experimental and + backward incompatible changes may be made. Backward compatible changes + may be added together with the corresponding interface version bump. + Backward incompatible changes are done by bumping the version number in + the protocol and interface names an
Referencing enums in other protocols
Hi all, While writing a protocol, I've been trying to reference symbols from another protocol. While it seems to work fine for interfaces, it fails for enums: error: could not find enumeration wl_output.transform Is this by design? It seems odd to me that interfaces work but enums don't. Thanks, --- Simon Ser https://emersion.fr ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 1/2] weston-info: Add support for tablet-unstable-v2
On April 24, 2018 8:31 AM, wrote:
> From: Markus Ongyerth
>
> This now prints each tablet seat with at least one tablet/pad/tool
> attached.
> For each tablet seat, each tablet, pad and tool is printed with as much
> detail about the device as the protocol provides.
> Seat info is stored to be referenced, because the protocol requires to
> request a tablet_seat for each wl_seat and it's not guaranteed that the
> tablet_v2_manager is available when seats are advertised.
>
> Signed-off-by: Markus Ongyerth
Overall LGTM.
> ---
> Makefile.am | 14 +-
> clients/weston-info.c | 844 ++
> 2 files changed, 853 insertions(+), 5 deletions(-)
>
> diff --git a/Makefile.am b/Makefile.am
> index 69ca6cba..ac0f5471 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -824,11 +824,13 @@ weston_simple_im_CFLAGS = $(AM_CFLAGS) $(CLIENT_CFLAGS)
> weston_info_SOURCES =\
> clients/weston-info.c \
> shared/helpers.h
> -nodist_weston_info_SOURCES = \
> - protocol/presentation-time-protocol.c \
> - protocol/presentation-time-client-protocol.h\
> - protocol/linux-dmabuf-unstable-v1-protocol.c\
> - protocol/linux-dmabuf-unstable-v1-client-protocol.h
> +nodist_weston_info_SOURCES = \
> + protocol/presentation-time-protocol.c \
> + protocol/presentation-time-client-protocol.h\
> + protocol/linux-dmabuf-unstable-v1-protocol.c\
> + protocol/linux-dmabuf-unstable-v1-client-protocol.h \
> + protocol/tablet-unstable-v2-protocol.c \
> + protocol/tablet-unstable-v2-client-protocol.h
> weston_info_LDADD = $(WESTON_INFO_LIBS) libshared.la
> weston_info_CFLAGS = $(AM_CFLAGS) $(CLIENT_CFLAGS)
>
> @@ -888,6 +890,8 @@ BUILT_SOURCES += \
> protocol/ivi-application-client-protocol.h \
> protocol/linux-dmabuf-unstable-v1-protocol.c\
> protocol/linux-dmabuf-unstable-v1-client-protocol.h \
> + protocol/tablet-unstable-v2-protocol.c \
> + protocol/tablet-unstable-v2-client-protocol.h \
> protocol/input-timestamps-unstable-v1-protocol.c\
> protocol/input-timestamps-unstable-v1-client-protocol.h
>
> diff --git a/clients/weston-info.c b/clients/weston-info.c
> index 386bd412..7ae6f10b 100644
> --- a/clients/weston-info.c
> +++ b/clients/weston-info.c
> @@ -41,6 +41,7 @@
> #include "shared/zalloc.h"
> #include "presentation-time-client-protocol.h"
> #include "linux-dmabuf-unstable-v1-client-protocol.h"
> +#include "tablet-unstable-v2-client-protocol.h"
>
> typedef void (*print_info_t)(void *info);
> typedef void (*destroy_info_t)(void *info);
> @@ -113,6 +114,7 @@ struct linux_dmabuf_info {
>
> struct seat_info {
> struct global_info global;
> + struct wl_list global_link;
> struct wl_seat *seat;
> struct weston_info *info;
>
> @@ -123,6 +125,75 @@ struct seat_info {
> int32_t repeat_delay;
> };
>
> +struct tablet_v2_path {
> + struct wl_list link;
> + char *path;
> +};
Maybe a wl_array should be used instead?
> +
> +struct tablet_tool_info {
> + struct wl_list link;
> + struct zwp_tablet_tool_v2 *tool;
> +
> + uint64_t hardware_serial;
> + uint64_t hardware_id_wacom;
> + enum zwp_tablet_tool_v2_type type;
> +
> + int tilt;
> + int pressure;
> + int distance;
> + int rotation;
> + int slider;
> + int wheel;
> +};
> +
> +struct tablet_pad_group_info {
> + struct wl_list link;
> + struct zwp_tablet_pad_group_v2 *group;
> +
> + uint32_t modes;
> + size_t button_count;
> + int *buttons;
> + size_t strips;
> + size_t rings;
> +};
> +
> +struct tablet_pad_info {
> + struct wl_list link;
> + struct zwp_tablet_pad_v2 *pad;
> +
> + uint32_t buttons;
> + struct wl_list paths;
> + struct wl_list groups;
> +};
> +
> +struct tablet_info {
> + struct wl_list link;
> + struct zwp_tablet_v2 *tablet;
> +
> + char *name;
> + uint32_t vid, pid;
> + struct wl_list paths;
> +};
> +
> +struct tablet_seat_info {
> + struct wl_list link;
> +
> + struct zwp_tablet_seat_v2 *seat;
> + struct seat_info *seat_info;
> +
> + struct wl_list tablets;
> + struct wl_list tools;
> + struct wl_list pads;
> +};
> +
> +struct tablet_v2_info {
> + struct global_info global;
> + struct zwp_tablet_manager_v2 *manager;
> + struct weston_info *info;
> +
> + struct wl_list seats;
> +};
> +
> struct presentation_info {
> struct global_info global;
> struct wp_presentation *presentation;
> @@ -134,6 +205,9 @@ struct weston_info {
> struct wl_display *display;
> struct wl_registry *registry;
>
> + struct wl_list seats; /
Re: [PATCH wayland-protocols v5] unstable: add xdg-decoration protocol
Hi Jonas, Any news about this trimmed-down version of the protocol? I'll reply to the v4 comments shortly. Best, --- Simon Ser https://emersion.fr ‐‐‐ Original Message ‐‐‐ On April 18, 2018 7:48 PM, Simon Ser wrote: > > > This adds a new protocol to negotiate server-side rendering of window > > decorations for xdg-toplevels. This allows compositors that want to draw > > decorations themselves to send their preference to clients, and clients that > > prefer server-side decorations to request them. > > This is inspired by a protocol from KDE [1] which has been implemented in > > KDE and Sway and was submitted for consideration in 2017 [2]. This patch > > provides an updated protocol with those concerns taken into account. > > Signed-off-by: Simon Ser cont...@emersion.fr > > Reviewed-by: Drew DeVault s...@cmpwn.com > > Reviewed-by: David Edmundson da...@davidedmundson.co.uk > > Reviewed-by: Alan Griffiths alan.griffi...@canonical.com > > Reviewed-by: Tony Crisci t...@dubstepdish.com > > Reviewed-by: Eike Hein h...@kde.org > > [1]https://github.com/KDE/kwayland/blob/master/src/client/protocols/server-decoration.xml > > [2] > https://lists.freedesktop.org/archives/wayland-devel/2017-October/035564.html > > > -------- > > This was iterated on privately between representatives of Sway and wlroots > > (Simon Ser, Drew DeVault and Tony Crisci), KDE and Qt (David Edmundson), and > > Mir (Alan Griffiths). > > A proof-of-concept of a client and server implementation is available at [1]. > > Changes from v4 to v5: > > - Renamed the protocol to xdg-decoration for future extensions (Jonas) > - Removed the preferred_mode event and the set_mode request for now because > > of a race (Jonas) > > [1] https://github.com/swaywm/wlroots/pull/638 > > Makefile.am | 1 + > > unstable/xdg-decoration/README | 4 + > > .../xdg-decoration-unstable-v1.xml | 115 ++ > > 3 files changed, 120 insertions(+) > > create mode 100644 unstable/xdg-decoration/README > > create mode 100644 unstable/xdg-decoration/xdg-decoration-unstable-v1.xml > > diff --git a/Makefile.am b/Makefile.am > > index 4b9a901..71909d8 100644 > > --- a/Makefile.am > > +++ b/Makefile.am > > @@ -17,6 +17,7 @@ unstable_protocols = \ > > > unstable/keyboard-shortcuts-inhibit/keyboard-shortcuts-inhibit-unstable-v1.xml > \ > > unstable/xdg-output/xdg-output-unstable-v1.xml \ > > unstable/input-timestamps/input-timestamps-unstable-v1.xml \ > > > - unstable/xdg-decoration/xdg-decoration-unstable-v1.xml \ > > $(NULL) > > stable_protocols = \ > > diff --git a/unstable/xdg-decoration/README > b/unstable/xdg-decoration/README > > new file mode 100644 > > index 000..e927110 > > --- /dev/null > > +++ b/unstable/xdg-decoration/README > > @@ -0,0 +1,4 @@ > > +xdg_toplevel_decoration protocol > > - > > +Maintainers: > > +Simon Ser cont...@emersion.fr > > diff --git a/unstable/xdg-decoration/xdg-decoration-unstable-v1.xml > b/unstable/xdg-decoration/xdg-decoration-unstable-v1.xml > > new file mode 100644 > > index 000..935f1f5 > > --- /dev/null > > +++ b/unstable/xdg-decoration/xdg-decoration-unstable-v1.xml > > @@ -0,0 +1,115 @@ > > + > > + > > - > > - Copyright © 2018 Simon Ser > > - > - Permission is hereby granted, free of charge, to any person obtaining a > > - copy of this software and associated documentation files (the "Software"), > > - to deal in the Software without restriction, including without limitation > > - the rights to use, copy, modify, merge, publish, distribute, sublicense, > > - and/or sell copies of the Software, and to permit persons to whom the > > - Software is furnished to do so, subject to the following conditions: > > - > - The above copyright notice and this permission notice (including the next > > - paragraph) shall be included in all copies or substantial portions of the > > - Software. > > - > - THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR > > - IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, > > - FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL > > - THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER > > - L
Re: [PATCH wayland-protocols v5] unstable: add xdg-decoration protocol
On May 8, 2018 4:27 PM, Jonas Ådahl wrote: > Looks fine to me. Are all those Reviewed-by:s also for the trimmed down > version? Ah, no, you're right. Drew DeVault, David Edmundson, Alan Griffiths, Tony Crisci, Eike Hein: if you find this version of the proposal good enough, can you reply with a Reviewed-By tag again? > Are going to propose a newer version or is the v5 of the patch > what should end up as version 1 of the extension? My plan is to get this v5 patch end up as version 1 of the extension, as it already enables useful features. We'll discuss about adding back the set_mode request in a non-racy way separately. If consensus is reached, this could just be added with a simple protocol bump as I understand it? ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH wayland-protocols] xdg-output: add a transform example for the logical size
Signed-off-by: Simon Ser --- I believe it's easy to understand that transformations are not applied to the logical size. unstable/xdg-output/xdg-output-unstable-v1.xml | 3 +++ 1 file changed, 3 insertions(+) diff --git a/unstable/xdg-output/xdg-output-unstable-v1.xml b/unstable/xdg-output/xdg-output-unstable-v1.xml index bd9a8a8..320c0a0 100644 --- a/unstable/xdg-output/xdg-output-unstable-v1.xml +++ b/unstable/xdg-output/xdg-output-unstable-v1.xml @@ -135,6 +135,9 @@ - A compositor using a fractional scale of 1.5 will advertise a logical size to 2560×1620. + For example, for a wl_output mode 1920×1080 and a 90 degree rotation, the + compositor will advertise a logical size of 1080x1920. + The logical_size event is sent after creating an xdg_output (see xdg_output_manager.get_xdg_output) and whenever the logical size of the output changes, either as a result of a change in the -- 2.17.0 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH wayland-protocols v6] unstable: add xdg-decoration protocol
This adds a new protocol to negotiate server-side rendering of window decorations for xdg-toplevels. This allows compositors that want to draw decorations themselves to send their preference to clients, and clients that prefer server-side decorations to request them. This is inspired by a protocol from KDE [1] which has been implemented in KDE and Sway and was submitted for consideration in 2017 [2]. This patch provides an updated protocol with those concerns taken into account. Signed-off-by: Simon Ser [1] https://github.com/KDE/kwayland/blob/master/src/client/protocols/server-decoration.xml [2] https://lists.freedesktop.org/archives/wayland-devel/2017-October/035564.html --- This was iterated on privately between representatives of Sway and wlroots (Simon Ser, Drew DeVault and Tony Crisci), KDE and Qt (David Edmundson), and Mir (Alan Griffiths). A proof-of-concept of a client and server implementation is available at [1]. Changes from v5 to v6: - Add back the set_mode request, add a new unset_mode request This version fixes the race condition Jonas pointed out in his v4 review. I believe there were two client use-cases for the set_mode request in v4: - Request a specific preferred mode, and ignore the compositor preference. This is still possible since the set_mode request is back. - Use the compositor's preference, as the client doesn't have one. In v4 this was achieved by sending a set_mode request with the mode received in the preferred_mode event. In this version this is achieved by not unsetting the mode (either by not sending any set_mode request, or by sending an unset_mode request). The race condition could happen in v4 if the compositor sent a preferred_mode event and couldn't decide if the client would want to keep its current mode or change it (ie. should the compositor wait for a set_mode request or not?). This new design doesn't let the client know the compositor's preferred mode. When the compositor changes its preferred mode, it already knows if the client prefers to use it or to use its own - and thus can directly send a configure event if necessary. I believe this lso simplifies the protocol and makes it easier to understand. I don't think there are any regressions due to the fact that the client doesn't know anymore the compositor's preferred mode. [1] https://github.com/swaywm/wlroots/pull/638 Makefile.am | 1 + unstable/xdg-decoration/README| 4 + .../xdg-decoration-unstable-v1.xml| 145 ++ 3 files changed, 150 insertions(+) create mode 100644 unstable/xdg-decoration/README create mode 100644 unstable/xdg-decoration/xdg-decoration-unstable-v1.xml diff --git a/Makefile.am b/Makefile.am index 4b9a901..71909d8 100644 --- a/Makefile.am +++ b/Makefile.am @@ -17,6 +17,7 @@ unstable_protocols = \ unstable/keyboard-shortcuts-inhibit/keyboard-shortcuts-inhibit-unstable-v1.xml \ unstable/xdg-output/xdg-output-unstable-v1.xml \ unstable/input-timestamps/input-timestamps-unstable-v1.xml \ + unstable/xdg-decoration/xdg-decoration-unstable-v1.xml \ $(NULL) stable_protocols = \ diff --git a/unstable/xdg-decoration/README b/unstable/xdg-decoration/README new file mode 100644 index 000..73f0c52 --- /dev/null +++ b/unstable/xdg-decoration/README @@ -0,0 +1,4 @@ +xdg_decoration protocol + +Maintainers: +Simon Ser diff --git a/unstable/xdg-decoration/xdg-decoration-unstable-v1.xml b/unstable/xdg-decoration/xdg-decoration-unstable-v1.xml new file mode 100644 index 000..cf8cbdb --- /dev/null +++ b/unstable/xdg-decoration/xdg-decoration-unstable-v1.xml @@ -0,0 +1,145 @@ + + + +Copyright © 2018 Simon Ser + +Permission is hereby granted, free of charge, to any person obtaining a +copy of this software and associated documentation files (the "Software"), +to deal in the Software without restriction, including without limitation +the rights to use, copy, modify, merge, publish, distribute, sublicense, +and/or sell copies of the Software, and to permit persons to whom the +Software is furnished to do so, subject to the following conditions: + +The above copyright notice and this permission notice (including the next +paragraph) shall be included in all copies or substantial portions of the +Software. + +THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR +IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, +FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL +THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER +LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING +FROM, O
Re: [PATCH] virtual-keyboard: Add new virtual keyboard protocol
On May 21, 2018 12:12 AM, Dorota Czaplejewicz wrote: > Apart from the typo that Silvan spotted, I have also encountered the issue > where > the .c/.h generator complained about undefined key_state and keymap_format > enums > which are defined in wayland.xml. I'm not sure what the correct way to solve > this - should they be copied into this protocol? This is a bug in wayland-scanner, see [1]. Fixing wayland-scanner has been on my TODO-list for a while, but if you want to do it, go ahead. A (less than ideal) workaround is to remove the "enum" attribute from the for now. [1]: https://lists.freedesktop.org/archives/wayland-devel/2018-April/037960.html ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH] scanner: allow referencing foreign enums
It's already possible to reference foreign interfaces, so it
should also be possible to reference foreign enums.
Signed-off-by: Simon Ser
---
src/scanner.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/src/scanner.c b/src/scanner.c
index 1737911..205c28a 100644
--- a/src/scanner.c
+++ b/src/scanner.c
@@ -894,14 +894,9 @@ verify_arguments(struct parse_context *ctx,
e = find_enumeration(ctx->protocol, interface,
a->enumeration_name);
- if (e == NULL)
- fail(&ctx->loc,
-"could not find enumeration %s",
-a->enumeration_name);
-
switch (a->type) {
case INT:
- if (e->bitfield)
+ if (e && e->bitfield)
fail(&ctx->loc,
"bitfield-style enum must only be
referenced by uint");
break;
--
2.17.0
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland-protocols v6] unstable: add xdg-decoration protocol
Hi Jonas, What do you think of this new proposal? Thanks, --- Simon Ser https://emersion.fr On May 20, 2018 11:39 AM, Simon Ser wrote: > This adds a new protocol to negotiate server-side rendering of window > decorations for xdg-toplevels. This allows compositors that want to draw > decorations themselves to send their preference to clients, and clients that > prefer server-side decorations to request them. > > This is inspired by a protocol from KDE [1] which has been implemented in > KDE and Sway and was submitted for consideration in 2017 [2]. This patch > provides an updated protocol with those concerns taken into account. > > Signed-off-by: Simon Ser > > [1] > https://github.com/KDE/kwayland/blob/master/src/client/protocols/server-decoration.xml > [2] > https://lists.freedesktop.org/archives/wayland-devel/2017-October/035564.html > --- > > This was iterated on privately between representatives of Sway and wlroots > (Simon Ser, Drew DeVault and Tony Crisci), KDE and Qt (David Edmundson), and > Mir (Alan Griffiths). > > A proof-of-concept of a client and server implementation is available at [1]. > > Changes from v5 to v6: > - Add back the set_mode request, add a new unset_mode request > > This version fixes the race condition Jonas pointed out in his v4 review. > > I believe there were two client use-cases for the set_mode request in v4: > - Request a specific preferred mode, and ignore the compositor preference. > This > is still possible since the set_mode request is back. > - Use the compositor's preference, as the client doesn't have one. In v4 this > was achieved by sending a set_mode request with the mode received in the > preferred_mode event. In this version this is achieved by not unsetting the > mode (either by not sending any set_mode request, or by sending an > unset_mode > request). > > The race condition could happen in v4 if the compositor sent a preferred_mode > event and couldn't decide if the client would want to keep its current mode or > change it (ie. should the compositor wait for a set_mode request or not?). > This > new design doesn't let the client know the compositor's preferred mode. When > the > compositor changes its preferred mode, it already knows if the client prefers > to > use it or to use its own - and thus can directly send a configure event if > necessary. > > I believe this lso simplifies the protocol and makes it easier to understand. > I > don't think there are any regressions due to the fact that the client doesn't > know anymore the compositor's preferred mode. > > [1] https://github.com/swaywm/wlroots/pull/638 > > Makefile.am | 1 + > unstable/xdg-decoration/README| 4 + > .../xdg-decoration-unstable-v1.xml| 145 ++ > 3 files changed, 150 insertions(+) > create mode 100644 unstable/xdg-decoration/README > create mode 100644 unstable/xdg-decoration/xdg-decoration-unstable-v1.xml > > diff --git a/Makefile.am b/Makefile.am > index 4b9a901..71909d8 100644 > --- a/Makefile.am > +++ b/Makefile.am > @@ -17,6 +17,7 @@ unstable_protocols = > \ > > unstable/keyboard-shortcuts-inhibit/keyboard-shortcuts-inhibit-unstable-v1.xml > \ > unstable/xdg-output/xdg-output-unstable-v1.xml > \ > unstable/input-timestamps/input-timestamps-unstable-v1.xml \ > + unstable/xdg-decoration/xdg-decoration-unstable-v1.xml \ > $(NULL) > > stable_protocols = > \ > diff --git a/unstable/xdg-decoration/README b/unstable/xdg-decoration/README > new file mode 100644 > index 000..73f0c52 > --- /dev/null > +++ b/unstable/xdg-decoration/README > @@ -0,0 +1,4 @@ > +xdg_decoration protocol > + > +Maintainers: > +Simon Ser > diff --git a/unstable/xdg-decoration/xdg-decoration-unstable-v1.xml > b/unstable/xdg-decoration/xdg-decoration-unstable-v1.xml > new file mode 100644 > index 000..cf8cbdb > --- /dev/null > +++ b/unstable/xdg-decoration/xdg-decoration-unstable-v1.xml > @@ -0,0 +1,145 @@ > + > + > + > +Copyright © 2018 Simon Ser > + > +Permission is hereby granted, free of charge, to any person obtaining a > +copy of this software and associated documentation files (the > "Software"), > +to deal in the Software without restriction, including without limitation > +the rights to use, copy, modify, merge, publish, distribute, sublicense, > +and/or sell copies of the Software, and to permit persons to whom
Re: [PATCH_v2] virtual-keyboard: Add new virtual keyboard protocol
> + > + > + > + > + > + > + > + > + > + > +A key was pressed or released. > +The time argument is a timestamp with millisecond granularity, with > an > +undefined base. All requests regarding a single object must share the > +same clock. > + > +Keymap must be set before issuing this request. > + > +State carries a value from the key_state enumeration. (Ditto) > + > + > + > + > + > + > + > + > +Notifies the compositor that the modifier and/or group state has > +changed, and it should update state. > + > +The client should use wl_keyboard.modifiers event to synchronize its > +internal state with seat state. > + > +Keymap must be set before issuing this request. > + > + > + > + > + > + > + > + No need for `since="1"`, this is implicit. > + > + > + > + > + > + > + A virtual keyboard manager allows an application to provide keyboard > + input events as if they came from a physical keyboard. > + > + > + > + > + > + > + > + > +Creates a new virtual keyboard associated to a seat. > + > +If the compositor enables a keyboard to perform arbitrary actions, it > +should present an error when an untrusted client requests a new > +keyboard. Which error? Maybe this could just be reworded as something among the lines of "it should only allow trusted clients to use this request", implying it can either disconnect clients or (and this is probably preferred) don't expose the global by default. > + > + > + > + Is it possible to add a request to destroy the manager? Quoting pq from the latest DRM lease protocol review: >This interface is missing a destroy request. Interfaces must always have a >destroy request unless there is a very good reason to not have one. In any >case, every object must be destroyable somehow. > + > + > -- > 2.14.3 > ___ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/wayland-devel Otherwise, this protocol looks pretty good to me. --- Simon Ser https://emersion.fr ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland-protocols v6] unstable: add xdg-decoration protocol
Hi Jonas, Did you have the chance to have a look at this version? Thanks, --- Simon Ser https://emersion.fr On May 28, 2018 8:04 AM, Simon Ser wrote: > Hi Jonas, > > What do you think of this new proposal? > > Thanks, > --- > Simon Ser > https://emersion.fr > > On May 20, 2018 11:39 AM, Simon Ser wrote: > > This adds a new protocol to negotiate server-side rendering of window > > decorations for xdg-toplevels. This allows compositors that want to draw > > decorations themselves to send their preference to clients, and clients that > > prefer server-side decorations to request them. > > > > This is inspired by a protocol from KDE [1] which has been implemented in > > KDE and Sway and was submitted for consideration in 2017 [2]. This patch > > provides an updated protocol with those concerns taken into account. > > > > Signed-off-by: Simon Ser > > > > [1] > > https://github.com/KDE/kwayland/blob/master/src/client/protocols/server-decoration.xml > > [2] > > https://lists.freedesktop.org/archives/wayland-devel/2017-October/035564.html > > --- > > > > This was iterated on privately between representatives of Sway and wlroots > > (Simon Ser, Drew DeVault and Tony Crisci), KDE and Qt (David Edmundson), and > > Mir (Alan Griffiths). > > > > A proof-of-concept of a client and server implementation is available at > > [1]. > > > > Changes from v5 to v6: > > - Add back the set_mode request, add a new unset_mode request > > > > This version fixes the race condition Jonas pointed out in his v4 review. > > > > I believe there were two client use-cases for the set_mode request in v4: > > - Request a specific preferred mode, and ignore the compositor preference. > > This > > is still possible since the set_mode request is back. > > - Use the compositor's preference, as the client doesn't have one. In v4 > > this > > was achieved by sending a set_mode request with the mode received in the > > preferred_mode event. In this version this is achieved by not unsetting > > the > > mode (either by not sending any set_mode request, or by sending an > > unset_mode > > request). > > > > The race condition could happen in v4 if the compositor sent a > > preferred_mode > > event and couldn't decide if the client would want to keep its current mode > > or > > change it (ie. should the compositor wait for a set_mode request or not?). > > This > > new design doesn't let the client know the compositor's preferred mode. > > When the > > compositor changes its preferred mode, it already knows if the client > > prefers to > > use it or to use its own - and thus can directly send a configure event if > > necessary. > > > > I believe this lso simplifies the protocol and makes it easier to > > understand. I > > don't think there are any regressions due to the fact that the client > > doesn't > > know anymore the compositor's preferred mode. > > > > [1] https://github.com/swaywm/wlroots/pull/638 > > > > Makefile.am | 1 + > > unstable/xdg-decoration/README| 4 + > > .../xdg-decoration-unstable-v1.xml| 145 ++ > > 3 files changed, 150 insertions(+) > > create mode 100644 unstable/xdg-decoration/README > > create mode 100644 unstable/xdg-decoration/xdg-decoration-unstable-v1.xml > > > > diff --git a/Makefile.am b/Makefile.am > > index 4b9a901..71909d8 100644 > > --- a/Makefile.am > > +++ b/Makefile.am > > @@ -17,6 +17,7 @@ unstable_protocols = > > \ > > > > unstable/keyboard-shortcuts-inhibit/keyboard-shortcuts-inhibit-unstable-v1.xml > > \ > > unstable/xdg-output/xdg-output-unstable-v1.xml > > \ > > unstable/input-timestamps/input-timestamps-unstable-v1.xml \ > > + unstable/xdg-decoration/xdg-decoration-unstable-v1.xml \ > > $(NULL) > > > > stable_protocols = > > \ > > diff --git a/unstable/xdg-decoration/README b/unstable/xdg-decoration/README > > new file mode 100644 > > index 000..73f0c52 > > --- /dev/null > > +++ b/unstable/xdg-decoration/README > > @@ -0,0 +1,4 @@ > > +xdg_decoration protocol > > + > > +Maintainers: > > +Simon Ser > > diff --git a/unstable/xdg-decoration/xdg-decoration-unstable-v1.xml &
Re: [PATCH] scanner: allow referencing foreign enums
On May 29, 2018 9:52 AM, Pekka Paalanen wrote:
> On Sat, 26 May 2018 09:51:18 +0200
> Silvan Jegen wrote:
>
> > Hi
> >
> > On Fri, May 25, 2018 at 05:24:41PM -0400, Simon Ser wrote:
> > > It's already possible to reference foreign interfaces, so it
> > > should also be possible to reference foreign enums.
> > >
> > > Signed-off-by: Simon Ser
> > > ---
> > > src/scanner.c | 7 +--
> > > 1 file changed, 1 insertion(+), 6 deletions(-)
> >
> > It looks good to me and I can confirm that this works as intended. If
> > no solution allowing for the passing of reference protocols is desired,
> > this should be applied.
> >
> > Reviewed-by: Silvan Jegen
>
> Reviewed-by: Pekka Paalanen
>
> If no-one objects, I will push this next week. Do ping me if I forget.
Ping :)
> Thanks,
> pq
>
> > >
> > > diff --git a/src/scanner.c b/src/scanner.c
> > > index 1737911..205c28a 100644
> > > --- a/src/scanner.c
> > > +++ b/src/scanner.c
> > > @@ -894,14 +894,9 @@ verify_arguments(struct parse_context *ctx,
> > > e = find_enumeration(ctx->protocol, interface,
> > >a->enumeration_name);
> > >
> > > - if (e == NULL)
> > > - fail(&ctx->loc,
> > > - "could not find enumeration %s",
> > > - a->enumeration_name);
> > > -
> > > switch (a->type) {
> > > case INT:
> > > - if (e->bitfield)
> > > + if (e && e->bitfield)
> > > fail(&ctx->loc,
> > >"bitfield-style enum must only be
> > > referenced by uint");
> > > break;
> > > --
> > > 2.17.0
> > >
> > >
> > > ___
> > > 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
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland-protocols v6] unstable: add xdg-decoration protocol
Hi Jonas, Any news about this? Thanks, --- Simon Ser https://emersion.fr On June 4, 2018 9:11 AM, Simon Ser wrote: > Hi Jonas, > > Did you have the chance to have a look at this version? > > Thanks, > --- > Simon Ser > https://emersion.fr > > On May 28, 2018 8:04 AM, Simon Ser wrote: > > Hi Jonas, > > > > What do you think of this new proposal? > > > > Thanks, > > --- > > Simon Ser > > https://emersion.fr > > > > On May 20, 2018 11:39 AM, Simon Ser wrote: > > > This adds a new protocol to negotiate server-side rendering of window > > > decorations for xdg-toplevels. This allows compositors that want to draw > > > decorations themselves to send their preference to clients, and clients > > > that > > > prefer server-side decorations to request them. > > > > > > This is inspired by a protocol from KDE [1] which has been implemented in > > > KDE and Sway and was submitted for consideration in 2017 [2]. This patch > > > provides an updated protocol with those concerns taken into account. > > > > > > Signed-off-by: Simon Ser > > > > > > [1] > > > https://github.com/KDE/kwayland/blob/master/src/client/protocols/server-decoration.xml > > > [2] > > > https://lists.freedesktop.org/archives/wayland-devel/2017-October/035564.html > > > --- > > > > > > This was iterated on privately between representatives of Sway and wlroots > > > (Simon Ser, Drew DeVault and Tony Crisci), KDE and Qt (David Edmundson), > > > and > > > Mir (Alan Griffiths). > > > > > > A proof-of-concept of a client and server implementation is available at > > > [1]. > > > > > > Changes from v5 to v6: > > > - Add back the set_mode request, add a new unset_mode request > > > > > > This version fixes the race condition Jonas pointed out in his v4 review. > > > > > > I believe there were two client use-cases for the set_mode request in v4: > > > - Request a specific preferred mode, and ignore the compositor > > > preference. This > > > is still possible since the set_mode request is back. > > > - Use the compositor's preference, as the client doesn't have one. In v4 > > > this > > > was achieved by sending a set_mode request with the mode received in the > > > preferred_mode event. In this version this is achieved by not unsetting > > > the > > > mode (either by not sending any set_mode request, or by sending an > > > unset_mode > > > request). > > > > > > The race condition could happen in v4 if the compositor sent a > > > preferred_mode > > > event and couldn't decide if the client would want to keep its current > > > mode or > > > change it (ie. should the compositor wait for a set_mode request or > > > not?). This > > > new design doesn't let the client know the compositor's preferred mode. > > > When the > > > compositor changes its preferred mode, it already knows if the client > > > prefers to > > > use it or to use its own - and thus can directly send a configure event if > > > necessary. > > > > > > I believe this lso simplifies the protocol and makes it easier to > > > understand. I > > > don't think there are any regressions due to the fact that the client > > > doesn't > > > know anymore the compositor's preferred mode. > > > > > > [1] https://github.com/swaywm/wlroots/pull/638 > > > > > > Makefile.am | 1 + > > > unstable/xdg-decoration/README| 4 + > > > .../xdg-decoration-unstable-v1.xml| 145 ++ > > > 3 files changed, 150 insertions(+) > > > create mode 100644 unstable/xdg-decoration/README > > > create mode 100644 unstable/xdg-decoration/xdg-decoration-unstable-v1.xml > > > > > > diff --git a/Makefile.am b/Makefile.am > > > index 4b9a901..71909d8 100644 > > > --- a/Makefile.am > > > +++ b/Makefile.am > > > @@ -17,6 +17,7 @@ unstable_protocols = > > > \ > > > > > > unstable/keyboard-shortcuts-inhibit/keyboard-shortcuts-inhibit-unstable-v1.xml > > > \ > > > unstable/xdg-output/xdg-output-unstable-v1.xml > > > \ > > > unstable/input-timestamps/input-timestamp
Re: [PATCH wayland-protocols v6] unstable: add xdg-decoration protocol
On June 15, 2018 5:56 PM, Jonas Ådahl wrote: > Hi, Hi Jonas, Thanks for you feedback. > What about when clients change their "preference" in combination with a > window state change? > > Lets assume the compositor prefers server side, and the current state > is that the client has set the preferred state to "server_side" as well. > > For client driven state change: > > client: unset_maximize > server: configure(server_side, unmaximized) > client: set_state(client_side) > server: configure(client_side, unmaximized) > > And for the server driven state change: > > server: configure(server_side, unmaximized) > client: set_state(client_side) > server: configure(client_side, unmaximized) > > We'll temporarly have a unwanted configured state after the first > configures. That's right. This always happens when the client decides to change its preference on its own (e.g. when the window contents changes), not just when it's because of a window state change. The "infinite loop" issue you describe in case the server always sends configure events is specific to clients change their preference because of a window state change, though. > I guess this is work-around:able by requiring the compositor to always > reply with a configure() event for each (un)set_state() request no > matter whether any state changed or not (except for the initial state!), > and require the client to always ignore the configure() event when it > knows it will change its state preference. > > Requiring that is a bit awkward, or what do you think? It'll make an > extra back-and-forth between the compositor and client a necessity when > a decoration state preference depends on some other window state. I > don't have a better alternative in mind though. I'm okay with requiring the compositor to send configure events, but the second requirement seems a little weird phrased this way. I don't think we can avoid the extra roundtrip anyway, because the compositor cannot guess the client's preferred mode depending on its current state (and we really don't want to make the compositor able to do that). So, the client is aware that a set_mode or unset_mode request will always trigger a configure event. The client is thus responsible for preventing infinite loops to happen, and this might mean to prevent requests from being sent if they don't change the client's current preferred mode (in case the client changes its mode depending on the window state). In the protocol, we already have: > After requesting a decoration mode, the compositor will respond by > emitting a xdg_surface.configure event. So I think the requirement is already covered by this sentence. We could add "the compositor will always respond" if we want to play it safe. However, we also have: > The compositor can ignore this request. So we should probably change it to something like: > The compositor can decide not to use the client's mode and enforce a different > mode instead. What do you think? Simon ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH wayland-protocols v7] unstable: add xdg-decoration protocol
This adds a new protocol to negotiate server-side rendering of window decorations for xdg-toplevels. This allows compositors that want to draw decorations themselves to send their preference to clients, and clients that prefer server-side decorations to request them. This is inspired by a protocol from KDE [1] which has been implemented in KDE and Sway and was submitted for consideration in 2017 [2]. This patch provides an updated protocol with those concerns taken into account. Signed-off-by: Simon Ser [1] https://github.com/KDE/kwayland/blob/master/src/client/protocols/server-decoration.xml [2] https://lists.freedesktop.org/archives/wayland-devel/2017-October/035564.html --- This was iterated on privately between representatives of Sway and wlroots (Simon Ser, Drew DeVault and Tony Crisci), KDE and Qt (David Edmundson), and Mir (Alan Griffiths). A proof-of-concept of a client and server implementation is available at [1]. Changes from v6 to v7: - Move errors in xdg_toplevel_decoration - Add errors descriptions - Add an error when toplevel is destroyed before decoration - State that objects created with the manager are still valid after destroying the manager - Compositors can no longer ignore set_mode requests, but they can disregard the client's preference - Describe how clients whose preference depend on the window state should behave to prevent frames with unwanted state [1] https://github.com/swaywm/wlroots/pull/1053 Makefile.am | 1 + unstable/xdg-decoration/README| 4 + .../xdg-decoration-unstable-v1.xml| 145 ++ 3 files changed, 150 insertions(+) create mode 100644 unstable/xdg-decoration/README create mode 100644 unstable/xdg-decoration/xdg-decoration-unstable-v1.xml diff --git a/Makefile.am b/Makefile.am index 4b9a901..71909d8 100644 --- a/Makefile.am +++ b/Makefile.am @@ -17,6 +17,7 @@ unstable_protocols = \ unstable/keyboard-shortcuts-inhibit/keyboard-shortcuts-inhibit-unstable-v1.xml \ unstable/xdg-output/xdg-output-unstable-v1.xml \ unstable/input-timestamps/input-timestamps-unstable-v1.xml \ + unstable/xdg-decoration/xdg-decoration-unstable-v1.xml \ $(NULL) stable_protocols = \ diff --git a/unstable/xdg-decoration/README b/unstable/xdg-decoration/README new file mode 100644 index 000..73f0c52 --- /dev/null +++ b/unstable/xdg-decoration/README @@ -0,0 +1,4 @@ +xdg_decoration protocol + +Maintainers: +Simon Ser diff --git a/unstable/xdg-decoration/xdg-decoration-unstable-v1.xml b/unstable/xdg-decoration/xdg-decoration-unstable-v1.xml new file mode 100644 index 000..cf8cbdb --- /dev/null +++ b/unstable/xdg-decoration/xdg-decoration-unstable-v1.xml @@ -0,0 +1,145 @@ + + + +Copyright © 2018 Simon Ser + +Permission is hereby granted, free of charge, to any person obtaining a +copy of this software and associated documentation files (the "Software"), +to deal in the Software without restriction, including without limitation +the rights to use, copy, modify, merge, publish, distribute, sublicense, +and/or sell copies of the Software, and to permit persons to whom the +Software is furnished to do so, subject to the following conditions: + +The above copyright notice and this permission notice (including the next +paragraph) shall be included in all copies or substantial portions of the +Software. + +THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR +IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, +FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL +THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER +LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING +FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER +DEALINGS IN THE SOFTWARE. + + + + + This interface allows a compositor to announce support for server-side + decorations. + + A window decoration is a set of window controls as deemed appropriate by + the party managing them, such as user interface components used to move, + resize and change a window's state. + + A client can use this protocol to request being decorated by a supporting + compositor. + + If compositor and client do not negotiate the use of a server-side + decoration using this protocol, clients continue to self-decorate as they + see fit. + + Warning! The protocol described in this file is experimental and + backward incompatible changes may be made. Backward compatible changes + may be added together with the corresponding interface version bump. + Backward incompatible c
[PATCH wayland-protocols v7] unstable: add xdg-decoration protocol
This adds a new protocol to negotiate server-side rendering of window decorations for xdg-toplevels. This allows compositors that want to draw decorations themselves to send their preference to clients, and clients that prefer server-side decorations to request them. This is inspired by a protocol from KDE [1] which has been implemented in KDE and Sway and was submitted for consideration in 2017 [2]. This patch provides an updated protocol with those concerns taken into account. Signed-off-by: Simon Ser [1] https://github.com/KDE/kwayland/blob/master/src/client/protocols/server-decoration.xml [2] https://lists.freedesktop.org/archives/wayland-devel/2017-October/035564.html --- (Sorry, I somehow managed to send the old version and not the v7 one in my previous email) This was iterated on privately between representatives of Sway and wlroots (Simon Ser, Drew DeVault and Tony Crisci), KDE and Qt (David Edmundson), and Mir (Alan Griffiths). A proof-of-concept of a client and server implementation is available at [1]. Changes from v6 to v7: - Move errors in xdg_toplevel_decoration - Add errors descriptions - Add an error when toplevel is destroyed before decoration - State that objects created with the manager are still valid after destroying the manager - Compositors can no longer ignore set_mode requests, but they can disregard the client's preference - Describe how clients whose preference depend on the window state should behave to prevent frames with unwanted state [1] https://github.com/swaywm/wlroots/pull/1053 Makefile.am | 1 + unstable/xdg-decoration/README| 4 + .../xdg-decoration-unstable-v1.xml| 156 ++ 3 files changed, 161 insertions(+) create mode 100644 unstable/xdg-decoration/README create mode 100644 unstable/xdg-decoration/xdg-decoration-unstable-v1.xml diff --git a/Makefile.am b/Makefile.am index 4b9a901..71909d8 100644 --- a/Makefile.am +++ b/Makefile.am @@ -17,6 +17,7 @@ unstable_protocols = \ unstable/keyboard-shortcuts-inhibit/keyboard-shortcuts-inhibit-unstable-v1.xml \ unstable/xdg-output/xdg-output-unstable-v1.xml \ unstable/input-timestamps/input-timestamps-unstable-v1.xml \ + unstable/xdg-decoration/xdg-decoration-unstable-v1.xml \ $(NULL) stable_protocols = \ diff --git a/unstable/xdg-decoration/README b/unstable/xdg-decoration/README new file mode 100644 index 000..73f0c52 --- /dev/null +++ b/unstable/xdg-decoration/README @@ -0,0 +1,4 @@ +xdg_decoration protocol + +Maintainers: +Simon Ser diff --git a/unstable/xdg-decoration/xdg-decoration-unstable-v1.xml b/unstable/xdg-decoration/xdg-decoration-unstable-v1.xml new file mode 100644 index 000..378e8ff --- /dev/null +++ b/unstable/xdg-decoration/xdg-decoration-unstable-v1.xml @@ -0,0 +1,156 @@ + + + +Copyright © 2018 Simon Ser + +Permission is hereby granted, free of charge, to any person obtaining a +copy of this software and associated documentation files (the "Software"), +to deal in the Software without restriction, including without limitation +the rights to use, copy, modify, merge, publish, distribute, sublicense, +and/or sell copies of the Software, and to permit persons to whom the +Software is furnished to do so, subject to the following conditions: + +The above copyright notice and this permission notice (including the next +paragraph) shall be included in all copies or substantial portions of the +Software. + +THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR +IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, +FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL +THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER +LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING +FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER +DEALINGS IN THE SOFTWARE. + + + + + This interface allows a compositor to announce support for server-side + decorations. + + A window decoration is a set of window controls as deemed appropriate by + the party managing them, such as user interface components used to move, + resize and change a window's state. + + A client can use this protocol to request being decorated by a supporting + compositor. + + If compositor and client do not negotiate the use of a server-side + decoration using this protocol, clients continue to self-decorate as they + see fit. + + Warning! The protocol described in this file is experimental and + backward incompatible changes may be made. Backward compatible changes +
[PATCH wayland] doc: update IANA MIME types registry URL
Use a more official one, served over HTTP rather than FTP. --- doc/publican/sources/Protocol.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/publican/sources/Protocol.xml b/doc/publican/sources/Protocol.xml index 9fdee9a..fedaaab 100644 --- a/doc/publican/sources/Protocol.xml +++ b/doc/publican/sources/Protocol.xml @@ -479,7 +479,7 @@ MIME is defined in RFC's 2045-2049. A - ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/";> + https://www.iana.org/assignments/media-types/media-types.xhtml";> registry of MIME types is maintained by the Internet Assigned Numbers Authority (IANA). -- 2.17.1 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH v3 wayland-protocols] virtual-keyboard: Add new virtual keyboard protocol
On June 22, 2018 4:20 PM, Dorota Czaplejewicz wrote: > Provides the ability to emulate keyboards by applications. Complementary to > input-method protocol. > > The interface is a mirror copy of wl_keyboard, with removed serials, and > added seat binding. > --- > Hi, > > this patch is another improvement to the previously sent virtual keyboard > protocol. Changes compared to v2: > > - readded enum names > - removed suggestion to listen to modifiers > - clarified untrusted client behaviour > - added destructor on virtual_keyboard_manager > - fixed text wrapping > > First off, the new version of wayland-scanner looks up enums found in other > xml files, so the textual reference are gone and actual enum values are used. > > Secondly, there was a suggestion that if the client wants to know global > modifiers, it should listen to wl_keyboard.modifiers. In reality, this can > only be done when the client has keyboard focus. I decided to remove this > suggestion. > > Clarified that create_virtual_keyboard must error out with unauthorized when > an untrusted client connects. That doesn't preclude making the whole > virtual_keyboard_manager interface unavailable when the client is determined > as untrusted ahead of time. > > Lastly, added a missing destructor as per Simon Ser's suggestion. > > I hope that we're getting closer to perfect with this revision! As usual, > feedback is welcome. > > Cheers, > Dorota Czaplejewicz Hi, Thanks for this updated version. A few comments below. > Makefile.am| 1 + > unstable/virtual-keyboard/README | 2 + > .../virtual-keyboard-unstable-v1.xml | 116 > + > 3 files changed, 119 insertions(+) > create mode 100644 unstable/virtual-keyboard/README > create mode 100644 unstable/virtual-keyboard/virtual-keyboard-unstable-v1.xml > > diff --git a/Makefile.am b/Makefile.am > index 1aa13cf..17cedc1 100644 > --- a/Makefile.am > +++ b/Makefile.am > @@ -19,6 +19,7 @@ unstable_protocols = > \ > > unstable/keyboard-shortcuts-inhibit/keyboard-shortcuts-inhibit-unstable-v1.xml > \ > unstable/xdg-output/xdg-output-unstable-v1.xml > \ > unstable/input-timestamps/input-timestamps-unstable-v1.xml \ > + unstable/virtual-keyboard/virtual-keyboard-unstable-v1.xml \ > $(NULL) > > stable_protocols = > \ > diff --git a/unstable/virtual-keyboard/README > b/unstable/virtual-keyboard/README > new file mode 100644 > index 000..a2c646d > --- /dev/null > +++ b/unstable/virtual-keyboard/README > @@ -0,0 +1,2 @@ > +Virtual keyboard protocol > + > diff --git a/unstable/virtual-keyboard/virtual-keyboard-unstable-v1.xml > b/unstable/virtual-keyboard/virtual-keyboard-unstable-v1.xml > new file mode 100644 > index 000..bde55e8 > --- /dev/null > +++ b/unstable/virtual-keyboard/virtual-keyboard-unstable-v1.xml > @@ -0,0 +1,116 @@ > + > + > + > +Copyright © 2008-2011 Kristian Høgsberg > +Copyright © 2010-2013 Intel Corporation > +Copyright © 2012-2013 Collabora, Ltd. > +Copyright © 2018 Purism SPC > + > +Permission is hereby granted, free of charge, to any person obtaining a > +copy of this software and associated documentation files (the > "Software"), > +to deal in the Software without restriction, including without limitation > +the rights to use, copy, modify, merge, publish, distribute, sublicense, > +and/or sell copies of the Software, and to permit persons to whom the > +Software is furnished to do so, subject to the following conditions: > + > +The above copyright notice and this permission notice (including the next > +paragraph) shall be included in all copies or substantial portions of the > +Software. > + > +THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS > OR > +IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, > +FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL > +THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR > OTHER > +LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING > +FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER > +DEALINGS IN THE SOFTWARE. > + > + > + > + > + The virtual keyboard provides an application with requests which > emulate > + the behaviour of a physical keyboard. > + > + This interface can be used by clients on its own to provide raw input > + events, or it can accompany the input method protocol. > + > + > + > + > +Provide a file descriptor to the compositor which can be > memory-mapped > +to provide a keyboard mapping description. > + > + +summary="keymap format"/> > +
Re: [PATCH v3 wayland-protocols] virtual-keyboard: Add new virtual keyboard protocol
On June 22, 2018 7:00 PM, Dorota Czaplejewicz wrote: > On Fri, 22 Jun 2018 12:36:16 -0400 > Simon Ser wrote: > > > On June 22, 2018 4:20 PM, Dorota Czaplejewicz > > wrote: > > > Provides the ability to emulate keyboards by applications. Complementary > > > to input-method protocol. > > > > > > The interface is a mirror copy of wl_keyboard, with removed serials, and > > > added seat binding. > > > --- > > > Hi, > > > > > > this patch is another improvement to the previously sent virtual keyboard > > > protocol. Changes compared to v2: > > > > > > - readded enum names > > > - removed suggestion to listen to modifiers > > > - clarified untrusted client behaviour > > > - added destructor on virtual_keyboard_manager > > > - fixed text wrapping > > > > > > First off, the new version of wayland-scanner looks up enums found in > > > other xml files, so the textual reference are gone and actual enum values > > > are used. > > > > > > Secondly, there was a suggestion that if the client wants to know global > > > modifiers, it should listen to wl_keyboard.modifiers. In reality, this > > > can only be done when the client has keyboard focus. I decided to remove > > > this suggestion. > > > > > > Clarified that create_virtual_keyboard must error out with unauthorized > > > when an untrusted client connects. That doesn't preclude making the whole > > > virtual_keyboard_manager interface unavailable when the client is > > > determined as untrusted ahead of time. > > > > > > Lastly, added a missing destructor as per Simon Ser's suggestion. > > > > > > I hope that we're getting closer to perfect with this revision! As usual, > > > feedback is welcome. > > > > > > Cheers, > > > Dorota Czaplejewicz > > > > Hi, > > > > Thanks for this updated version. A few comments below. > > > snip > > > + > > > + > > > + > > > + A virtual keyboard manager allows an application to provide > > > keyboard > > > + input events as if they came from a physical keyboard. > > > + > > > + If the compositor enables a keyboard to perform arbitrary actions, > > > it > > > + should prevent untrusted clients from using this interface. > > > + > > > + > > > + > > > + > > +summary="client not authorized to use the interface"/> > > > + > > > > This is more of a general metaphorical question than anything else: I > > wonder how > > we should handle unauthorized clients, and if adding an error for them is a > > good > > idea. Generally errors are meant for protocol violations: it's clear from > > the > > protocol spec that e.g. sending a request with a negative value will > > trigger a > > protocol error. Also, errors are unrecoverable, they abort the whole client > > (though this is being worked on). > > > > So here we use an error, and the conditions in which the error is sent are > > implementation-defined. I wonder if there's a better way to handle this > > situation? > > > Speaking from a position of someone without a lot of Wayland experience: are > Wayland errors meant to be recoverable by a client? It's obvious that if an > application doing its primary task and then trying to use a restricted > protocol as a secondary action crashes, that's undesireable. Wayland protocol errors are meant to be fatal. They're meant to signal that the client is doing something really wrong, against the protocol specification. They indicate a bug in the client. As ongy said, they currently abort() the whole client. > As a more concrete example, an automation application may use e.g. DBus API to > automate tasks, and display a window to control it. It may request a virtual > keyboard to extend its possibilities, but it shouldn't suddenly stop working > if it's refused by the compositor. That's right, and that's a reason why I'd personally prefer not to use protocol errors for security errors. > That brings me to the question: should applications using restricted protocols > create additional connections which may be broken and recovered from > individually or should they rather use one connection? If the latter is > required for some use cases, then authorization and probing/graceful rejection > should be specified inside protocols. Unfortunatel
Re: [PATCH v3 wayland-protocols] virtual-keyboard: Add new virtual keyboard protocol
On June 24, 2018 12:24 PM, Simon Ser wrote: > On June 22, 2018 7:00 PM, Dorota Czaplejewicz > wrote: > > On Fri, 22 Jun 2018 12:36:16 -0400 > > Simon Ser wrote: > > > > > On June 22, 2018 4:20 PM, Dorota Czaplejewicz > > > wrote: > > > > Provides the ability to emulate keyboards by applications. > > > > Complementary to input-method protocol. > > > > > > > > The interface is a mirror copy of wl_keyboard, with removed serials, > > > > and added seat binding. > > > > --- > > > > Hi, > > > > > > > > this patch is another improvement to the previously sent virtual > > > > keyboard protocol. Changes compared to v2: > > > > > > > > - readded enum names > > > > - removed suggestion to listen to modifiers > > > > - clarified untrusted client behaviour > > > > - added destructor on virtual_keyboard_manager > > > > - fixed text wrapping > > > > > > > > First off, the new version of wayland-scanner looks up enums found in > > > > other xml files, so the textual reference are gone and actual enum > > > > values are used. > > > > > > > > Secondly, there was a suggestion that if the client wants to know > > > > global modifiers, it should listen to wl_keyboard.modifiers. In > > > > reality, this can only be done when the client has keyboard focus. I > > > > decided to remove this suggestion. > > > > > > > > Clarified that create_virtual_keyboard must error out with unauthorized > > > > when an untrusted client connects. That doesn't preclude making the > > > > whole virtual_keyboard_manager interface unavailable when the client is > > > > determined as untrusted ahead of time. > > > > > > > > Lastly, added a missing destructor as per Simon Ser's suggestion. > > > > > > > > I hope that we're getting closer to perfect with this revision! As > > > > usual, feedback is welcome. > > > > > > > > Cheers, > > > > Dorota Czaplejewicz > > > > > > Hi, > > > > > > Thanks for this updated version. A few comments below. > > > > > snip > > > > + > > > > + > > > > + > > > > + A virtual keyboard manager allows an application to provide > > > > keyboard > > > > + input events as if they came from a physical keyboard. > > > > + > > > > + If the compositor enables a keyboard to perform arbitrary > > > > actions, it > > > > + should prevent untrusted clients from using this interface. > > > > + > > > > + > > > > + > > > > + > > > +summary="client not authorized to use the interface"/> > > > > + > > > > > > This is more of a general metaphorical question than anything else: I > > > wonder how > > > we should handle unauthorized clients, and if adding an error for them is > > > a good > > > idea. Generally errors are meant for protocol violations: it's clear from > > > the > > > protocol spec that e.g. sending a request with a negative value will > > > trigger a > > > protocol error. Also, errors are unrecoverable, they abort the whole > > > client > > > (though this is being worked on). > > > > > > So here we use an error, and the conditions in which the error is sent are > > > implementation-defined. I wonder if there's a better way to handle this > > > situation? > > > > > Speaking from a position of someone without a lot of Wayland experience: are > > Wayland errors meant to be recoverable by a client? It's obvious that if an > > application doing its primary task and then trying to use a restricted > > protocol as a secondary action crashes, that's undesireable. > > Wayland protocol errors are meant to be fatal. They're meant to signal that > the > client is doing something really wrong, against the protocol specification. > They > indicate a bug in the client. As ongy said, they currently abort() the whole > client. It seems we've been misunderstanding this point. They don't abort the client, they just kill the connection. After that, functions called with the same wl_display will start returning errors. There are functions to get details about the protocol er
Re: [PATCH wayland-protocols v7] unstable: add xdg-decoration protocol
Hi Jonas, What do you think of this new version? Wording suggestions and other comments welcome :) Thanks, Simon On June 18, 2018 11:16 AM, Simon Ser wrote: > This adds a new protocol to negotiate server-side rendering of window > decorations for xdg-toplevels. This allows compositors that want to draw > decorations themselves to send their preference to clients, and clients that > prefer server-side decorations to request them. > > This is inspired by a protocol from KDE [1] which has been implemented in > KDE and Sway and was submitted for consideration in 2017 [2]. This patch > provides an updated protocol with those concerns taken into account. > > Signed-off-by: Simon Ser > > [1] > https://github.com/KDE/kwayland/blob/master/src/client/protocols/server-decoration.xml > [2] > https://lists.freedesktop.org/archives/wayland-devel/2017-October/035564.html > --- > > (Sorry, I somehow managed to send the old version and not the v7 one in my > previous email) > > This was iterated on privately between representatives of Sway and wlroots > (Simon Ser, Drew DeVault and Tony Crisci), KDE and Qt (David Edmundson), and > Mir (Alan Griffiths). > > A proof-of-concept of a client and server implementation is available at [1]. > > Changes from v6 to v7: > - Move errors in xdg_toplevel_decoration > - Add errors descriptions > - Add an error when toplevel is destroyed before decoration > - State that objects created with the manager are still valid after > destroying the manager > - Compositors can no longer ignore set_mode requests, but they can > disregard the client's preference > - Describe how clients whose preference depend on the window state > should behave to prevent frames with unwanted state > > [1] https://github.com/swaywm/wlroots/pull/1053 > > Makefile.am | 1 + > unstable/xdg-decoration/README| 4 + > .../xdg-decoration-unstable-v1.xml| 156 ++ > 3 files changed, 161 insertions(+) > create mode 100644 unstable/xdg-decoration/README > create mode 100644 unstable/xdg-decoration/xdg-decoration-unstable-v1.xml > > diff --git a/Makefile.am b/Makefile.am > index 4b9a901..71909d8 100644 > --- a/Makefile.am > +++ b/Makefile.am > @@ -17,6 +17,7 @@ unstable_protocols = > \ > > unstable/keyboard-shortcuts-inhibit/keyboard-shortcuts-inhibit-unstable-v1.xml > \ > unstable/xdg-output/xdg-output-unstable-v1.xml > \ > unstable/input-timestamps/input-timestamps-unstable-v1.xml \ > + unstable/xdg-decoration/xdg-decoration-unstable-v1.xml \ > $(NULL) > > stable_protocols = > \ > diff --git a/unstable/xdg-decoration/README b/unstable/xdg-decoration/README > new file mode 100644 > index 000..73f0c52 > --- /dev/null > +++ b/unstable/xdg-decoration/README > @@ -0,0 +1,4 @@ > +xdg_decoration protocol > + > +Maintainers: > +Simon Ser > diff --git a/unstable/xdg-decoration/xdg-decoration-unstable-v1.xml > b/unstable/xdg-decoration/xdg-decoration-unstable-v1.xml > new file mode 100644 > index 000..378e8ff > --- /dev/null > +++ b/unstable/xdg-decoration/xdg-decoration-unstable-v1.xml > @@ -0,0 +1,156 @@ > + > + > + > +Copyright © 2018 Simon Ser > + > +Permission is hereby granted, free of charge, to any person obtaining a > +copy of this software and associated documentation files (the > "Software"), > +to deal in the Software without restriction, including without limitation > +the rights to use, copy, modify, merge, publish, distribute, sublicense, > +and/or sell copies of the Software, and to permit persons to whom the > +Software is furnished to do so, subject to the following conditions: > + > +The above copyright notice and this permission notice (including the next > +paragraph) shall be included in all copies or substantial portions of the > +Software. > + > +THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS > OR > +IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, > +FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL > +THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR > OTHER > +LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING > +FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER > +DEALINGS IN THE SOFTWARE. > + > + > + > + > + This interface allows a compositor to annou
Re: [PATCH v2 1/3] xdg-shell: move maximized state definition together
> From: Markus Ongyerth > > The xdg-shell documentation had part of the maximized state render > implications in the `set_maximized` request documentation, not the > actual state. > This moves the relevant lines into the state description. > > Signed-off-by: Markus Ongyerth > Reviewed-By: Mike Blumenkrantz > --- > stable/xdg-shell/xdg-shell.xml | 6 -- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/stable/xdg-shell/xdg-shell.xml b/stable/xdg-shell/xdg-shell.xml > index ad96fe8..9067275 100644 > --- a/stable/xdg-shell/xdg-shell.xml > +++ b/stable/xdg-shell/xdg-shell.xml > @@ -724,6 +724,9 @@ > > The surface is maximized. The window geometry specified in the > configure > event must be obeyed by the client. > + > + The client should draw without shadow > + or other decoration outside of the window geometry. Nitpick: there's a line wrapping issue here. Otherwise this is: Reviewed-by: Simon Ser > > > > @@ -865,8 +868,7 @@ > After requesting that the surface should be maximized, the compositor > will respond by emitting a configure event with the "maximized" state > and the required window geometry. The client should then update its > - content, drawing it in a maximized state, i.e. without shadow or other > - decoration outside of the window geometry. The client must also > + content, drawing it in a maximized state. The client must also > acknowledge the configure when committing the new content (see > ack_configure). > > -- > 2.18.0 > > ___ > 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: [PATCH v2 2/3] xdg-shell: Make sure wording reflects expectations
> From: Markus Ongyerth This should maybe be a Signed-off-by at the end of the commit message? > The wording in xdg-shell's `set_*` requests implies the compositor > *will* honour the client's request. > This would give clients the control over their actual state, while the > general expectation is that clients kindly ask for state changes which > the compositor may follow. > This patch ensures the actual protocol text reflects these expectations. > --- > stable/xdg-shell/xdg-shell.xml | 49 +- > 1 file changed, 25 insertions(+), 24 deletions(-) > > diff --git a/stable/xdg-shell/xdg-shell.xml b/stable/xdg-shell/xdg-shell.xml > index 9067275..08708dd 100644 > --- a/stable/xdg-shell/xdg-shell.xml > +++ b/stable/xdg-shell/xdg-shell.xml > @@ -725,8 +725,8 @@ > The surface is maximized. The window geometry specified in the > configure > event must be obeyed by the client. > > - The client should draw without shadow > - or other decoration outside of the window geometry. > + The client should draw without shadow or other > + decoration outside of the window geometry. Hmm. This belongs to the previous patch, I believe? I think this is a good change otherwise. Reviewed-by: Simon Ser > > > > @@ -866,11 +866,11 @@ > Maximize the surface. > > After requesting that the surface should be maximized, the compositor > - will respond by emitting a configure event with the "maximized" state > - and the required window geometry. The client should then update its > - content, drawing it in a maximized state. The client must also > - acknowledge the configure when committing the new content (see > - ack_configure). > + will respond by emitting a configure event. Whether this configure > + actually sets the window maximized is subject to compositor policies. > + The client must then update its content, drawing in the configured > + state. The client must also acknowledge the configure when committing > + the new content (see ack_configure). > > It is up to the compositor to decide how and where to maximize the > surface, for example which output and what region of the screen should > @@ -880,8 +880,8 @@ > a configure event with the "maximized" state. > > If the surface is in a fullscreen state, this request has no direct > - effect. It will alter the state the surface is returned to when > - unmaximized if not overridden by the compositor. > + effect. It may alter the state the surface is returned to when > + unmaximized unless overridden by the compositor. > > > > @@ -890,13 +890,13 @@ > Unmaximize the surface. > > After requesting that the surface should be unmaximized, the compositor > - will respond by emitting a configure event without the "maximized" > - state. If available, the compositor will include the window geometry > - dimensions the window had prior to being maximized in the configure > - event. The client must then update its content, drawing it in a > - regular state, i.e. potentially with shadow, etc. The client must also > - acknowledge the configure when committing the new content (see > - ack_configure). > + will respond by emitting a configure event. Whether this actually > + un-maximizes the window is subject to compositor policies. > + If available and applicable, the compositor will include the window > + geometry dimensions the window had prior to being maximized in the > + configure event. The client must then update its content, drawing it in > + the configured state. The client must also acknowledge the configure > + when committing the new content (see ack_configure). > > It is up to the compositor to position the surface after it was > unmaximized; usually the position the surface had before maximizing, if > @@ -906,8 +906,8 @@ > emit a configure event without the "maximized" state. > > If the surface is in a fullscreen state, this request has no direct > - effect. It will alter the state the surface is returned to when > - unmaximized if not overridden by the compositor. > + effect. It may alter the state the surface is returned to when > + unmaximized unless overridden by the compositor. > > > > @@ -916,10 +916,10 @@ > Make the surface fullscreen. > > After requesting that the surface should be fullscreened, the > - compositor will respond by emitting a configure event with the > - "fullscreen" state and th
Re: [PATCH] compositor-headless: Report a more realistic physical size
> On Thu, 12 Apr 2018 09:31:48 +0200
> Johan Klokkhammer Helsing wrote:
>
> > Some clients rely on the physical size to determine the physical DPI. With
> > the
> > previous implementation, we would report 1px==1mm, which is a DPI of 25.4,
> > which is incredibly low.
> >
> > The problem is solved by setting a physical size so the DPI is close to 72
> > instead. If the output is scaled, the DPI is set to the corresponding
> > multiple
> > of 72.
> >
> > This makes the headless backend more usable for automated testing of DPI
> > sensitive functionality such as point sized fonts.
> >
> > Signed-off-by: Johan Klokkhammer Helsing
> > ---
> > libweston/compositor-headless.c | 16
> > 1 file changed, 12 insertions(+), 4 deletions(-)
>
> Hi,
>
> this is a good idea, but could you rebase this patch to master?
>
>
> Thanks,
> pq
Hi,
Would it make sense to change the protocol to allow compositors to send a zero
physical size in case it isn't relevant?
> >
> > diff --git a/libweston/compositor-headless.c
> > b/libweston/compositor-headless.c
> > index 9307a36a..9f1a1a72 100644
> > --- a/libweston/compositor-headless.c
> > +++ b/libweston/compositor-headless.c
> > @@ -180,12 +180,19 @@ err_malloc:
> > return -1;
> > }
> >
> > +static int
> > +physical_size_for_dpi(int pixels, int dpi)
> > +{
> > + static const float mm_per_inch = 25.4;
> > + return pixels * mm_per_inch / dpi;
> > +}
> > +
> > static int
> > headless_output_set_size(struct weston_output *base,
> > int width, int height)
> > {
> > struct headless_output *output = to_headless_output(base);
> > - int output_width, output_height;
> > + int output_width, output_height, output_dpi;
> >
> > /* We can only be called once. */
> > assert(!output->base.current_mode);
> > @@ -207,9 +214,10 @@ headless_output_set_size(struct weston_output *base,
> > output->base.make = "weston";
> > output->base.model = "headless";
> >
> > - /* XXX: Calculate proper size. */
> > - output->base.mm_width = width;
> > - output->base.mm_height = height;
> > + /* XXX: Make this configurable */
> > + output_dpi = 72 * output->base.scale;
> > + output->base.mm_width = physical_size_for_dpi(output_width, output_dpi);
> > + output->base.mm_height = physical_size_for_dpi(output_height,
> > output_dpi);
> >
> > output->base.start_repaint_loop = headless_output_start_repaint_loop;
> > output->base.repaint = headless_output_repaint;
>
> ___
> 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] protocol: allow to send a zero physical output size
Physical size doesn't always make sense for all outputs. In case it's not available or not relevant, allow compositors to send zero. --- In practice this doesn't seem to break any client toolkit. We've been doing that for a long time in wlroots. protocol/wayland.xml | 3 +++ 1 file changed, 3 insertions(+) diff --git a/protocol/wayland.xml b/protocol/wayland.xml index b5662e0..141038b 100644 --- a/protocol/wayland.xml +++ b/protocol/wayland.xml @@ -2399,6 +2399,9 @@ The geometry event describes geometric properties of the output. The event is sent when binding to the output object and whenever any of the properties change. + + The physical size can be set to zero if it doesn't make sense for this + output (e.g. for projectors or virtual outputs). -- 2.18.0 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland 8/8] fixup! scanner: initialize .{method, event}_count via ARRAY_SIZE
On July 3, 2018 12:45 PM, Pekka Paalanen wrote:
> On Thu, 14 Jun 2018 16:49:45 +0100
> Emil Velikov wrote:
>
> > ---
> > 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] = &wl_surface_interface,
> > };
> >
> > +#define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0]))
> > static const struct wl_message wl_display_requests[] = {
> > { .name = "sync", .signature = "n", .types = &types[8] },
> > { .name = "get_registry", .signature = "n", .types = &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,
> > };
>
> Hi,
>
> this change is not an obvious improvement to me. "method_count = 2" is
> pretty clear, that combined with "methods = foo" does not seem to
> leave anything to be desired.
>
> If this code was hand-written, then I would be cheering for ARRAY_SIZE
> for sure, but it's not. It all comes from a generator that gets the
> count right.
>
> I suppose we'd need an opinion from someone who is less familiar with
> Wayland C bindings.
Hi,
I'm not sure if I qualify, but I would agree with Pekka here. This generated
code isn't meant to be maintained or edited by humans. This code is read-only,
and is readable enough as is IMHO for the reasons Pekka wrote.
> 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] protocol: warn clients about some wl_output properties
All wl_output properties don't always make sense for all
compositors.
Some compositors might not implement a "global compositor space",
(e.g. 3D compositors) in which case properties like x and y don't
make sense.
Some compositors might expose virtual outputs, in which case modes,
make and model are not relevant.
In a lot of these situations, information from xdg_output is better
suited.
---
Regular clients shouldn't use most of these properties anyway.
wl_output is not meant to be an output management protocol. wl_output
should only expose enough information to allow clients to display
themselves properly. I don't think there's any legitimate use-case
to read geometry.{x,y,make,model} and modes for regular clients. Some
clients (e.g. xwayland) need more information and support an additional
protocol (xdg-output) that's better suited.
Because of this, compositors should be allowed to fake these properties,
and clients should be prepared to receive fake data.
I'm not completely happy with this patch. IMHO we should completely
deprecate modes because I really fail to see how clients will use this
information properly. To do so we can probably just bump the protocol
version and make this event optional?
protocol/wayland.xml | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/protocol/wayland.xml b/protocol/wayland.xml
index b5662e0..b4ffcd5 100644
--- a/protocol/wayland.xml
+++ b/protocol/wayland.xml
@@ -2399,6 +2399,13 @@
The geometry event describes geometric properties of the output.
The event is sent when binding to the output object and whenever
any of the properties change.
+
+ Note: wl_output only advertises partial information about the output
+ position and identification. Some compositors, for instance those not
+ implementing a desktop-style output layout or those exposing virtual
+ outputs, might fake this information. Instead of using x and y, clients
+ should use xdg_output.logical_position. Instead of using make and model,
+ clients should use xdg_output.name and xdg_output.description.
@@ -2443,7 +2450,13 @@
the output device. This is not necessarily the same as
the output size in the global compositor space. For instance,
the output may be scaled, as described in wl_output.scale,
- or transformed, as described in wl_output.transform.
+ or transformed, as described in wl_output.transform. Clients
+ willing to retrieve the output size in the global compositor
+ space should use xdg_output.logical_size instead.
+
+ Note: this information is not always meaningful for all outputs. Some
+ compositors, such as those exposing virtual outputs, might fake the
+ refresh rate or the size.
--
2.18.0
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland-protocols v7] unstable: add xdg-decoration protocol
Hi Jonas, Any news about this? Thanks, Simon On June 27, 2018 5:23 PM, Simon Ser wrote: > Hi Jonas, > > What do you think of this new version? Wording suggestions and other comments > welcome :) > > Thanks, > > Simon > > On June 18, 2018 11:16 AM, Simon Ser wrote: > > This adds a new protocol to negotiate server-side rendering of window > > decorations for xdg-toplevels. This allows compositors that want to draw > > decorations themselves to send their preference to clients, and clients that > > prefer server-side decorations to request them. > > > > This is inspired by a protocol from KDE [1] which has been implemented in > > KDE and Sway and was submitted for consideration in 2017 [2]. This patch > > provides an updated protocol with those concerns taken into account. > > > > Signed-off-by: Simon Ser > > > > [1] > > https://github.com/KDE/kwayland/blob/master/src/client/protocols/server-decoration.xml > > [2] > > https://lists.freedesktop.org/archives/wayland-devel/2017-October/035564.html > > --- > > > > (Sorry, I somehow managed to send the old version and not the v7 one in my > > previous email) > > > > This was iterated on privately between representatives of Sway and wlroots > > (Simon Ser, Drew DeVault and Tony Crisci), KDE and Qt (David Edmundson), and > > Mir (Alan Griffiths). > > > > A proof-of-concept of a client and server implementation is available at > > [1]. > > > > Changes from v6 to v7: > > - Move errors in xdg_toplevel_decoration > > - Add errors descriptions > > - Add an error when toplevel is destroyed before decoration > > - State that objects created with the manager are still valid after > > destroying the manager > > - Compositors can no longer ignore set_mode requests, but they can > > disregard the client's preference > > - Describe how clients whose preference depend on the window state > > should behave to prevent frames with unwanted state > > > > [1] https://github.com/swaywm/wlroots/pull/1053 > > > > Makefile.am | 1 + > > unstable/xdg-decoration/README| 4 + > > .../xdg-decoration-unstable-v1.xml| 156 ++ > > 3 files changed, 161 insertions(+) > > create mode 100644 unstable/xdg-decoration/README > > create mode 100644 unstable/xdg-decoration/xdg-decoration-unstable-v1.xml > > > > diff --git a/Makefile.am b/Makefile.am > > index 4b9a901..71909d8 100644 > > --- a/Makefile.am > > +++ b/Makefile.am > > @@ -17,6 +17,7 @@ unstable_protocols = > > \ > > > > unstable/keyboard-shortcuts-inhibit/keyboard-shortcuts-inhibit-unstable-v1.xml > > \ > > unstable/xdg-output/xdg-output-unstable-v1.xml > > \ > > unstable/input-timestamps/input-timestamps-unstable-v1.xml \ > > + unstable/xdg-decoration/xdg-decoration-unstable-v1.xml \ > > $(NULL) > > > > stable_protocols = > > \ > > diff --git a/unstable/xdg-decoration/README b/unstable/xdg-decoration/README > > new file mode 100644 > > index 000..73f0c52 > > --- /dev/null > > +++ b/unstable/xdg-decoration/README > > @@ -0,0 +1,4 @@ > > +xdg_decoration protocol > > + > > +Maintainers: > > +Simon Ser > > diff --git a/unstable/xdg-decoration/xdg-decoration-unstable-v1.xml > > b/unstable/xdg-decoration/xdg-decoration-unstable-v1.xml > > new file mode 100644 > > index 000..378e8ff > > --- /dev/null > > +++ b/unstable/xdg-decoration/xdg-decoration-unstable-v1.xml > > @@ -0,0 +1,156 @@ > > + > > + > > + > > +Copyright © 2018 Simon Ser > > + > > +Permission is hereby granted, free of charge, to any person obtaining a > > +copy of this software and associated documentation files (the > > "Software"), > > +to deal in the Software without restriction, including without > > limitation > > +the rights to use, copy, modify, merge, publish, distribute, > > sublicense, > > +and/or sell copies of the Software, and to permit persons to whom the > > +Software is furnished to do so, subject to the following conditions: > > + > > +The above copyright notice and this permission notice (including the > > next > > +paragraph) shall be included in all copies or substantial portions of > > the > > +
Re: [PATCH wayland-protocols v7] unstable: add xdg-decoration protocol
On July 4, 2018 3:45 PM, Jonas Ådahl wrote: > Looks good to me, I think we can go with this. What Reviewed-by:s should > I add, besides my own? I think everybody has replied with a tag as of now. Simon ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH wayland-protocols] unstable: add xdg-primary-selection protocol
This primary selection is similar in spirit to the eponimous in X11, allowing a quick "select text + middle click" shortcut to copying and pasting. It's otherwise very similar to its Yayland counterpart, and explicitly made consistent with it. Signed-off-by: Simon Ser --- This is a continuation of [1]. This protocol was pretty close to being accepted. I've chosen to put the xdg prefix because this primary selection is mostly relevant to desktop compositors. I've added myself as maintainer, Carlos and Lyude let me know if you want to replace me or be added to the list too. [1]: https://lists.freedesktop.org/archives/wayland-devel/2016-February/027101.html Makefile.am | 3 +- unstable/xdg-primary-selection/README | 4 + .../xdg-primary-selection-unstable-v1.xml | 225 ++ 3 files changed, 231 insertions(+), 1 deletion(-) create mode 100644 unstable/xdg-primary-selection/README create mode 100644 unstable/xdg-primary-selection/xdg-primary-selection-unstable-v1.xml diff --git a/Makefile.am b/Makefile.am index 2b59d34..66a65af 100644 --- a/Makefile.am +++ b/Makefile.am @@ -19,7 +19,8 @@ unstable_protocols = \ unstable/keyboard-shortcuts-inhibit/keyboard-shortcuts-inhibit-unstable-v1.xml \ unstable/xdg-output/xdg-output-unstable-v1.xml \ unstable/input-timestamps/input-timestamps-unstable-v1.xml \ - unstable/xdg-decoration/xdg-decoration-unstable-v1.xml \ + unstable/xdg-decoration/xdg-decoration-unstable-v1.xml \ + unstable/xdg-primary-selection/xdg-primary-selection-unstable-v1.xml \ $(NULL) stable_protocols = \ diff --git a/unstable/xdg-primary-selection/README b/unstable/xdg-primary-selection/README new file mode 100644 index 000..ae0a402 --- /dev/null +++ b/unstable/xdg-primary-selection/README @@ -0,0 +1,4 @@ +Primary selection protocol + +Maintainers: +Simon Ser diff --git a/unstable/xdg-primary-selection/xdg-primary-selection-unstable-v1.xml b/unstable/xdg-primary-selection/xdg-primary-selection-unstable-v1.xml new file mode 100644 index 000..eb97425 --- /dev/null +++ b/unstable/xdg-primary-selection/xdg-primary-selection-unstable-v1.xml @@ -0,0 +1,225 @@ + + + +Copyright © 2015, 2016 Red Hat + +Permission is hereby granted, free of charge, to any person obtaining a +copy of this software and associated documentation files (the "Software"), +to deal in the Software without restriction, including without limitation +the rights to use, copy, modify, merge, publish, distribute, sublicense, +and/or sell copies of the Software, and to permit persons to whom the +Software is furnished to do so, subject to the following conditions: + +The above copyright notice and this permission notice (including the next +paragraph) shall be included in all copies or substantial portions of the +Software. + +THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR +IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, +FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL +THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER +LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING +FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER +DEALINGS IN THE SOFTWARE. + + + +This protocol provides the ability to have a primary selection device to +match that of the X server. This primary selection is a shortcut to the +common clipboard selection, where text just needs to be selected in order +to allow copying it elsewhere. The de facto way to perform this action +is the middle mouse button, although it is not limited to this one. + +Clients wishing to honor primary selection should create a primary +selection source and set it as the selection through +xdg_primary_selection_device.set_selection whenever the text selection +changes. In order to minimize calls in pointer-driven text selection, +it should happen only once after the operation finished. Similarly, +a NULL source should be set when text is unselected. + +xdg_primary_selection_offer objects are first announced through the +xdg_primary_selection_device.data_offer event. Immediately after this event, +the primary data offer will emit xdg_primary_selection_offer.offer events +to let know of the mime types being offered. + +When the primary selection changes, the client with the keyboard focus +will receive xdg_primary_selection_device.selection events. Only the client +with the keyboard focus will receive such events with a non-NULL +xdg_primary_selection_offer. Across keyboard f
Re: [PATCH wayland-protocols] xdg-output: add a transform example for the logical size
Bump: this is the source of bugs in xwayland [1]. [1]: https://lists.x.org/archives/xorg-devel/2018-July/057285.html On May 18, 2018 9:40 PM, Simon Ser wrote: > Signed-off-by: Simon Ser > --- > > I believe it's easy to understand that transformations are not applied to > the logical size. > > unstable/xdg-output/xdg-output-unstable-v1.xml | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/unstable/xdg-output/xdg-output-unstable-v1.xml > b/unstable/xdg-output/xdg-output-unstable-v1.xml > index bd9a8a8..320c0a0 100644 > --- a/unstable/xdg-output/xdg-output-unstable-v1.xml > +++ b/unstable/xdg-output/xdg-output-unstable-v1.xml > @@ -135,6 +135,9 @@ > - A compositor using a fractional scale of 1.5 will advertise a > logical size to 2560×1620. > > + For example, for a wl_output mode 1920×1080 and a 90 degree rotation, > the > + compositor will advertise a logical size of 1080x1920. > + > The logical_size event is sent after creating an xdg_output > (see xdg_output_manager.get_xdg_output) and whenever the logical > size of the output changes, either as a result of a change in the > -- > 2.17.0 > > > ___ > 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: [PATCH v2 0/3] Change wording in xdg-shell stable
Hi Jonas, What do you think of these patches? Thanks, Simon On June 29, 2018 11:12 AM, wrote: > From: Markus Ongyerth w...@ongy.net > > Hi, > > This is a v2 of a rather old patch series I more or less forgot about [1]. > > The previous version of patch 1 is [2] > The patch 2 and 3 are based on are: [3] > > Patch 1 should still be quite straight forward. > Patch 2 is the well received part of the previous Patch 2. > > Patch 3 on the other hand is probably more controversial. > It's the not-so-well received part of the previous Patch 2, worked out > properly > and supplied with reasoning why I think that the changes are necessary. > > I would have prefered to submit #3 independent of the other two, since 1 and 2 > should not be held up for problems on the third one, but it changes the same > sections as Patch2, so I can't do that. > > cheers, > Ongy > > [1] > https://lists.freedesktop.org/archives/wayland-devel/2018-February/037248.html > [2] > https://lists.freedesktop.org/archives/wayland-devel/2018-February/037249.html > [3] > https://lists.freedesktop.org/archives/wayland-devel/2018-February/037250.html > > Markus Ongyerth (3): > xdg-shell: move maximized state definition together > xdg-shell: Make sure wording reflects expectations > xdg-shell: Give compositor control over configure > > stable/xdg-shell/xdg-shell.xml | 78 -- > 1 file changed, 45 insertions(+), 33 deletions(-) > > --- > 2.18.0 > > 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: [PATCH v4 wayland-protocols] virtual-keyboard: Add new virtual keyboard protocol
> Provides the ability to emulate keyboards by applications. Complementary to > input-method protocol. > > The interface is a mirror copy of wl_keyboard, with removed serials, and added > seat binding. > > --- > > Hello, > > thank you for giving me a lot of useful feedback in the last round. I applied > the suggestions and this is the new incarnation of the protocol. Changes to > v3, > in no particular order: > > - added clarification to the destructor namespaced enum references made > virtual > - keyboard creation non-fatal > > The responses about keeping a virtual keyboard on a separate connection and > about using protocol errors as part of the authentication mechanism were all > in > agreement, and they made sense to me too. As a result, there is a whole new > mechanism for that. > > The client now requests a creation of a virtual keyboard, but does not > immediately get a valid instance. It must wait for one of two events in > virtual_keyboard_manager: `virtual_keyboard_create_failed` for a failure or > `virtual_keyboard_created` for success. I deliberately kept them inside the > manager instead of virtual_keyboard, since I don't like the idea of creating > an > object and immediately sending a message that it's useless (in case of > failure). > > I also deliberately kept the names long in order not to forget what's being > manipulated. > > The serial number is there to match up requests on different seats with > failures. I imagine that a compositor might spam the user(s) with a number of > permission requests for different seats, and the user would deal with them in > a > random order. Serials prevent the answers from getting mixed up. > > I am not happy only with one aspect of this: the amount of time between create > request and response is indefinite, opening a loophole for the compositor > never > to reply. I decided that it doesn't warrant a protocol error however. > > As usual, feedback is welcome. Hi, Sorry for the delay. I'm not sure I like this new design. First, this is using server-side created resources (the a `new_id` argument in an event). One should be really careful when doing so, see Pekka's post on the matter [1]. Then, this serial mechanism makes me uneasy. A more idiomatic approach would be to use a proper object for this. Finally, I'm not even sure this security mechanism belongs here. I think adding this mechanism to potentially all privileged protocols will result in duplicated code and "pollutes" protocols. Here are some other solutions: * Have one keyboard daemon they spawn themselves. In this case they can only expose this interface on the daemon's display. This is e.g. weston's approach for its private protocols, and will be sway's approach for privileged protocols. * Allow other clients to use this interface too, but don't let them know if the keyboard they created is active or is ignored. This could possibly lead to bad UX. * Allow other clients to use this interface too, and use another protocol to manage authorizations. Basically the idea would be not to expose this interface, and require the client to request access to this privileged interface through an authorizer protocol. Someone already mentioned it, this is Orbital's approach [2]. This allows the compositor to spawn a dialog asking to the user "do you want to allow to create a virtual keyboard?". What do you think? An event on the keyboard to signal when the keyboard is no longer active (ie. when the compositor decides to destroy it) might still be useful, maybe. Everything else looks good to me. Thanks for your work! Simon [1]: http://ppaalanen.blogspot.com/2014/07/wayland-protocol-design-object-lifespan.html [2]: https://github.com/giucam/orbital/blob/master/protocol/orbital-authorizer.xml > Cheers, > Dorota Czaplejewicz > > Makefile.am| 1 + > unstable/virtual-keyboard/README | 2 + > .../virtual-keyboard-unstable-v1.xml | 154 > + > 3 files changed, 157 insertions(+) > create mode 100644 unstable/virtual-keyboard/README > create mode 100644 unstable/virtual-keyboard/virtual-keyboard-unstable-v1.xml > > diff --git a/Makefile.am b/Makefile.am > index 1aa13cf..17cedc1 100644 > --- a/Makefile.am > +++ b/Makefile.am > @@ -19,6 +19,7 @@ unstable_protocols = > \ > > unstable/keyboard-shortcuts-inhibit/keyboard-shortcuts-inhibit-unstable-v1.xml > \ > unstable/xdg-output/xdg-output-unstable-v1.xml > \ > unstable/input-timestamps/input-timestamps-unstable-v1.xml \ > + unstable/virtual-keyboard/virtual-keyboard-unstable-v1.xml \ > $(NULL) > > stable_protocols = > \ > diff --git a/unstable/virtual-keyboard/README > b/unstable/virtual-keyboard/README > new file mode 100644 > index 000..a2c
Re: [PATCH] protocol: allow to send a zero physical output size
Hi all, I'd like to bump this, because it seems that's how they do it on the X11 side [1]. So adding this would allow to have better Wayland behaviour _and_ correct X11 screen data via Xwayland. Thanks, [1]: https://lists.x.org/archives/xorg-devel/2018-July/057301.html On July 3, 2018 12:27 PM, Simon Ser wrote: > Physical size doesn't always make sense for all outputs. In case > it's not available or not relevant, allow compositors to send zero. > --- > In practice this doesn't seem to break any client toolkit. We've been > doing that for a long time in wlroots. > > protocol/wayland.xml | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/protocol/wayland.xml b/protocol/wayland.xml > index b5662e0..141038b 100644 > --- a/protocol/wayland.xml > +++ b/protocol/wayland.xml > @@ -2399,6 +2399,9 @@ > The geometry event describes geometric properties of the output. > The event is sent when binding to the output object and whenever > any of the properties change. > + > + The physical size can be set to zero if it doesn't make sense for this > + output (e.g. for projectors or virtual outputs). > > summary="x position within the global compositor space"/> > -- > 2.18.0 > > > ___ > 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] server: add wl_signal_emit_safe
This new function allows listeners to remove themselves or any
other listener when called. This version only works if listeners
are properly cleaned up when the wl_signal is free'd.
Signed-off-by: Simon Ser
---
This is a [1] follow-up. Since we noticed the previous version is
not a drop-in replacement for wl_signal_emit, this patch just adds
a new function instead.
[1]: https://patchwork.freedesktop.org/patch/204641/
src/wayland-server-core.h | 3 ++
src/wayland-server.c | 47 +
tests/signal-test.c | 86 +++
3 files changed, 136 insertions(+)
diff --git a/src/wayland-server-core.h b/src/wayland-server-core.h
index 2e725d9..4a2948a 100644
--- a/src/wayland-server-core.h
+++ b/src/wayland-server-core.h
@@ -468,6 +468,9 @@ wl_signal_emit(struct wl_signal *signal, void *data)
l->notify(l, data);
}
+void
+wl_signal_emit_safe(struct wl_signal *signal, void *data);
+
typedef void (*wl_resource_destroy_func_t)(struct wl_resource *resource);
/*
diff --git a/src/wayland-server.c b/src/wayland-server.c
index eae8d2e..a5f3735 100644
--- a/src/wayland-server.c
+++ b/src/wayland-server.c
@@ -1932,6 +1932,53 @@ wl_client_for_each_resource(struct wl_client *client,
wl_map_for_each(&client->objects, resource_iterator_helper, &context);
}
+static void
+handle_noop(struct wl_listener *listener, void *data) {
+ /* Do nothing */
+}
+
+/** Emits this signal, safe against removal of any listener.
+ *
+ * \note This function can only be used if listeners are properly removed when
+ * the wl_signal is free'd.
+ *
+ * \param signal The signal object that will emit the signal
+ * \param data The data that will be emitted with the signal
+ *
+ * \sa wl_signal_emit()
+ *
+ * \memberof wl_signal
+ */
+WL_EXPORT void
+wl_signal_emit_safe(struct wl_signal *signal, void *data) {
+ struct wl_listener cursor;
+ struct wl_listener end;
+
+ /* Add two special markers: one cursor and one end marker. This way, we
know
+* that we've already called listeners on the left of the cursor and
that we
+* don't want to call listeners on the right of the end marker. The 'it'
+* function can remove any element it wants from the list without
troubles.
+* wl_list_for_each_safe tries to be safe but it fails: it works fine
+* if the current item is removed, but not if the next one is. */
+ wl_list_insert(&signal->listener_list, &cursor.link);
+ cursor.notify = handle_noop;
+ wl_list_insert(signal->listener_list.prev, &end.link);
+ end.notify = handle_noop;
+
+ while (cursor.link.next != &end.link) {
+ struct wl_list *pos = cursor.link.next;
+ struct wl_listener *l = wl_container_of(pos, l, link);
+
+ wl_list_remove(&cursor.link);
+ wl_list_insert(pos, &cursor.link);
+
+ l->notify(l, data);
+ }
+
+ wl_list_remove(&cursor.link);
+ wl_list_remove(&end.link);
+}
+
/** \cond INTERNAL */
/** Initialize a wl_priv_signal object
diff --git a/tests/signal-test.c b/tests/signal-test.c
index 7bbaa9f..dc762a4 100644
--- a/tests/signal-test.c
+++ b/tests/signal-test.c
@@ -115,3 +115,89 @@ TEST(signal_emit_to_more_listeners)
assert(3 * counter == count);
}
+
+struct signal
+{
+ struct wl_signal signal;
+ struct wl_listener l1, l2, l3;
+ int count;
+ struct wl_listener *current;
+};
+
+static void notify_remove(struct wl_listener *l, void *data)
+{
+ struct signal *sig = data;
+ wl_list_remove(&sig->current->link);
+ wl_list_init(&sig->current->link);
+ sig->count++;
+}
+
+#define INIT \
+ wl_signal_init(&signal.signal); \
+ wl_list_init(&signal.l1.link); \
+ wl_list_init(&signal.l2.link); \
+ wl_list_init(&signal.l3.link);
+#define CHECK_EMIT(expected) \
+ signal.count = 0; \
+ wl_signal_emit_safe(&signal.signal, &signal); \
+ assert(signal.count == expected);
+
+TEST(signal_remove_listener)
+{
+ test_set_timeout(4);
+
+ struct signal signal;
+
+ signal.l1.notify = notify_remove;
+ signal.l2.notify = notify_remove;
+ signal.l3.notify = notify_remove;
+
+ INIT
+ wl_signal_add(&signal.signal, &signal.l1);
+
+ signal.current = &signal.l1;
+ CHECK_EMIT(1)
+ CHECK_EMIT(0)
+
+ INIT
+ wl_signal_add(&signal.signal, &signal.l1);
+ wl_signal_add(&signal.signal, &signal.l2);
+
+ CHECK_EMIT(2)
+ CHECK_EMIT(1)
+
+ INIT
+ wl_signal_add(&signal.signal, &signal.l1);
+ wl_signal_add(&signal.signal, &signal.l2);
+
+ signal.current = &signal.l2;
+ CHECK_EMIT(1)
+ CHECK_EMIT(1)
+
+ IN
Re: [PATCH wayland-protocols] unstable: add xdg-primary-selection protocol
Hi Jonas, What do you think of this proposal? (It's basically the GTK protocol with some prefix changes) Thanks, Simon On July 8, 2018 8:14 PM, Simon Ser wrote: > This primary selection is similar in spirit to the eponymous > in X11, allowing a quick "select text + middle click" shortcut > to copying and pasting. > > It's otherwise very similar to its Wayland counterpart, and > explicitly made consistent with it. > > Signed-off-by: Simon Ser > --- > This is a continuation of [1]. This protocol was pretty close to being > accepted. > > I've chosen to put the xdg prefix because this primary selection is mostly > relevant > to desktop compositors. > > I've added myself as maintainer, Carlos and Lyude let me know if you want to > replace > me or be added to the list too. > > [1]: > https://lists.freedesktop.org/archives/wayland-devel/2016-February/027101.html > > Makefile.am | 3 +- > unstable/xdg-primary-selection/README | 4 + > .../xdg-primary-selection-unstable-v1.xml | 225 ++ > 3 files changed, 231 insertions(+), 1 deletion(-) > create mode 100644 unstable/xdg-primary-selection/README > create mode 100644 > unstable/xdg-primary-selection/xdg-primary-selection-unstable-v1.xml > > diff --git a/Makefile.am b/Makefile.am > index 2b59d34..66a65af 100644 > --- a/Makefile.am > +++ b/Makefile.am > @@ -19,7 +19,8 @@ unstable_protocols = > \ > > unstable/keyboard-shortcuts-inhibit/keyboard-shortcuts-inhibit-unstable-v1.xml > \ > unstable/xdg-output/xdg-output-unstable-v1.xml > \ > unstable/input-timestamps/input-timestamps-unstable-v1.xml \ > - unstable/xdg-decoration/xdg-decoration-unstable-v1.xml \ > + unstable/xdg-decoration/xdg-decoration-unstable-v1.xml \ > + unstable/xdg-primary-selection/xdg-primary-selection-unstable-v1.xml > \ > $(NULL) > > stable_protocols = > \ > diff --git a/unstable/xdg-primary-selection/README > b/unstable/xdg-primary-selection/README > new file mode 100644 > index 000..ae0a402 > --- /dev/null > +++ b/unstable/xdg-primary-selection/README > @@ -0,0 +1,4 @@ > +Primary selection protocol > + > +Maintainers: > +Simon Ser > diff --git > a/unstable/xdg-primary-selection/xdg-primary-selection-unstable-v1.xml > b/unstable/xdg-primary-selection/xdg-primary-selection-unstable-v1.xml > new file mode 100644 > index 000..eb97425 > --- /dev/null > +++ b/unstable/xdg-primary-selection/xdg-primary-selection-unstable-v1.xml > @@ -0,0 +1,225 @@ > + > + > + > +Copyright © 2015, 2016 Red Hat > + > +Permission is hereby granted, free of charge, to any person obtaining a > +copy of this software and associated documentation files (the > "Software"), > +to deal in the Software without restriction, including without limitation > +the rights to use, copy, modify, merge, publish, distribute, sublicense, > +and/or sell copies of the Software, and to permit persons to whom the > +Software is furnished to do so, subject to the following conditions: > + > +The above copyright notice and this permission notice (including the next > +paragraph) shall be included in all copies or substantial portions of the > +Software. > + > +THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS > OR > +IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, > +FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL > +THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR > OTHER > +LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING > +FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER > +DEALINGS IN THE SOFTWARE. > + > + > + > +This protocol provides the ability to have a primary selection device to > +match that of the X server. This primary selection is a shortcut to the > +common clipboard selection, where text just needs to be selected in order > +to allow copying it elsewhere. The de facto way to perform this action > +is the middle mouse button, although it is not limited to this one. > + > +Clients wishing to honor primary selection should create a primary > +selection source and set it as the selection through > +xdg_primary_selection_device.set_selection whenever the text selection > +changes. In order to minimize cal
Re: [PATCH wayland-protocols] xdg-output: add a transform example for the logical size
Hi Jonas, What do you think of this patch? Thanks, Simon On July 9, 2018 3:25 PM, Olivier Fourdan wrote: > Hi, > > On Mon, 9 Jul 2018 at 11:09, Simon Ser wrote: > > > > Bump: this is the source of bugs in xwayland [1]. > > > > [1]: https://lists.x.org/archives/xorg-devel/2018-July/057285.html > > > > On May 18, 2018 9:40 PM, Simon Ser wrote: > > > Signed-off-by: Simon Ser > > > --- > > > > > > I believe it's easy to understand that transformations are not applied to > > > the logical size. > > > > > > unstable/xdg-output/xdg-output-unstable-v1.xml | 3 +++ > > > 1 file changed, 3 insertions(+) > > > > > > diff --git a/unstable/xdg-output/xdg-output-unstable-v1.xml > > > b/unstable/xdg-output/xdg-output-unstable-v1.xml > > > index bd9a8a8..320c0a0 100644 > > > --- a/unstable/xdg-output/xdg-output-unstable-v1.xml > > > +++ b/unstable/xdg-output/xdg-output-unstable-v1.xml > > > @@ -135,6 +135,9 @@ > > > - A compositor using a fractional scale of 1.5 will advertise a > > > logical size to 2560×1620. > > > > > > + For example, for a wl_output mode 1920×1080 and a 90 degree > > > rotation, the > > > + compositor will advertise a logical size of 1080x1920. > > > + > > > The logical_size event is sent after creating an xdg_output > > > (see xdg_output_manager.get_xdg_output) and whenever the logical > > > size of the output changes, either as a result of a change in the > > > -- > > > 2.17.0 > > Reviewed-by: Olivier Fourdan > > That r-b doesn't apply to the Xwayland patch though, to which I 'll > reply in the relevant thread. > > Cheers, > Olivier ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH v3 1/3] xdg-shell: move maximized state definition together
On July 20, 2018 10:09 AM, wrote: > From: Markus Ongyerth > > The xdg-shell documentation had part of the maximized state render > implications in the `set_maximized` request documentation, not the > actual state. > This moves the relevant lines into the state description. > > Signed-off-by: Markus Ongyerth > Reviewed-By: Mike Blumenkrantz Reviewed-By: Simon Ser > --- > stable/xdg-shell/xdg-shell.xml | 6 -- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/stable/xdg-shell/xdg-shell.xml b/stable/xdg-shell/xdg-shell.xml > index ad96fe8..213b227 100644 > --- a/stable/xdg-shell/xdg-shell.xml > +++ b/stable/xdg-shell/xdg-shell.xml > @@ -724,6 +724,9 @@ > > The surface is maximized. The window geometry specified in the > configure > event must be obeyed by the client. > + > + The client should draw without shadow or other > + decoration outside of the window geometry. > > > > @@ -865,8 +868,7 @@ > After requesting that the surface should be maximized, the compositor > will respond by emitting a configure event with the "maximized" state > and the required window geometry. The client should then update its > - content, drawing it in a maximized state, i.e. without shadow or other > - decoration outside of the window geometry. The client must also > + content, drawing it in a maximized state. The client must also > acknowledge the configure when committing the new content (see > ack_configure). > > -- > 2.18.0 > > ___ > 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: [PATCH v3 2/3] xdg-shell: Make sure wording reflects expectations
On July 20, 2018 10:09 AM, wrote: > From: Markus Ongyerth > > The wording in xdg-shell's `set_*` requests implies the compositor > *will* honour the client's request. > This would give clients the control over their actual state, while the > general expectation is that clients kindly ask for state changes which > the compositor may follow. > This patch ensures the actual protocol text reflects these expectations. Reviewed-By: Simon Ser > --- > stable/xdg-shell/xdg-shell.xml | 45 +- > 1 file changed, 23 insertions(+), 22 deletions(-) > > diff --git a/stable/xdg-shell/xdg-shell.xml b/stable/xdg-shell/xdg-shell.xml > index 213b227..08708dd 100644 > --- a/stable/xdg-shell/xdg-shell.xml > +++ b/stable/xdg-shell/xdg-shell.xml > @@ -866,11 +866,11 @@ > Maximize the surface. > > After requesting that the surface should be maximized, the compositor > - will respond by emitting a configure event with the "maximized" state > - and the required window geometry. The client should then update its > - content, drawing it in a maximized state. The client must also > - acknowledge the configure when committing the new content (see > - ack_configure). > + will respond by emitting a configure event. Whether this configure > + actually sets the window maximized is subject to compositor policies. > + The client must then update its content, drawing in the configured > + state. The client must also acknowledge the configure when committing > + the new content (see ack_configure). > > It is up to the compositor to decide how and where to maximize the > surface, for example which output and what region of the screen should > @@ -880,8 +880,8 @@ > a configure event with the "maximized" state. > > If the surface is in a fullscreen state, this request has no direct > - effect. It will alter the state the surface is returned to when > - unmaximized if not overridden by the compositor. > + effect. It may alter the state the surface is returned to when > + unmaximized unless overridden by the compositor. > > > > @@ -890,13 +890,13 @@ > Unmaximize the surface. > > After requesting that the surface should be unmaximized, the compositor > - will respond by emitting a configure event without the "maximized" > - state. If available, the compositor will include the window geometry > - dimensions the window had prior to being maximized in the configure > - event. The client must then update its content, drawing it in a > - regular state, i.e. potentially with shadow, etc. The client must also > - acknowledge the configure when committing the new content (see > - ack_configure). > + will respond by emitting a configure event. Whether this actually > + un-maximizes the window is subject to compositor policies. > + If available and applicable, the compositor will include the window > + geometry dimensions the window had prior to being maximized in the > + configure event. The client must then update its content, drawing it in > + the configured state. The client must also acknowledge the configure > + when committing the new content (see ack_configure). > > It is up to the compositor to position the surface after it was > unmaximized; usually the position the surface had before maximizing, if > @@ -906,8 +906,8 @@ > emit a configure event without the "maximized" state. > > If the surface is in a fullscreen state, this request has no direct > - effect. It will alter the state the surface is returned to when > - unmaximized if not overridden by the compositor. > + effect. It may alter the state the surface is returned to when > + unmaximized unless overridden by the compositor. > > > > @@ -916,10 +916,10 @@ > Make the surface fullscreen. > > After requesting that the surface should be fullscreened, the > - compositor will respond by emitting a configure event with the > - "fullscreen" state and the fullscreen window geometry. The client must > - also acknowledge the configure when committing the new content (see > - ack_configure). > + compositor will respond by emitting a configure event. Whether the > + client is actually put into a fullscreen state is subject to compositor > + policies. The client must also acknowledge the configure when > + committing the new content (see ack_configure). > > The output passed by the request indicates the client's preference as > to which display it shou
Re: [PATCH] protocol: allow to send a zero physical output size
On July 13, 2018 12:00 PM, Daniel Stone wrote: > Hi, > > On Tue, 3 Jul 2018 at 12:27, Simon Ser wrote: > > Physical size doesn't always make sense for all outputs. In case > > it's not available or not relevant, allow compositors to send zero. > > --- > > In practice this doesn't seem to break any client toolkit. We've been > > doing that for a long time in wlroots. > > Seems legitimate to me. I'd like to hear if anyone else touching > output has thoughts, but this is: > Acked-by: Daniel Stone Hi, Thanks for the ack. Olivier, Jonas, do you have opinions about this? Thanks, > Cheers, > Daniel > ___ > 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: [PATCH wayland-protocols] unstable: add xdg-primary-selection protocol
Hi Jonas, Any thoughts about this? Thanks, Simon On July 15, 2018 7:36 PM, Simon Ser wrote: > Hi Jonas, > > What do you think of this proposal? (It's basically the GTK protocol with > some prefix changes) > > Thanks, > > Simon > > On July 8, 2018 8:14 PM, Simon Ser wrote: > > This primary selection is similar in spirit to the eponymous > > in X11, allowing a quick "select text + middle click" shortcut > > to copying and pasting. > > > > It's otherwise very similar to its Wayland counterpart, and > > explicitly made consistent with it. > > > > Signed-off-by: Simon Ser > > --- > > This is a continuation of [1]. This protocol was pretty close to being > > accepted. > > > > I've chosen to put the xdg prefix because this primary selection is mostly > > relevant > > to desktop compositors. > > > > I've added myself as maintainer, Carlos and Lyude let me know if you want > > to replace > > me or be added to the list too. > > > > [1]: > > https://lists.freedesktop.org/archives/wayland-devel/2016-February/027101.html > > > > Makefile.am | 3 +- > > unstable/xdg-primary-selection/README | 4 + > > .../xdg-primary-selection-unstable-v1.xml | 225 ++ > > 3 files changed, 231 insertions(+), 1 deletion(-) > > create mode 100644 unstable/xdg-primary-selection/README > > create mode 100644 > > unstable/xdg-primary-selection/xdg-primary-selection-unstable-v1.xml > > > > diff --git a/Makefile.am b/Makefile.am > > index 2b59d34..66a65af 100644 > > --- a/Makefile.am > > +++ b/Makefile.am > > @@ -19,7 +19,8 @@ unstable_protocols = > > \ > > > > unstable/keyboard-shortcuts-inhibit/keyboard-shortcuts-inhibit-unstable-v1.xml > > \ > > unstable/xdg-output/xdg-output-unstable-v1.xml > > \ > > unstable/input-timestamps/input-timestamps-unstable-v1.xml \ > > - unstable/xdg-decoration/xdg-decoration-unstable-v1.xml \ > > + unstable/xdg-decoration/xdg-decoration-unstable-v1.xml \ > > + unstable/xdg-primary-selection/xdg-primary-selection-unstable-v1.xml > > \ > > $(NULL) > > > > stable_protocols = > > \ > > diff --git a/unstable/xdg-primary-selection/README > > b/unstable/xdg-primary-selection/README > > new file mode 100644 > > index 000..ae0a402 > > --- /dev/null > > +++ b/unstable/xdg-primary-selection/README > > @@ -0,0 +1,4 @@ > > +Primary selection protocol > > + > > +Maintainers: > > +Simon Ser > > diff --git > > a/unstable/xdg-primary-selection/xdg-primary-selection-unstable-v1.xml > > b/unstable/xdg-primary-selection/xdg-primary-selection-unstable-v1.xml > > new file mode 100644 > > index 000..eb97425 > > --- /dev/null > > +++ b/unstable/xdg-primary-selection/xdg-primary-selection-unstable-v1.xml > > @@ -0,0 +1,225 @@ > > + > > + > > + > > +Copyright © 2015, 2016 Red Hat > > + > > +Permission is hereby granted, free of charge, to any person obtaining a > > +copy of this software and associated documentation files (the > > "Software"), > > +to deal in the Software without restriction, including without > > limitation > > +the rights to use, copy, modify, merge, publish, distribute, > > sublicense, > > +and/or sell copies of the Software, and to permit persons to whom the > > +Software is furnished to do so, subject to the following conditions: > > + > > +The above copyright notice and this permission notice (including the > > next > > +paragraph) shall be included in all copies or substantial portions of > > the > > +Software. > > + > > +THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, > > EXPRESS OR > > +IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF > > MERCHANTABILITY, > > +FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT > > SHALL > > +THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR > > OTHER > > +LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING > > +FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER > > +DEALINGS IN THE SOFTWARE. > > + > > + > > + > > +This prot
Re: [PATCH v4 wayland-protocols] virtual-keyboard: Add new virtual keyboard protocol
On July 29, 2018 6:55 PM, Dorota Czaplejewicz wrote: > On Tue, 24 Jul 2018 15:10:29 +0200 > Dorota Czaplejewicz wrote: > > > On Thu, 12 Jul 2018 18:15:32 -0400 > > Simon Ser wrote: > > > > > Hi, > > > > > > Sorry for the delay. > > > > > > I'm not sure I like this new design. > > > > > > Finally, I'm not even sure this security mechanism belongs here. I think > > > adding > > > this mechanism to potentially all privileged protocols will result in > > > duplicated > > > code and "pollutes" protocols. Here are some other solutions: > > > > > --- snip --- > > > > * Allow other clients to use this interface too, and use another protocol > > > to > > > manage authorizations. Basically the idea would be not to expose this > > > interface, and require the client to request access to this privileged > > > interface through an authorizer protocol. Someone already mentioned it, > > > this > > > is Orbital's approach [2]. This allows the compositor to spawn a dialog > > > asking > > > to the user "do you want to allow to create a virtual > > > keyboard?". > > > > > > What do you think? > > > > > I'm in favor of option 3, which will be useful for other protocols as well, > > which are not necessarily in position to be kept in a permanent privileged > > process, e.g. screen recording. > > > > It would also make me happier as a protocol author, because the protocol > > becomes more compact and easier to maintain without explicit managing. > > > > Thinking a bit more about the topic, this patch with the authentication > features removed would end up exactly the same as patch v3. Patch v3 is > already implemented in wlroots too. > > Hereby I withdraw this update. Please refer to > 20180622152045.10563-1-dorota.czaplejew...@puri.sm which can be read here: > https://lists.freedesktop.org/archives/wayland-devel/2018-June/038629.html Hi, While the interfaces, requests and events are the same, there are some wording changes from v3 to v4 and some enum reference fixes: - added clarification to the destructor - namespaced enum references Is it possible to backport these changes to v3? Thanks, Simon > Regards, > Dorota Czaplejewicz ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH v10 wayland_protocols] text-input: Add v3 of the text-input protocol
On July 30, 2018 3:14 PM, Dorota Czaplejewicz wrote: > From: Carlos Garnacho > > This new protocol description is an evolution of v2. > > - All pre-edit text styling is gone. > - Pre-edit cursor can span characters. > - No events regarding input panel (OSK) state nor covered rectangle. > Compositors are still free to handle situations where the keyboard > focus rectangle is covered by the input panel. > - No set_preferred_language request for clients. > - There is no event to send keysyms. Compositors can use wl_keyboard > interface instead. > - All state is double-buffered, with specified defaults. > - The compositor can be notified about external changes to the state. > - The client can detect outdated requests. > > Signed-off-by: Dorota Czaplejewicz > Signed-off-by: Carlos Garnacho > --- > Hi, > > this patch applies most recent advice from Jonas. The changes are in commit > and done messages and spelled out in my previous email. > > Cheers, > Dorota > > Makefile.am| 1 + > unstable/text-input/text-input-unstable-v3.xml | 435 > + > 2 files changed, 436 insertions(+) > create mode 100644 unstable/text-input/text-input-unstable-v3.xml > > diff --git a/Makefile.am b/Makefile.am > index 4b9a901..86d7ca9 100644 > --- a/Makefile.am > +++ b/Makefile.am > @@ -3,6 +3,7 @@ unstable_protocols = > \ > unstable/fullscreen-shell/fullscreen-shell-unstable-v1.xml > \ > unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml > \ > unstable/text-input/text-input-unstable-v1.xml > \ > + unstable/text-input/text-input-unstable-v3.xml > \ > unstable/input-method/input-method-unstable-v1.xml > \ > unstable/xdg-shell/xdg-shell-unstable-v5.xml > \ > unstable/xdg-shell/xdg-shell-unstable-v6.xml > \ > diff --git a/unstable/text-input/text-input-unstable-v3.xml > b/unstable/text-input/text-input-unstable-v3.xml > new file mode 100644 > index 000..acf5674 > --- /dev/null > +++ b/unstable/text-input/text-input-unstable-v3.xml > @@ -0,0 +1,435 @@ > + > + > + > + > +Copyright © 2012, 2013 Intel Corporation > +Copyright © 2015, 2016 Jan Arne Petersen > +Copyright © 2017, 2018 Red Hat, Inc. > +Copyright © 2018 Purism SPC > + > +Permission to use, copy, modify, distribute, and sell this > +software and its documentation for any purpose is hereby granted > +without fee, provided that the above copyright notice appear in > +all copies and that both that copyright notice and this permission > +notice appear in supporting documentation, and that the name of > +the copyright holders not be used in advertising or publicity > +pertaining to distribution of the software without specific, > +written prior permission. The copyright holders make no > +representations about the suitability of this software for any > +purpose. It is provided "as is" without express or implied > +warranty. > + > +THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS > +SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND > +FITNESS, IN NO EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY > +SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES > +WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN > +AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, > +ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF > +THIS SOFTWARE. > + > + > + > + > + The zwp_text_input_v3 interface represents text input and input methods > + associated with a seat. It provides enter/leave events to follow the > + text input focus for a seat. > + > + Requests are used to enable/disable the text-input object and set > + state information like surrounding and selected text or the content > type. > + The information about the entered text is sent to the text-input object > + via the preedit_string and commit_string events. > + > + Text is valid UTF-8 encoded, indices and lengths are in bytes. Indices > + must not point to middle bytes inside a code point: they must either > + point to the first byte of a code point or to the end of the buffer. > + Lengths must be measured between two valid indices. > + > + Focus moving throughout surfaces will result in the emission of > + zwp_text_input_v3.enter and zwp_text_input_v3.leave events. The focused > + surface must commit zwp_text_input_v3.enable and > + zwp_text_input_v3.disable requests as the keyboard focus moves across > + editable and non-editable elements of the UI. Those two requests are > not > + expected to be paired with each other, the compositor m
Re: [PATCH wayland-protocols 1/2] tests: Use public-code and private-code instead of code
On July 30, 2018 4:10 PM, Jonas Ådahl wrote: > The wayland-scanner sub-commands private-code and public-code replaced > the old code command, so lets use those in the tests instead. > > Signed-off-by: Jonas Ådahl LGTM and works. Reviewed-by: Simon Ser > --- > tests/scan.sh | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/tests/scan.sh b/tests/scan.sh > index 15dd39f..0b1ff00 100755 > --- a/tests/scan.sh > +++ b/tests/scan.sh > @@ -7,4 +7,5 @@ fi > > $SCANNER client-header $1 /dev/null > $SCANNER server-header $1 /dev/null > -$SCANNER code $1 /dev/null > +$SCANNER private-code $1 /dev/null > +$SCANNER public-code $1 /dev/null > -- > 2.17.1 > > ___ > 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: [PATCH wayland-protocols 2/2] tests: Make wayland-scanner strict
On July 30, 2018 4:10 PM, Jonas Ådahl wrote: > Pass --strict to wayland-scanner in order to make it exit with failure > if something wasn't correct. > > Signed-off-by: Jonas Ådahl LGTM and catches the inside issue. Reviewed-by: Simon Ser > --- > tests/scan.sh | 8 > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/tests/scan.sh b/tests/scan.sh > index 0b1ff00..cad6887 100755 > --- a/tests/scan.sh > +++ b/tests/scan.sh > @@ -5,7 +5,7 @@ if [ "x$SCANNER" = "x" ] ; then > exit 77 > fi > > -$SCANNER client-header $1 /dev/null > -$SCANNER server-header $1 /dev/null > -$SCANNER private-code $1 /dev/null > -$SCANNER public-code $1 /dev/null > +$SCANNER client-header --strict $1 /dev/null > +$SCANNER server-header --strict $1 /dev/null > +$SCANNER private-code --strict $1 /dev/null > +$SCANNER public-code --strict $1 /dev/null > -- > 2.17.1 > > ___ > 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: [PATCH v11 wayland_protocols] text-input: Add v3 of the text-input protocol
> From: Carlos Garnacho > > This new protocol description is an evolution of v2. > > - All pre-edit text styling is gone. > - Pre-edit cursor can span characters. > - No events regarding input panel (OSK) state nor covered rectangle. > Compositors are still free to handle situations where the keyboard > focus rectangle is covered by the input panel. > - No set_preferred_language request for clients. > - There is no event to send keysyms. Compositors can use wl_keyboard > interface instead. > - All state is double-buffered, with specified defaults. > - The compositor can be notified about external changes to the state. > - The client can detect outdated requests. > > Signed-off-by: Dorota Czaplejewicz > Signed-off-by: Carlos Garnacho > --- > Hi, > > this version adds a short protocol description and moves some text from > text_input description there (most of it is still directly relevant to > text_input only). > > It also fixes the done argument by placing it outside the description. > > --Dorota Nice work. This is: Reviewed-by: Simon Ser > Makefile.am| 1 + > unstable/text-input/text-input-unstable-v3.xml | 441 > + > 2 files changed, 442 insertions(+) > create mode 100644 unstable/text-input/text-input-unstable-v3.xml > > diff --git a/Makefile.am b/Makefile.am > index 4b9a901..86d7ca9 100644 > --- a/Makefile.am > +++ b/Makefile.am > @@ -3,6 +3,7 @@ unstable_protocols = > \ > unstable/fullscreen-shell/fullscreen-shell-unstable-v1.xml > \ > unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml > \ > unstable/text-input/text-input-unstable-v1.xml > \ > + unstable/text-input/text-input-unstable-v3.xml > \ > unstable/input-method/input-method-unstable-v1.xml > \ > unstable/xdg-shell/xdg-shell-unstable-v5.xml > \ > unstable/xdg-shell/xdg-shell-unstable-v6.xml > \ > diff --git a/unstable/text-input/text-input-unstable-v3.xml > b/unstable/text-input/text-input-unstable-v3.xml > new file mode 100644 > index 000..95af0e2 > --- /dev/null > +++ b/unstable/text-input/text-input-unstable-v3.xml > @@ -0,0 +1,441 @@ > + > + > + > + > +Copyright © 2012, 2013 Intel Corporation > +Copyright © 2015, 2016 Jan Arne Petersen > +Copyright © 2017, 2018 Red Hat, Inc. > +Copyright © 2018 Purism SPC > + > +Permission to use, copy, modify, distribute, and sell this > +software and its documentation for any purpose is hereby granted > +without fee, provided that the above copyright notice appear in > +all copies and that both that copyright notice and this permission > +notice appear in supporting documentation, and that the name of > +the copyright holders not be used in advertising or publicity > +pertaining to distribution of the software without specific, > +written prior permission. The copyright holders make no > +representations about the suitability of this software for any > +purpose. It is provided "as is" without express or implied > +warranty. > + > +THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS > +SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND > +FITNESS, IN NO EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY > +SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES > +WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN > +AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, > +ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF > +THIS SOFTWARE. > + > + > + > +This protocol allows compositors to act as input methods and to send text > +to applications. A text input object is used to manage state of what are > +typically text entry fields in the application. > + > +This document adheres to the RFC 2119 when using words like "must", > +"should", "may", etc. > + > +Warning! The protocol described in this file is experimental and > +backward incompatible changes may be made. Backward compatible changes > +may be added together with the corresponding interface version bump. > +Backward incompatible changes are done by bumping the version number in > +the protocol and interface names and resetting the interface version. > +Once the protocol is to be declared stable, the 'z' prefix and the > +
Re: [PATCH v6 wayland-protocols] virtual-keyboard: Add new virtual keyboard protocol
On August 3, 2018 6:12 PM, Dorota Czaplejewicz wrote: > Provides the ability to emulate keyboards by applications. Complementary to > input-method protocol. > > The interface is a mirror copy of wl_keyboard, with removed serials, and > added seat binding. > --- > Hello, > > this is the change I wanted to send previously (sorry). > > Regards, > Dorota Czaplejewicz Thanks for this update! Reviewed-by: Simon Ser > Makefile.am| 1 + > unstable/virtual-keyboard/README | 2 + > .../virtual-keyboard-unstable-v1.xml | 114 > + > 3 files changed, 117 insertions(+) > create mode 100644 unstable/virtual-keyboard/README > create mode 100644 unstable/virtual-keyboard/virtual-keyboard-unstable-v1.xml > > diff --git a/Makefile.am b/Makefile.am > index 6394e26..d67aa1b 100644 > --- a/Makefile.am > +++ b/Makefile.am > @@ -20,6 +20,7 @@ unstable_protocols = > \ > > unstable/keyboard-shortcuts-inhibit/keyboard-shortcuts-inhibit-unstable-v1.xml > \ > unstable/xdg-output/xdg-output-unstable-v1.xml > \ > unstable/input-timestamps/input-timestamps-unstable-v1.xml \ > + unstable/virtual-keyboard/virtual-keyboard-unstable-v1.xml \ > unstable/xdg-decoration/xdg-decoration-unstable-v1.xml \ > $(NULL) > > diff --git a/unstable/virtual-keyboard/README > b/unstable/virtual-keyboard/README > new file mode 100644 > index 000..a2c646d > --- /dev/null > +++ b/unstable/virtual-keyboard/README > @@ -0,0 +1,2 @@ > +Virtual keyboard protocol > + > diff --git a/unstable/virtual-keyboard/virtual-keyboard-unstable-v1.xml > b/unstable/virtual-keyboard/virtual-keyboard-unstable-v1.xml > new file mode 100644 > index 000..9eae804 > --- /dev/null > +++ b/unstable/virtual-keyboard/virtual-keyboard-unstable-v1.xml > @@ -0,0 +1,114 @@ > + > + > + > +Copyright © 2008-2011 Kristian Høgsberg > +Copyright © 2010-2013 Intel Corporation > +Copyright © 2012-2013 Collabora, Ltd. > +Copyright © 2018 Purism SPC > + > +Permission is hereby granted, free of charge, to any person obtaining a > +copy of this software and associated documentation files (the > "Software"), > +to deal in the Software without restriction, including without limitation > +the rights to use, copy, modify, merge, publish, distribute, sublicense, > +and/or sell copies of the Software, and to permit persons to whom the > +Software is furnished to do so, subject to the following conditions: > + > +The above copyright notice and this permission notice (including the next > +paragraph) shall be included in all copies or substantial portions of the > +Software. > + > +THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS > OR > +IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, > +FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL > +THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR > OTHER > +LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING > +FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER > +DEALINGS IN THE SOFTWARE. > + > + > + > + > + The virtual keyboard provides an application with requests which > emulate > + the behaviour of a physical keyboard. > + > + This interface can be used by clients on its own to provide raw input > + events, or it can accompany the input method protocol. > + > + > + > + > +Provide a file descriptor to the compositor which can be > memory-mapped > +to provide a keyboard mapping description. > + > + +summary="keymap format"/> > + > + > + > + > + > + > + > + > + > + > +A key was pressed or released. > + > +The time argument is a timestamp with millisecond granularity, with > an > +undefined base. All requests regarding a single object must share the > +same clock. > + > +Keymap must be set before issuing this request. > + > + +summary="timestamp with millisecond granularity"/> > + > + +summary="physical state of the key"/> > + > + > + > + > +Notifies the compositor that the modifier and/or group state has > +changed, and it should upda
[PATCH v2] server: add wl_signal_emit_safe
This new function allows listeners to remove themselves or any
other listener when called. This version only works if listeners
are properly removed before they are free'd.
wl_signal_emit tries to be safe but it fails: it works fine if a
handler removes its own listener, but not if it removes another
one.
It's not possible to patch wl_signal_emit directly as attempted
in [1] because some projects using libwayland directly free
destroy listeners without removing them from the list. Using this
new strategy fails in this case, causing read-after-free errors.
[1]: https://patchwork.freedesktop.org/patch/204641/
Signed-off-by: Simon Ser
---
Addressed Markus' comments [1].
[1]: https://lists.freedesktop.org/archives/wayland-devel/2018-July/039042.html
src/wayland-server-core.h | 3 ++
src/wayland-server.c | 50 +++
tests/signal-test.c | 86 +++
3 files changed, 139 insertions(+)
diff --git a/src/wayland-server-core.h b/src/wayland-server-core.h
index 2e725d9..4a2948a 100644
--- a/src/wayland-server-core.h
+++ b/src/wayland-server-core.h
@@ -468,6 +468,9 @@ wl_signal_emit(struct wl_signal *signal, void *data)
l->notify(l, data);
}
+void
+wl_signal_emit_safe(struct wl_signal *signal, void *data);
+
typedef void (*wl_resource_destroy_func_t)(struct wl_resource *resource);
/*
diff --git a/src/wayland-server.c b/src/wayland-server.c
index eae8d2e..3d851f4 100644
--- a/src/wayland-server.c
+++ b/src/wayland-server.c
@@ -1932,6 +1932,56 @@ wl_client_for_each_resource(struct wl_client *client,
wl_map_for_each(&client->objects, resource_iterator_helper, &context);
}
+static void
+handle_noop(struct wl_listener *listener, void *data) {
+ /* Do nothing */
+}
+
+/** Emits this signal, safe against removal of any listener.
+ *
+ * wl_signal_emit tries to be safe but it fails: it works fine if a handler
+ * removes its own listener, but not if it removes another one.
+ *
+ * \note This function can only be used if listeners are properly removed
before
+ * being free'd.
+ *
+ * \param signal The signal object that will emit the signal
+ * \param data The data that will be emitted with the signal
+ *
+ * \sa wl_signal_emit()
+ *
+ * \memberof wl_signal
+ */
+WL_EXPORT void
+wl_signal_emit_safe(struct wl_signal *signal, void *data) {
+ struct wl_listener cursor;
+ struct wl_listener end;
+
+ /* Add two special markers: one cursor and one end marker. This way, we
know
+* that we've already called listeners on the left of the cursor and
that we
+* don't want to call listeners on the right of the end marker. The 'it'
+* function can remove any element it wants from the list without
troubles.
+* wl_list_for_each_safe tries to be safe but it fails: it works fine
+* if the current item is removed, but not if the next one is. */
+ wl_list_insert(&signal->listener_list, &cursor.link);
+ cursor.notify = handle_noop;
+ wl_list_insert(signal->listener_list.prev, &end.link);
+ end.notify = handle_noop;
+
+ while (cursor.link.next != &end.link) {
+ struct wl_list *pos = cursor.link.next;
+ struct wl_listener *l = wl_container_of(pos, l, link);
+
+ wl_list_remove(&cursor.link);
+ wl_list_insert(pos, &cursor.link);
+
+ l->notify(l, data);
+ }
+
+ wl_list_remove(&cursor.link);
+ wl_list_remove(&end.link);
+}
+
/** \cond INTERNAL */
/** Initialize a wl_priv_signal object
diff --git a/tests/signal-test.c b/tests/signal-test.c
index 7bbaa9f..dc762a4 100644
--- a/tests/signal-test.c
+++ b/tests/signal-test.c
@@ -115,3 +115,89 @@ TEST(signal_emit_to_more_listeners)
assert(3 * counter == count);
}
+
+struct signal
+{
+ struct wl_signal signal;
+ struct wl_listener l1, l2, l3;
+ int count;
+ struct wl_listener *current;
+};
+
+static void notify_remove(struct wl_listener *l, void *data)
+{
+ struct signal *sig = data;
+ wl_list_remove(&sig->current->link);
+ wl_list_init(&sig->current->link);
+ sig->count++;
+}
+
+#define INIT \
+ wl_signal_init(&signal.signal); \
+ wl_list_init(&signal.l1.link); \
+ wl_list_init(&signal.l2.link); \
+ wl_list_init(&signal.l3.link);
+#define CHECK_EMIT(expected) \
+ signal.count = 0; \
+ wl_signal_emit_safe(&signal.signal, &signal); \
+ assert(signal.count == expected);
+
+TEST(signal_remove_listener)
+{
+ test_set_timeout(4);
+
+ struct signal signal;
+
+ signal.l1.notify = notify_remove;
+ signal.l2.notify = notify_remove;
+ signal.l3.notify = notify_remove;
+
+ INIT
+ wl_signal_add(&signal.signal, &signal.l
[PATCH] cursor: use memfd_create or shm_open for anonymous in-memory files
On Linux, try using memfd_create and file sealing. Fallback to
shm_open on old kernels.
On FreeBSD, use shm_open with SHM_ANON.
Otherwise, use shm_open with a random name, making sure the name
isn't already taken.
Signed-off-by: Simon Ser
---
Makefile.am | 2 +-
configure.ac | 4 +-
cursor/os-compatibility.c | 172 ++
3 files changed, 86 insertions(+), 92 deletions(-)
diff --git a/Makefile.am b/Makefile.am
index 697c517..c612672 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -136,7 +136,7 @@ libwayland_cursor_la_SOURCES = \
cursor/cursor-data.h\
cursor/xcursor.c\
cursor/xcursor.h
-libwayland_cursor_la_LIBADD = libwayland-client.la
+libwayland_cursor_la_LIBADD = libwayland-client.la -lrt
pkgconfig_DATA += cursor/wayland-cursor.pc
diff --git a/configure.ac b/configure.ac
index 9419ae3..d59c61d 100644
--- a/configure.ac
+++ b/configure.ac
@@ -62,8 +62,8 @@ if test "x$GCC" = "xyes"; then
fi
AC_SUBST(GCC_CFLAGS)
-AC_CHECK_HEADERS([sys/prctl.h])
-AC_CHECK_FUNCS([accept4 mkostemp posix_fallocate prctl])
+AC_CHECK_HEADERS([sys/prctl.h linux/memfd.h])
+AC_CHECK_FUNCS([accept4 prctl])
AC_ARG_ENABLE([libraries],
[AC_HELP_STRING([--disable-libraries],
diff --git a/cursor/os-compatibility.c b/cursor/os-compatibility.c
index e972d21..96649e3 100644
--- a/cursor/os-compatibility.c
+++ b/cursor/os-compatibility.c
@@ -25,124 +25,118 @@
#define _GNU_SOURCE
-#include
-#include
-#include
#include
-#include
+#include
#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#ifdef HAVE_LINUX_MEMFD_H
+#include
+#endif
#include "config.h"
#include "os-compatibility.h"
-#ifndef HAVE_MKOSTEMP
+static void
+randname(char *buf) {
+ struct timespec ts;
+ long r;
+ int i;
+
+ clock_gettime(CLOCK_REALTIME, &ts);
+ r = ts.tv_nsec;
+ for (i = 0; i < 6; ++i) {
+ buf[i] = 'A'+(r&15)+(r&16)*2;
+ r >>= 5;
+ }
+}
+
static int
-set_cloexec_or_close(int fd)
+anonymous_shm_open(off_t size)
{
- long flags;
-
- if (fd == -1)
- return -1;
+ char name[] = "/wayland-cursor-XX";
+ int fd, retries = 100;
- flags = fcntl(fd, F_GETFD);
- if (flags == -1)
- goto err;
+ do {
+ randname(name + strlen(name) - 6);
- if (fcntl(fd, F_SETFD, flags | FD_CLOEXEC) == -1)
- goto err;
+ --retries;
+ fd = shm_open(name, O_RDWR | O_CREAT | O_EXCL | O_CLOEXEC,
0600);
+ if (fd >= 0) {
+ shm_unlink(name);
+ return fd;
+ }
+ } while (retries > 0 && errno == EEXIST);
- return fd;
-
-err:
- close(fd);
return -1;
}
+
+static int
+seal_or_close(int fd) {
+#if defined(F_ADD_SEALS) && defined(F_SEAL_SHRINK)
+ if (fcntl(fd, F_ADD_SEALS, F_SEAL_SHRINK) == -1) {
+ close(fd);
+ return -1;
+ }
#endif
+ return 0;
+}
+
static int
-create_tmpfile_cloexec(char *tmpname)
+create_anonymous_file(off_t size)
{
- int fd;
+ int fd, flags;
-#ifdef HAVE_MKOSTEMP
- fd = mkostemp(tmpname, O_CLOEXEC);
- if (fd >= 0)
- unlink(tmpname);
-#else
- fd = mkstemp(tmpname);
+#if defined(__NR_memfd_create) && defined(MFD_CLOEXEC)
+ flags = MFD_CLOEXEC;
+#if defined(MFD_ALLOW_SEALING)
+ flags |= MFD_ALLOW_SEALING;
+#endif
+ fd = syscall(__NR_memfd_create, "wayland-cursor", flags);
if (fd >= 0) {
- fd = set_cloexec_or_close(fd);
- unlink(tmpname);
- }
+ if (ftruncate(fd, size) < 0) {
+ close(fd);
+ return -1;
+ }
+
+#if defined(MFD_ALLOW_SEALING)
+ if (seal_or_close(fd) != 0)
+ return -1;
#endif
+ return fd;
+ } else if (errno != ENOSYS)
+ return fd;
+#endif
+
+#if defined(__FreeBSD__)
+ fd = shm_open(SHM_ANON, O_CREAT | O_EXCL | O_RDWR | O_CLOEXEC, 0600);
+#else
+ fd = anonymous_shm_open(size);
+#endif
+
+ if (ftruncate(fd, size) < 0) {
+ close(fd);
+ return -1;
+ }
+
return fd;
}
-/*
- * Create a new, unique, anonymous file of the given size, and
- * return the file descriptor for it. The file descriptor is set
- * CLOEXEC. The file is immediately suitable for mmap()'ing
- * the given size at offset zero.
- *
- * The file should not have a permanent backing store like a disk,
- * but may have if XDG_RUNTIME_DIR is not properly implemented in OS.
- *
- * The file name is de
Re: [PATCH] cursor: use memfd_create or shm_open for anonymous in-memory files
On August 16, 2018 11:57 AM, Jan Engelhardt wrote: > On Thursday 2018-08-16 12:41, Emil Velikov wrote: > > > On 15 August 2018 at 15:14, Simon Ser cont...@emersion.fr wrote: > > > > > On Linux, try using memfd_create and file sealing. Fallback to > > > shm_open on old kernels. > > > On FreeBSD, use shm_open with SHM_ANON. > > > Otherwise, use shm_open with a random name, making sure the name > > > isn't already taken. > > > > Thinking out loud: > > I wonder if the next POSIX standard will finally standardise > > random/anonymous shm files. Be that shm_open+SHM_ANON [...] > > According to the shm_open.3 from Linux man-pages-4.16 project, > shm_open is already marked standardized: > > CONFORMING TO > POSIX.1-2001, POSIX.1-2008. Yes, but this doesn't include SHM_ANON unfortunately. So we still need to generate a random name and make sure it hasn't been taken already. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland-protocols] unstable: add xdg-primary-selection protocol
Hi, Thanks for the clarification. On August 16, 2018 3:46 PM, Jonas Ådahl wrote: > On Thu, Aug 16, 2018 at 04:25:06PM +0200, Carlos Garnacho wrote: > > > Hi!, > > Thanks Simon for moving this forward. FTR this looks good to me. Had > > some chat with Jonas on IRC about the suitability of xdg vs wp > > prefixes, but I personally think your choice is fine. Either way, this > > is > > To elaborate what the discussion was about: > > "xdg" shouldn't be seen as a "desktop" (device that sits on a desk) > thing, but a place to put protocols that aims to "bridge" different > environments, be they things running in devices placed on desks or in > hands. In my mind "xdg" meant "desktop-style compositors", be it targeted at desktop machines as well as laptops. I was thinking "xdg" was separate from e.g. IVI and mobile phones. But it seems I'm wrong here -- can you elaborate on this "bridge" idea? Do you mean a bridge between different compositors? Or a bridge between desktops/laptops/smartphones/tablets? > For example, if someone plugs in a mouse to a smartphone or tablet, if > that person has the middle-click-paste function on the actual desktop > computer, I'd assume the same user would expect it also on the > not-a-desktop-computer device. I'm not sure smartphone/tablets compositors would want to implement things like drag-and-drop and primary selection. If they do, this is only to accommodate for situations in which the user makes their device more desktop-y (e.g. by plugging a mouse), in which case implementing an "xdg" protocol makes sense. > Personally I don't think clipboard really fall into this category of > desktop environment interoperability, and "primary selection" is not > really different from the regular clipboard and drag-n-drop > functionality here I think. The difference is that while you have clipboard on a smartphone/tablet, you don't have drag-and-drop nor primary selection. Yeah, primary selection is similar to drag-and-drop. > On the other hand, if we see clipboard as something that bridges > environments (e.g. if gtk wants to have interoperable clipboard, it > needs to use a bridging protocol), and with that in mind, primary > selection do fall into this category (so does regular clipboard, but > can't rename that so meh). I personally think at least drag-and-drop doesn't belong in the core Wayland protocol. But yeah, it's not like we can change this. > So, my personal opinion is that putting this inside a "xdg_" prefix is > not entirely suitable, given that this is clipboard type plumbing that > just happens to historically come from the traditional desktop Linux > usage. So in the end, do you want to use the "wp_" prefix, or maybe another prefix? IMHO the "wp_" prefix is too broad for this protocol. I'm not feeling strongly about this in any case. > Thoughts? If we ignore form factors (desktop vs hand held), where does > it fall, you think? > > Jonas > > > Acked-by: Carlos Garnacho carl...@gnome.org > > On Sun, Jul 8, 2018 at 9:14 PM, Simon Ser cont...@emersion.fr wrote: > > > > > This primary selection is similar in spirit to the eponimous > > > in X11, allowing a quick "select text + middle click" shortcut > > > to copying and pasting. > > > It's otherwise very similar to its Yayland counterpart, and > > > explicitly made consistent with it. > > > > > > Signed-off-by: Simon Ser cont...@emersion.fr > > > > > > - > > > > > > This is a continuation of 1. This protocol was pretty close to being > > > accepted. > > > I've chosen to put the xdg prefix because this primary selection is > > > mostly relevant > > > to desktop compositors. > > > I've added myself as maintainer, Carlos and Lyude let me know if you want > > > to replace > > > me or be added to the list too. > > > Makefile.am | 3 +- > > > unstable/xdg-primary-selection/README | 4 + > > > .../xdg-primary-selection-unstable-v1.xml | 225 ++ > > > 3 files changed, 231 insertions(+), 1 deletion(-) > > > create mode 100644 unstable/xdg-primary-selection/README > > > create mode 100644 > > > unstable/xdg-primary-selection/xdg-primary-selection-unstable-v1.xml > > > diff --git a/Makefile.am b/Makefile.am > > > index 2b59d34..66a65af 100644 > > > --- a/Makefile.am > > > +++ b/Makefile.am > > > @@ -19,7 +19,8 @@ unstable_protocols = \ > > > unstable/keybo
Re: [RFC wayland-protocols] input-method: Add zwp-input-method-v2
On 6 August 2018 3:00 PM, Dorota Czaplejewicz wrote: > This protocol is based on v1, and current text-input-v3. > > 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, > > the third item on the path to well-supported virtual keyboard experience under > Wayland comes from Purism. This one allows the compositor to delegate text > input and composition duties to an application instead of handling it itself. > Input-method-delegating compositor would typically become only a broker > between the input method client and other applications. > > I took the existing input-method protocol, and after dissecting it with the > help of wlroots developers, I came up with an improved version, which is > attached for your (re)viewing pleasure. > > A large part of this protocol was taken from recent text-input-v3, and some > description text was improved. Still, the protocol has a couple of rough > edges, which is why it's titled RFC and not a patch. > > The issues I have had most trouble with are related to the handling of > keyboard grabs. These are meant to allow traditional, keyboard-based input > methods, to take over keyboard input in order to compose text in a different > way. > > First, keyboard grabs are defined as unreliable. I'm not sure whether this is > the right choice, but given that making them more reliable seems rather > complicated, this is the default one. > > In addition, handling the keyboard events themselves is troublesome, because > an input method, even if it has a surface, is not meant to have keyboard focus > while it's in operation. Returning wl_keyboard as new_id seems not to be > possible due to versioning. Should the request make an existing wl_keyboard > instance change behaviour? Or perhaps there should be a new > zwp_input_method_keyboard mimicking the wl_keyboard interface? > > I'm interested in your opinions. > > Thank you, > Dorota Czaplejewicz Thansk for your RFC! > Makefile.am| 1 + > unstable/input-method/input-method-unstable-v2.xml | 403 > + > 2 files changed, 404 insertions(+) > create mode 100644 unstable/input-method/input-method-unstable-v2.xml > > diff --git a/Makefile.am b/Makefile.am > index 6394e26..f3b9f80 100644 > --- a/Makefile.am > +++ b/Makefile.am > @@ -7,6 +7,7 @@ unstable_protocols = > \ > unstable/text-input/text-input-unstable-v1.xml > \ > unstable/text-input/text-input-unstable-v3.xml > \ > unstable/input-method/input-method-unstable-v1.xml > \ > + unstable/input-method/input-method-unstable-v2.xml > \ > unstable/xdg-shell/xdg-shell-unstable-v5.xml > \ > unstable/xdg-shell/xdg-shell-unstable-v6.xml > \ > unstable/relative-pointer/relative-pointer-unstable-v1.xml > \ > diff --git a/unstable/input-method/input-method-unstable-v2.xml > b/unstable/input-method/input-method-unstable-v2.xml > new file mode 100644 > index 000..8cf8e29 > --- /dev/null > +++ b/unstable/input-method/input-method-unstable-v2.xml > @@ -0,0 +1,403 @@ > + > + > + > + > +Copyright © 2012, 2013 Intel Corporation > +Copyright © 2015, 2016 Jan Arne Petersen > +Copyright © 2017, 2018 Red Hat, Inc. > +Copyright © 2018 Purism SPC > + > +Permission is hereby granted, free of charge, to any person obtaining a > +copy of this software and associated documentation files (the > "Software"), > +to deal in the Software without restriction, including without limitation > +the rights to use, copy, modify, merge, publish, distribute, sublicense, > +and/or sell copies of the Software, and to permit persons to whom the > +Software is furnished to do so, subject to the following conditions: > + > +The above copyright notice and this permission notice (including the next > +paragraph) shall be included in all copies or su
[PATCH wayland-protocols v2] unstable: add primary-selection protocol
From: emersion This primary selection is similar in spirit to the eponimous in X11, allowing a quick "select text + middle click" shortcut to copying and pasting. It's otherwise very similar to its Wayland counterpart, and explicitly made consistent with it. Signed-off-by: Simon Ser --- Changes from v1 to v2: renamed with the wp_ prefix Makefile.am | 3 +- unstable/primary-selection/README | 4 + .../primary-selection-unstable-v1.xml | 226 ++ 3 files changed, 232 insertions(+), 1 deletion(-) create mode 100644 unstable/primary-selection/README create mode 100644 unstable/primary-selection/primary-selection-unstable-v1.xml diff --git a/Makefile.am b/Makefile.am index 6394e26..aca32c2 100644 --- a/Makefile.am +++ b/Makefile.am @@ -20,7 +20,8 @@ unstable_protocols = \ unstable/keyboard-shortcuts-inhibit/keyboard-shortcuts-inhibit-unstable-v1.xml \ unstable/xdg-output/xdg-output-unstable-v1.xml \ unstable/input-timestamps/input-timestamps-unstable-v1.xml \ - unstable/xdg-decoration/xdg-decoration-unstable-v1.xml \ + unstable/xdg-decoration/xdg-decoration-unstable-v1.xml \ + unstable/xdg-primary-selection/xdg-primary-selection-unstable-v1.xml \ $(NULL) stable_protocols = \ diff --git a/unstable/primary-selection/README b/unstable/primary-selection/README new file mode 100644 index 000..ae0a402 --- /dev/null +++ b/unstable/primary-selection/README @@ -0,0 +1,4 @@ +Primary selection protocol + +Maintainers: +Simon Ser diff --git a/unstable/primary-selection/primary-selection-unstable-v1.xml b/unstable/primary-selection/primary-selection-unstable-v1.xml new file mode 100644 index 000..749dd86 --- /dev/null +++ b/unstable/primary-selection/primary-selection-unstable-v1.xml @@ -0,0 +1,226 @@ + + + +Copyright © 2015, 2016 Red Hat + +Permission is hereby granted, free of charge, to any person obtaining a +copy of this software and associated documentation files (the "Software"), +to deal in the Software without restriction, including without limitation +the rights to use, copy, modify, merge, publish, distribute, sublicense, +and/or sell copies of the Software, and to permit persons to whom the +Software is furnished to do so, subject to the following conditions: + +The above copyright notice and this permission notice (including the next +paragraph) shall be included in all copies or substantial portions of the +Software. + +THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR +IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, +FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL +THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER +LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING +FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER +DEALINGS IN THE SOFTWARE. + + + +This protocol provides the ability to have a primary selection device to +match that of the X server. This primary selection is a shortcut to the +common clipboard selection, where text just needs to be selected in order +to allow copying it elsewhere. The de facto way to perform this action +is the middle mouse button, although it is not limited to this one. + +Clients wishing to honor primary selection should create a primary +selection source and set it as the selection through +wp_primary_selection_device.set_selection whenever the text selection +changes. In order to minimize calls in pointer-driven text selection, +it should happen only once after the operation finished. Similarly, +a NULL source should be set when text is unselected. + +wp_primary_selection_offer objects are first announced through the +wp_primary_selection_device.data_offer event. Immediately after this event, +the primary data offer will emit wp_primary_selection_offer.offer events +to let know of the mime types being offered. + +When the primary selection changes, the client with the keyboard focus +will receive wp_primary_selection_device.selection events. Only the client +with the keyboard focus will receive such events with a non-NULL +wp_primary_selection_offer. Across keyboard focus changes, previously +focused clients will receive wp_primary_selection_device.events with a +NULL wp_primary_selection_offer. + +In order to request the primary selection data, the client must pass +a recent serial pertaining to the press event that is triggering the +operation, if the compositor deems the serial valid and recent, the +wp_primary_selection_source.
Re: [PATCH] cursor: use memfd_create or shm_open for anonymous in-memory files
Hi all,
Any news about this?
Thanks,
---
Simon Ser
https://emersion.fr
On Wednesday, August 15, 2018 4:14 PM, Simon Ser wrote:
> On Linux, try using memfd_create and file sealing. Fallback to
> shm_open on old kernels.
>
> On FreeBSD, use shm_open with SHM_ANON.
>
> Otherwise, use shm_open with a random name, making sure the name
> isn't already taken.
>
> Signed-off-by: Simon Ser cont...@emersion.fr
>
> Makefile.am | 2 +-
> configure.ac | 4 +-
> cursor/os-compatibility.c | 172 ++
> 3 files changed, 86 insertions(+), 92 deletions(-)
>
> diff --git a/Makefile.am b/Makefile.am
> index 697c517..c612672 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -136,7 +136,7 @@ libwayland_cursor_la_SOURCES = \
> cursor/cursor-data.h \
> cursor/xcursor.c \
> cursor/xcursor.h
> -libwayland_cursor_la_LIBADD = libwayland-client.la
> +libwayland_cursor_la_LIBADD = libwayland-client.la -lrt
>
> pkgconfig_DATA += cursor/wayland-cursor.pc
>
> diff --git a/configure.ac b/configure.ac
> index 9419ae3..d59c61d 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -62,8 +62,8 @@ if test "x$GCC" = "xyes"; then
> fi
> AC_SUBST(GCC_CFLAGS)
>
> -AC_CHECK_HEADERS([sys/prctl.h])
> -AC_CHECK_FUNCS([accept4 mkostemp posix_fallocate prctl])
> +AC_CHECK_HEADERS([sys/prctl.h linux/memfd.h])
> +AC_CHECK_FUNCS([accept4 prctl])
>
> AC_ARG_ENABLE([libraries],
> [AC_HELP_STRING([--disable-libraries],
> diff --git a/cursor/os-compatibility.c b/cursor/os-compatibility.c
> index e972d21..96649e3 100644
> --- a/cursor/os-compatibility.c
> +++ b/cursor/os-compatibility.c
> @@ -25,124 +25,118 @@
>
> #define _GNU_SOURCE
>
> -#include
> -#include
> -#include
> #include
> -#include
> +#include
> #include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
>
> -
>
> +#ifdef HAVE_LINUX_MEMFD_H
> +#include
> +#endif
>
> #include "config.h"
> #include "os-compatibility.h"
>
> -#ifndef HAVE_MKOSTEMP
> +static void
> +randname(char *buf) {
>
> - struct timespec ts;
>
> - long r;
>
> - int i;
>
> -
> - clock_gettime(CLOCK_REALTIME, &ts);
>
> - r = ts.tv_nsec;
>
> - for (i = 0; i < 6; ++i) {
>
> - buf[i] = 'A'+(r&15)+(r&16)*2;
>
>
> - r >>= 5;
>
>
> - }
> +}
>
> -
>
> static int
> -set_cloexec_or_close(int fd)
> +anonymous_shm_open(off_t size)
> {
>
> - long flags;
> -
> - if (fd == -1)
> - return -1;
>
>
>
> - char name[] = "/wayland-cursor-XX";
> - int fd, retries = 100;
>
> - flags = fcntl(fd, F_GETFD);
> - if (flags == -1)
> - goto err;
>
>
>
> - do {
> - randname(name + strlen(name) - 6);
>
>
>
> - if (fcntl(fd, F_SETFD, flags | FD_CLOEXEC) == -1)
> - goto err;
>
>
>
> - --retries;
>
>
> - fd = shm_open(name, O_RDWR | O_CREAT | O_EXCL | O_CLOEXEC, 0600);
>
>
> - if (fd >= 0) {
>
>
> - shm_unlink(name);
>
>
> - return fd;
>
>
> - }
>
>
> - } while (retries > 0 && errno == EEXIST);
>
>
> - return fd;
> -
>
> -err:
>
> - close(fd);
> return -1;
> }
>
>
> -
>
> +static int
> +seal_or_close(int fd) {
> +#if defined(F_ADD_SEALS) && defined(F_SEAL_SHRINK)
>
> - if (fcntl(fd, F_ADD_SEALS, F_SEAL_SHRINK) == -1) {
> - close(fd);
>
>
> - return -1;
>
>
> - }
> #endif
>
> - return 0;
> +}
>
> -
>
> static int
> -create_tmpfile_cloexec(char *tmpname)
> +create_anonymous_file(off_t size)
> {
>
> - int fd;
>
> - int fd, flags;
>
> -#ifdef HAVE_MKOSTEMP
>
>
> - fd = mkostemp(tmpname, O_CLOEXEC);
>
> - if (fd >= 0)
>
> - unlink(tmpname);
>
>
>
> -#else
>
> - fd = mkstemp(tmpname);
> +#if defined(__NR_memfd_create) && defined(MFD_CLOEXEC)
>
>
> - flags = MFD_CLOEXEC;
> +#if defined(MFD_ALLOW_SEALING)
>
> - flags |= MFD_ALLOW_SEALING;
> +#endif
>
> - fd = syscall(__NR_memfd_create, "wayland-cursor", flags);
> if (fd >= 0) {
>
>
> - fd = set_cloexec_or_close(fd);
>
>
> - unlink(tmpname);
>
>
> - }
>
> - if (ftruncate(fd, size) < 0) {
>
>
> - close(fd);
>
>
> - return -1;
>
>
> -
Re: [PATCH v2] server: add wl_signal_emit_safe
On Tuesday, September 18, 2018 8:43 PM, Derek Foreman wrote: > On 2018-08-08 07:00 AM, Simon Ser wrote: > > > This new function allows listeners to remove themselves or any > > other listener when called. This version only works if listeners > > are properly removed before they are free'd. > > wl_signal_emit tries to be safe but it fails: it works fine if a > > handler removes its own listener, but not if it removes another > > one. > > It's not possible to patch wl_signal_emit directly as attempted > > in 1 because some projects using libwayland directly free > > destroy listeners without removing them from the list. Using this > > new strategy fails in this case, causing read-after-free errors. > > Signed-off-by: Simon Ser cont...@emersion.fr > > Hi Simon, > > Is there intent to use this internally in libwayland (or in weston?) > somewhere in a further patch? > > Since there's no way to know from the callback whether the signal is > being emit "safely" or not, I'm a little concerned that developers might > get confused about what style of callback they're writing. Or people > will see "safe" and just lazily use that everywhere, even for destroy > signals... > > Also, it looks at a glance like all of the struct members and such > touched by this function are in public headers? I think the safe emit > function doesn't strictly need to be in libwayland at all? > > I don't really mean to block this work, just wondering what follows next. > > Some tiny comments inlined further down. Hi, Thanks for you review. I have no plans to make libwayland or weston use this function in a future patch. It should be used by everybody who's sure users correctly remove destroy listeners (or doesn't care to break its ABI). Yeah, this function doesn't need to be in libwayland per se, in fact we already have it in wlroots and use it everywhere. I just thought users would benefit from having a safe version of wl_signal_emit in libwayland, because it's easy to remove multiple listeners from a destroy handler once you have multiple destroy signals and inter-dependant structs. It doesn't _need_ to be in libwayland, but putting it in libwayland would allow people to make sure they don't run into issues without needing to copy-paste the function from wlroots. People could use it without understanding why it's safe, but I prefer to have users running into issues because they forget to remove the destroy listener than having users running into issues because they use multiple wl_signals. What do you think? In the end it's not that a big deal, I just think it would be nice to have. Simon ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH] protocol: allow to send a zero output refresh rate
Fixed refresh rate doesn't always make sense for all outputs. In case it's not available or not relevant, allow compositors to send zero. This is for instance the case for outputs with variable refresh rate (such as FreeSync) and virtual outputs. Signed-off-by: Simon Ser --- protocol/wayland.xml | 4 1 file changed, 4 insertions(+) diff --git a/protocol/wayland.xml b/protocol/wayland.xml index 141038b..3c2aa3a 100644 --- a/protocol/wayland.xml +++ b/protocol/wayland.xml @@ -2447,6 +2447,10 @@ the output size in the global compositor space. For instance, the output may be scaled, as described in wl_output.scale, or transformed, as described in wl_output.transform. + + The vertical refresh rate can be set to zero if it doesn't make + sense for this output (e.g. for outputs with variable refresh + rates or virtual outputs). -- 2.19.0 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland-protocols v2] unstable: add primary-selection protocol
Hi Jonas, Any news about this? Thanks! Simon On Sunday, September 23, 2018 12:52 PM, Simon Ser wrote: > From: emersion cont...@emersion.fr > > This primary selection is similar in spirit to the eponimous > in X11, allowing a quick "select text + middle click" shortcut > to copying and pasting. > > It's otherwise very similar to its Wayland counterpart, and > explicitly made consistent with it. > > Signed-off-by: Simon Ser cont...@emersion.fr > > Changes from v1 to v2: renamed with the wp_ prefix > > Makefile.am | 3 +- > unstable/primary-selection/README | 4 + > .../primary-selection-unstable-v1.xml | 226 ++ > 3 files changed, 232 insertions(+), 1 deletion(-) > create mode 100644 unstable/primary-selection/README > create mode 100644 > unstable/primary-selection/primary-selection-unstable-v1.xml > > diff --git a/Makefile.am b/Makefile.am > index 6394e26..aca32c2 100644 > --- a/Makefile.am > +++ b/Makefile.am > @@ -20,7 +20,8 @@ unstable_protocols = \ > unstable/keyboard-shortcuts-inhibit/keyboard-shortcuts-inhibit-unstable-v1.xml > \ > unstable/xdg-output/xdg-output-unstable-v1.xml \ > unstable/input-timestamps/input-timestamps-unstable-v1.xml \ > > - unstable/xdg-decoration/xdg-decoration-unstable-v1.xml \ > > - unstable/xdg-decoration/xdg-decoration-unstable-v1.xml \ > - unstable/xdg-primary-selection/xdg-primary-selection-unstable-v1.xml \ > $(NULL) > > stable_protocols = \ > diff --git a/unstable/primary-selection/README > b/unstable/primary-selection/README > new file mode 100644 > index 000..ae0a402 > --- /dev/null > +++ b/unstable/primary-selection/README > @@ -0,0 +1,4 @@ > +Primary selection protocol > > - > > +Maintainers: > +Simon Ser cont...@emersion.fr > diff --git a/unstable/primary-selection/primary-selection-unstable-v1.xml > b/unstable/primary-selection/primary-selection-unstable-v1.xml > new file mode 100644 > index 000..749dd86 > --- /dev/null > +++ b/unstable/primary-selection/primary-selection-unstable-v1.xml > @@ -0,0 +1,226 @@ > + > + > > - > > - Copyright © 2015, 2016 Red Hat > > - > - Permission is hereby granted, free of charge, to any person obtaining a > > - copy of this software and associated documentation files (the "Software"), > > - to deal in the Software without restriction, including without limitation > > - the rights to use, copy, modify, merge, publish, distribute, sublicense, > > - and/or sell copies of the Software, and to permit persons to whom the > > - Software is furnished to do so, subject to the following conditions: > > - > - The above copyright notice and this permission notice (including the next > > - paragraph) shall be included in all copies or substantial portions of the > > - Software. > > - > - THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR > > - IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, > > - FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL > > - THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER > > - LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING > > - FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER > > - DEALINGS IN THE SOFTWARE. > > - > > - > - > > - This protocol provides the ability to have a primary selection device to > > - match that of the X server. This primary selection is a shortcut to the > > - common clipboard selection, where text just needs to be selected in order > > - to allow copying it elsewhere. The de facto way to perform this action > > - is the middle mouse button, although it is not limited to this one. > > - > - Clients wishing to honor primary selection should create a primary > > - selection source and set it as the selection through > > - wp_primary_selection_device.set_selection whenever the text selection > > - changes. In order to minimize calls in pointer-driven text selection, > > - it should happen only once after the operation finished. Similarly, > > - a NULL source should be set when text is unselected. > > - > - wp_primary_selection_offer objects are first announced through the > > - wp_primary_selection_device.data_offer event. Immediately after this > event, > > - the primary data offer will emit wp_primary_selection_offer.offer events > > - to let know of the mime types being offered. > > - > - When the primary selection changes, the client with the keyboard fo
[PATCH v2] protocol: warn clients about some wl_output properties
All wl_output properties don't always make sense for all compositors. Some compositors might not implement a "global compositor space", (e.g. 3D compositors) in which case properties like x and y don't make sense. Some compositors might expose virtual outputs, in which case modes, make and model are not relevant. In a lot of these situations, information from xdg_output is better suited. Signed-off-by: Simon Ser --- Changes from v1 to v2: added a note about presentation-time protocol/wayland.xml | 18 +- 1 file changed, 17 insertions(+), 1 deletion(-) diff --git a/protocol/wayland.xml b/protocol/wayland.xml index 141038b..fd657ae 100644 --- a/protocol/wayland.xml +++ b/protocol/wayland.xml @@ -2402,6 +2402,13 @@ The physical size can be set to zero if it doesn't make sense for this output (e.g. for projectors or virtual outputs). + + Note: wl_output only advertises partial information about the output + position and identification. Some compositors, for instance those not + implementing a desktop-style output layout or those exposing virtual + outputs, might fake this information. Instead of using x and y, clients + should use xdg_output.logical_position. Instead of using make and model, + clients should use xdg_output.name and xdg_output.description. @@ -2446,7 +2453,16 @@ the output device. This is not necessarily the same as the output size in the global compositor space. For instance, the output may be scaled, as described in wl_output.scale, - or transformed, as described in wl_output.transform. + or transformed, as described in wl_output.transform. Clients + willing to retrieve the output size in the global compositor + space should use xdg_output.logical_size instead. + + Clients should not use the refresh rate to schedule frames. Instead, + they should use the presentation-time protocol. + + Note: this information is not always meaningful for all outputs. Some + compositors, such as those exposing virtual outputs, might fake the + refresh rate or the size. -- 2.19.0 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Possible Wayland Extension to publish Mouse Pointer Size
Hi, On Tuesday, October 9, 2018 3:34 PM, Michael Arnold wrote: > Hi, > > I'm new here and out my depth - normally I tinker together applications, on > linux, sometimes using Qt. Using Qt under Gnome/Wayland I noticed that the > mouse pointer increased in size when moved over a Qt based application. (The > defect is raised here: https://bugreports.qt.io/browse/QTBUG-70971). As I am > sure you aware, under Wayland, Qt is responsible for displaying the mouse > pointer and since there is no standard way across Wayland compositors to > determine the current cursor size, Qt sets the mouse pointer to size 32 by > default. Gnome, on a none-HiDPI display (like mine), sets the mouse pointer > size to 24, hence the weird mouse pointer size change when the mouse pointer > is moved over a Qt application window where the size set to 32. Indeed, we (wlroots) have the same issue. Weston apps also choose 32, GLFW chooses 24 IIRC. > Understandably Johan (from Qt Co.) is reluctant to use gsettings to get the > current cursor size from within the Qt Platform Abstration Layer (QPA), > because that means they will need to do something similar for every Wayland > compositor and hence is suggesting (correctly from what I understand) that a > Wayland extension be created for Wayland Compositors to publish their mouse > pointer size. Qt, GTK+ etc. can then pickup the mouse pointer size using the > Wayland protocol extension and display the mouse pointer at the current size > when the mouse is over the application window. Agree. Using gsettings is not a viable solution. > But this is where I get a bit lost and would be grateful of your guidance: > from what I can see the xdg-decoration protocol got proposed and debated via > this mailing list. Is there someone on this mailing list who would be > interested to pickup this issue or is there some other forum where I need to > raise this request? If you want to discuss about improving the cursor situation on Wayland, this is the right place. I think we have two possible solutions: a short-term one and a long-term one. The short-term one is already used by Qt and some X11 apps. It uses two environment variables (XCURSOR_THEME and XCURSOR_SIZE) to configure the cursor theme and size. I recently had a pull request merged to always export those from the default Wayland seat's configuration in rootston, our wlroots compositor [1]. I just opened a Weston merge request to add support for this in Weston clients [2]. The issue with that short-term solution is that in addition to cluttering the environment, it isn't multiseat aware. Let's say you have two seats (so you also have at least two cursors). Then it's difficult to tell which cursor belongs to which seat, both are identical. To fix this, a new Wayland protocol would be required. That would be the long-term solution. Qt and GLFW have expressed interest in such a protocol. This protocol could just tell the client which XCursor theme/size to use for which seat. Though, there are other issues with this approach: it requires XCursor (wouldn't work with a different cursor image specification) and clients still need to load cursors themselves (a thing the compositor usually already does). Also, some of our users want to be able to change the default cursor image (to e.g. use the same theme for two seats but have one with the left pointer image and the other with a cross image). I've thought about another proposal: a protocol that would allow clients to create opaque wl_buffers containing cursor images. The client would for instance ask "I want the default cursor image for seat0" and the compositor would create a wl_buffer containing it. There are still many unanswered questions though: do we expose an enum with a list of cursor images or do we allow clients to load arbitrary cursor images? How do we handle HiDPI? Alternatively, to only fix the cursor size issue without introducing a whole new protocol, Johan suggested to add a "cursor_size" event to wl_pointer in the core Wayland protocol. Pekka said he's not a fan of this since size depends on the cursor theme. Has anyone thoughts about all of this? [1]: https://github.com/swaywm/wlroots/pull/1294 [2]: https://gitlab.freedesktop.org/wayland/weston/merge_requests/33 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland-protocols v2] unstable: add primary-selection protocol
Thanks for your review, Jonas. Carlos, what do you think of this proposal? Thanks, Simon. On Thursday, October 4, 2018 12:06 PM, Jonas Ådahl wrote: > On Sun, Sep 23, 2018 at 10:52:34AM +0000, Simon Ser wrote: > > > From: emersion cont...@emersion.fr > > This primary selection is similar in spirit to the eponimous > > in X11, allowing a quick "select text + middle click" shortcut > > to copying and pasting. > > It's otherwise very similar to its Wayland counterpart, and > > explicitly made consistent with it. > > Signed-off-by: Simon Ser cont...@emersion.fr > > Reviewed-by: Jonas Ådahljad...@gmail.com > > with one minor nit below. I'd prefer to get another RB or Ack (by Carlos > eg) before landing. > > > Changes from v1 to v2: renamed with the wp_ prefix > > Makefile.am | 3 +- > > unstable/primary-selection/README | 4 + > > .../primary-selection-unstable-v1.xml | 226 ++ > > 3 files changed, 232 insertions(+), 1 deletion(-) > > create mode 100644 unstable/primary-selection/README > > create mode 100644 > > unstable/primary-selection/primary-selection-unstable-v1.xml > > diff --git a/Makefile.am b/Makefile.am > > index 6394e26..aca32c2 100644 > > --- a/Makefile.am > > +++ b/Makefile.am > > @@ -20,7 +20,8 @@ unstable_protocols = \ > > unstable/keyboard-shortcuts-inhibit/keyboard-shortcuts-inhibit-unstable-v1.xml > > \ > > unstable/xdg-output/xdg-output-unstable-v1.xml \ > > unstable/input-timestamps/input-timestamps-unstable-v1.xml \ > > > > - unstable/xdg-decoration/xdg-decoration-unstable-v1.xml \ > > > > - unstable/xdg-decoration/xdg-decoration-unstable-v1.xml \ > > Accidental change (tabs -> spaces) above. > > Jonas ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Possible Wayland Extension to publish Mouse Pointer Size
On Wednesday, October 10, 2018 4:48 PM, Michael Arnold wrote:
> With regards to using XCURSOR_SIZE, I worry that this approach is going to
> enjoy varying levels of support across desktops and applications over time,
> for example
> 1. Fedora 28, that has Gnome on Wayland as the default desktop, but does not
> set XCURSOR_SIZE.
That's normal, it's not included in any kind of standard right now, and only Qt
and X11 apps support it.
> 2. Tools like gsettings need to be changed to update XCURSOR_SIZE and
> XCURSOR_THEME when the user changes the associated parameters.
> This will take time.
Yeah, I don't expect this solution to support live updates. That's a good point
in favor of a protocol.
> 3. Desktop application maintainers are poorly positioned to detect and set the
> appropriate cursor size when the Qt application starts because, like the
> toolkit maintainers, they face a variety of Wayland desktops each with a
> different mechanism for setting the mouse pointer size.
I don't understand this one. App developers shouldn't have to worry about this,
the toolkit should pick XCURSOR_{SIZE,THEME} automatically.
Anyway, we both agree that a protocol is needed.
> > The client would for instance ask "I want the default cursor image for
> > seat0" and the compositor would create a wl_buffer containing it
>
> This approach makes the most sense to me. It means that the compositor hides
> their mouse pointer library behind a standardised Wayland extension and thus
> the compositor's mouse pointer library and settings tools can evolve
> independently of the applications and their toolkits.
Indeed, that's the idea. So we must be careful not to expose xcursor specifics
in the protocol.
> > ...do we expose an enum with a list of cursor images or do we allow clients
> > to load arbitrary cursor images?
>
> Following the logic above, the enum's make more sense to me: I see that
> XCursor has a cursor type and sub-type (to indicate size) associated with each
> pointer image and Qt has a list of pointer types
> (http://doc.qt.io/qt-5/qcursor.html). Possibly we could use these as basis.
That makes sense to me. Note that not all cursor themes support all cursors.
> If the application wants to load its own mouse pointer, it can do that,
> possibly with the toolkit's help, if available.
Yeah, apps can always use the current set_cursor request with a custom buffer.
> > How do we handle HiDPI?
>
> Create an array of wl_buffers, one for each screen, where each wl_buffer holds
> the mouse pointer in the associated screen's resolution.
Right, so we need to add a "scale" parameter in the protocol somewhere.
> I see XCursor also supports animated cursors via multiple mouse pointer images
> and an image sequence. To support this, we'll need a count of the number of
> wl_buffer images provided.
Aye.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Possible Wayland Extension to publish Mouse Pointer Size
On Thursday, October 11, 2018 2:57 AM, Michael Arnold wrote: > > > > How do we handle HiDPI? > > > > > > Create an array of wl_buffers, one for each screen, where each wl_buffer > > > holds > > > the mouse pointer in the associated screen's resolution. > > > > Right, so we need to add a "scale" parameter in the protocol somewhere. > > I lost you on this one. I was thinking that the compositor would be > responsible for applying the appropriate scale to the wl_buffer associated > with each screen, so there would be no need of a separate screen scale factor > in the protocol. So both HiDPI and scale of each screen would be addressed > together by the content of the wl_buffer. The toolkit would be responsible > for choosing the wl_buffer associated with the screen that the application is > being shown on. (So I'm assuming that the toolkit / application, knows which > screen the application is currently being displayed on). > > I imagine that toolkits, in general, would be interested in knowing the screen > scale so they can show custom mouse pointers and other screen content > appropriately, but since screen scale is associated with screens and not the > mouse, is a Mouse Pointer Extension be an appropriate place to include a > screen scale factor? (i.e. touch-screen compositors would need to support the > Mouse Pointer Extension to publish the screen scale to toolkits / > applications). A "scale" parameter in the protocol wouldn't advertise scale factors for each screen. Rather, it would allow clients to create cursor images with a specific scale factor. This is how HiDPI works in Wayland: * For each screen, the compositor broadcasts a wl_output object. This object has a "scale" property, which indicates the scale factor of the screen. * The clients still needs to know on which screen each surface is. For this purpose, compositors send a wl_surface.enter(wl_output) event each time a surface enters a wl_output (there's also a leave event). * Now clients know on which outputs they are displayed, and also know the scale factor of each screen. They can pick a scale factor to draw themselves (usually the greatest scale of all of these outputs). * They create a wl_buffer (which is just a dumb pile of pixels) with the content they just rendered. * They attach the wl_buffer to their surface and set the surface scale. * They commit the surface. The cursor image protocol would work like this: * The client receives wl_surface.enter for each output the cursor is on. * The client requests a cursor image with the new protocol with the greatest of these output scales. The compositor gives a wl_buffer containing the cursor image to the client. * The client attaches the buffer to the cursor surface, sets the scale and commits. That's why we need to add a scale parameter to the protocol: the client chooses the cursor scale. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Possible Wayland Extension to publish Mouse Pointer Size
Hi all, We've had a chat about cursor images on IRC yesterday. I'll try to sum up what we said. I've published the original logs too for reference [1]. First, it's clear that a protocol is needed. As we discussed earlier, this would allow: * Consistent cursors across all clients * Per-seat configuration * Not cluttering the environment * Live cursor theme changes I originally wanted to push forward a "compositor-side cursors" approach where the compositor loads the cursor theme and allows clients to create wl_buffers using this loaded theme. Some people (from KDE, GLFW if I recall correctly) said there's some overhead in loading cursors on the client-side (a few megabytes, I/O when loading images) and that could be saved. I assumed most compositors loaded cursor themes. However, it seems that this design could get in the way of protocol adoption because some compositors may not load cursor themes at all (and still want cursor configuration) and some compositors use a client helper to load cursor themes (e.g. Weston). This would make it more difficult (and maybe less effective) to implement such a protocol. Additionally, this protocol would be more complex to implement for compositors. In the end, Pekka and Jonas said we should have two protocols: a simple one used to configure xcursor (basically just sending the theme name and size to the client) and maybe a more complicated one (creating wl_buffers). The former would be easy to implement for all compositors while the latter could be implemented by a subset of compositors willing to support it. We also discussed how the new protocol should integrate with libwayland-cursor. It would be nice to have libwayland-cursor automatically use the new protocol if available. Currently the API looks like this: theme = wl_cursor_theme_load(theme_name, size, shm); cursor = wl_cursor_theme_get_cursor(theme, cursor_name); buffer = wl_cursor_image_get_buffer(cursor->images[frame_num]) It's clear that this API is not suitable for this new protocol. We'd like to extend it to allow the xcursor configuration protocol to be used, and if possible allow in the future a compositor-side cursor extension to be used. This could roughly look like something like this: manager = wl_cursor_manager_create(display, seat, scale, default_theme_name, default_theme_size) buffer = wl_cursor_manager_get_cursor(manager, cursor_name, frame_num) (This is just a draft -- all of this still needs to be discussed and is incomplete) I think that's about it. Please reply to this email if you think I forgot something, got something wrong or if something's unclear. I plan to work on a protocol proposal, and then on a libwayland-cursor API extension. Let me know if you're interested in helping out! Simon [1]: https://sr.ht/Pz-j.txt ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH RFC wayland-protocols] unstable: add xcursor-configuration
Clients are responsible for loading and setting cursors. For this purpose they often use XCursor images via the libwayland-cursor library. However clients have no way to know the user's preferred theme and size. This results in inconsistent cursors across clients (e.g. cursor growing bigger when entering a surface). This protocol fixes this issue by sending the user's XCursor preferences to the client. It also allows for per-seat cursor configuration. Signed-off-by: Simon Ser --- This is a draft of the XCursor configuration protocol. It's pretty simple. It still doesn't allow to configure differently wl_pointer's cursor and the tablet tool's cursor. Maybe this can be done with an enum and a new get_xcursor_configuration_seat argument? Comments welcome! unstable/xcursor-configuration/README | 4 + .../xcursor-configuration-unstable-v1.xml | 105 ++ 2 files changed, 109 insertions(+) create mode 100644 unstable/xcursor-configuration/README create mode 100644 unstable/xcursor-configuration/xcursor-configuration-unstable-v1.xml diff --git a/unstable/xcursor-configuration/README b/unstable/xcursor-configuration/README new file mode 100644 index 000..472e3bf --- /dev/null +++ b/unstable/xcursor-configuration/README @@ -0,0 +1,4 @@ +xcursor configuration protocol + +Maintainers: +Simon Ser diff --git a/unstable/xcursor-configuration/xcursor-configuration-unstable-v1.xml b/unstable/xcursor-configuration/xcursor-configuration-unstable-v1.xml new file mode 100644 index 000..9d9d840 --- /dev/null +++ b/unstable/xcursor-configuration/xcursor-configuration-unstable-v1.xml @@ -0,0 +1,105 @@ + + + +Copyright © 2018 Simon Ser + +Permission is hereby granted, free of charge, to any person obtaining a +copy of this software and associated documentation files (the "Software"), +to deal in the Software without restriction, including without limitation +the rights to use, copy, modify, merge, publish, distribute, sublicense, +and/or sell copies of the Software, and to permit persons to whom the +Software is furnished to do so, subject to the following conditions: + +The above copyright notice and this permission notice (including the next +paragraph) shall be included in all copies or substantial portions of the +Software. + +THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR +IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, +FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL +THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER +LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING +FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER +DEALINGS IN THE SOFTWARE. + + + +This protocol allows compositors to advertize XCursor configuration to +clients. + +Once compositor configuration is received, clients are responsible for +loading the XCursor theme, creating wl_buffers with cursor images and +setting the cursor. + +Warning! The protocol described in this file is experimental and +backward incompatible changes may be made. Backward compatible changes +may be added together with the corresponding interface version bump. +Backward incompatible changes are done by bumping the version number in +the protocol and interface names and resetting the interface version. +Once the protocol is to be declared stable, the 'z' prefix and the +version number in the protocol and interface names are removed and the +interface version number is reset. + + + + + A global factory interface for wp_xcursor_configuration objects. + + + + +Destroy the XCursor configuration manager. This doesn't destroy objects +created with the manager. + + + + + +This creates a new wp_xcursor_configuration object for the given +wl_seat. + + + + + + + + + A Xcursor configuration seat object describes XCursor settings for a + specific seat. + + + + +Using this request a client can tell the server that it is not going to +use this object anymore. + + + + + +This event is sent after all other properties of a +wp_xcursor_configuration have been sent. + +This allows changes to the wp_xcursor_configuration properties to be +seen as atomic, even if they happen via multiple events. + + + + + +The theme event describes XCursor theme configuration for this seat. + + + + + + + +The default_cursor event describes the default XCursor cursor name to be +used for this seat. + + + + + -- 2.19.1 ___
Re: [PATCH RFC wayland-protocols] unstable: add xcursor-configuration
Hi Michael,
Thanks for you comments! Replies below.
On Sunday, October 14, 2018 4:05 AM, Michael Arnold wrote:
> Step 3: When the application exists, if the application has made use of the
> zwp_xcursor_configuration_v1 extension then the application will initiate the
> following conversation with the compositor:
> * I get stuck here - there are two destructor requests both called 'destroy' -
> are they both required?
> * Neither of the 'destroy' requests have an id for the application to identify
> to the compositor what should be destroyed? I assume that the destroy
> request
> is associated with the get_xcursor_configuration_seat request, so
> in-principle
> an application can destroy the seat information if the application itself is
> multi-seat aware - is that right? In which case is a seat parameter
> required
> for the destroy request?
You are right about the "setup" sequence. The "teardown" sequence is very
simple: since the Wayland protocol works with objects, when you send a request
on an object, the object itself is an implicit parameter to the request (just
like in object-oriented programming languages). The same applies to events.
That means the "theme" and "default_cursor" events are associated with the
configuration. The destroy requests are associated with either the manager or
the configuration.
The full sequence could look like this for the client:
-> config = manager.get_xcursor_configuration_seat(seat)
config.theme("Adwaita", 24)
config.default_cursor("left_ptr")
config.done()
[use the config, run the app]
-> config.destroy()
-> manager.destroy()
> Questions:
> * What happens if a user changes the cursor theme / size / default cursor
> while
> the application is running? I assume that the compositor must create the
> 'theme', 'default_cursor' and 'done' events and the application must update
> the cursor accordingly?
Yeah. I've added this text for the next version to make it more clear:
The theme event is sent after creating a wp_xcursor_configuration
(see wp_xcursor_configuration_manager) and whenever the theme
configuration changes.
(Same for the default_cursor event)
> * Why are event 'theme' and event 'default_cursor' two separate events and not
> handled by one event with 3 attributes?
It's just to clearly make the difference between these two categories of
arguments.
> * Is 'theme' a good name for an event and not something like 'xcursor_theme'?
> * Is that implied by the context?
"xcursor" is already in the interface name, I don't think it's necessary to add
it one more time.
> * It is implied on the XCursor man page that a theme may not be set. In this
> case does the compositor return an empty theme 'name' on the 'theme' event?
> Or is the 'name' set to 'default' if no theme is set?
I think it would be enough to just send "default". This is what
libwayland-cursor uses when the theme name is NULL. Is it really necessary to
make the "theme" and "default_cursor" events optional?
> * I see that XCursor interface has
> (https://www.x.org/releases/current/doc/man/man3/Xcursor.3.xhtml):
> int XcursorGetDefaultSize (Display *dpy)//Gets the default cursor
> size.
> char *XcursorGetTheme (Display *dpy)//Gets the current theme name.
> I see that Display* is defined in Xlib.h and looks like it gets populated
> when
> the application connects to an X server. So I assume that the 'theme'
> event is
> required because the application can't interact with the XCursor library to
> get this information directly, because it does not have an XServer Display
> connection?
Right.
> * For the XCursor interface
> (https://www.x.org/releases/current/doc/man/man3/Xcursor.3.xhtml), I can't
> see
> where the default_cursor name is used. Likewise I can't see a setting for
> default_cursor name under Gnome settings or in dconf editor. What is the
> thinking behind the default_cursor event? Is this really the XCursor
> 'shape'
> parameter that the application needs to convert to an unsigned int?
The use-case is to e.g. set a tablet tool cursor to be a cross, so you can have
both a normal pointer for you mouse/touchpad and a cross pointer for your tablet
device. One could also use an alternative default cursor to be able to keep the
same theme for two seats but to be able to tell the difference between those
(e.g. by using left_ptr for one and right_ptr for the other).
This protocol allows things that aren't possible with the XCursor library, such
as setting a default cursor, having per-seat configuration and allowing live
cursor updates.
> * I see that Gnome settings has some interesting settings that are not
> included
> in XCursor like:
> - Is the primary button the left or right button?
> - What is the mouse cursor speed?
> I assume we'll pick those up in the more advanced protocol?
I think those are out-of-scope for this protocol. Actually both of these
features could be implemen
[PATCH wayland-protocols v3] unstable: add primary-selection protocol
From: emersion This primary selection is similar in spirit to the eponimous in X11, allowing a quick "select text + middle click" shortcut to copying and pasting. It's otherwise very similar to its Wayland counterpart, and explicitly made consistent with it. Signed-off-by: Simon Ser Reviewed-by: Jonas Ådahl Reviewed-by: Carlos Garnacho --- Makefile.am | 1 + unstable/primary-selection/README | 4 + .../primary-selection-unstable-v1.xml | 225 ++ 3 files changed, 230 insertions(+) create mode 100644 unstable/primary-selection/README create mode 100644 unstable/primary-selection/primary-selection-unstable-v1.xml diff --git a/Makefile.am b/Makefile.am index 6394e26..417c398 100644 --- a/Makefile.am +++ b/Makefile.am @@ -21,6 +21,7 @@ unstable_protocols = \ unstable/xdg-output/xdg-output-unstable-v1.xml \ unstable/input-timestamps/input-timestamps-unstable-v1.xml \ unstable/xdg-decoration/xdg-decoration-unstable-v1.xml \ + unstable/xdg-primary-selection/xdg-primary-selection-unstable-v1.xml \ $(NULL) stable_protocols = \ diff --git a/unstable/primary-selection/README b/unstable/primary-selection/README new file mode 100644 index 000..ae0a402 --- /dev/null +++ b/unstable/primary-selection/README @@ -0,0 +1,4 @@ +Primary selection protocol + +Maintainers: +Simon Ser diff --git a/unstable/primary-selection/primary-selection-unstable-v1.xml b/unstable/primary-selection/primary-selection-unstable-v1.xml new file mode 100644 index 000..e5a39e3 --- /dev/null +++ b/unstable/primary-selection/primary-selection-unstable-v1.xml @@ -0,0 +1,225 @@ + + + +Copyright © 2015, 2016 Red Hat + +Permission is hereby granted, free of charge, to any person obtaining a +copy of this software and associated documentation files (the "Software"), +to deal in the Software without restriction, including without limitation +the rights to use, copy, modify, merge, publish, distribute, sublicense, +and/or sell copies of the Software, and to permit persons to whom the +Software is furnished to do so, subject to the following conditions: + +The above copyright notice and this permission notice (including the next +paragraph) shall be included in all copies or substantial portions of the +Software. + +THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR +IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, +FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL +THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER +LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING +FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER +DEALINGS IN THE SOFTWARE. + + + +This protocol provides the ability to have a primary selection device to +match that of the X server. This primary selection is a shortcut to the +common clipboard selection, where text just needs to be selected in order +to allow copying it elsewhere. The de facto way to perform this action +is the middle mouse button, although it is not limited to this one. + +Clients wishing to honor primary selection should create a primary +selection source and set it as the selection through +wp_primary_selection_device.set_selection whenever the text selection +changes. In order to minimize calls in pointer-driven text selection, +it should happen only once after the operation finished. Similarly, +a NULL source should be set when text is unselected. + +wp_primary_selection_offer objects are first announced through the +wp_primary_selection_device.data_offer event. Immediately after this event, +the primary data offer will emit wp_primary_selection_offer.offer events +to let know of the mime types being offered. + +When the primary selection changes, the client with the keyboard focus +will receive wp_primary_selection_device.selection events. Only the client +with the keyboard focus will receive such events with a non-NULL +wp_primary_selection_offer. Across keyboard focus changes, previously +focused clients will receive wp_primary_selection_device.events with a +NULL wp_primary_selection_offer. + +In order to request the primary selection data, the client must pass +a recent serial pertaining to the press event that is triggering the +operation, if the compositor deems the serial valid and recent, the +wp_primary_selection_source.send event will happen in the other end +to let the transfer begin. The client owning the primary selection +should write the requested data, and close t
[PATCH wayland-protocols] unstable: add xcursor-configuration
Clients are responsible for loading and setting cursors. For this purpose they often use XCursor images via the libwayland-cursor library. However clients have no way to know the user's preferred theme and size. This results in inconsistent cursors across clients (e.g. cursor growing bigger when entering a surface). This protocol fixes this issue by sending the user's XCursor preferences to the client. It also allows for per-device cursor configuration. Signed-off-by: Simon Ser --- Makefile.am | 1 + unstable/xcursor-configuration/README | 4 + .../xcursor-configuration-unstable-v1.xml | 115 ++ 3 files changed, 120 insertions(+) create mode 100644 unstable/xcursor-configuration/README create mode 100644 unstable/xcursor-configuration/xcursor-configuration-unstable-v1.xml diff --git a/Makefile.am b/Makefile.am index 6394e26..7ac70ec 100644 --- a/Makefile.am +++ b/Makefile.am @@ -18,6 +18,7 @@ unstable_protocols = \ unstable/idle-inhibit/idle-inhibit-unstable-v1.xml \ unstable/xwayland-keyboard-grab/xwayland-keyboard-grab-unstable-v1.xml \ unstable/keyboard-shortcuts-inhibit/keyboard-shortcuts-inhibit-unstable-v1.xml \ + unstable/xcursor-configuration/xcursor-configuration-unstable-v1.xml \ unstable/xdg-output/xdg-output-unstable-v1.xml \ unstable/input-timestamps/input-timestamps-unstable-v1.xml \ unstable/xdg-decoration/xdg-decoration-unstable-v1.xml \ diff --git a/unstable/xcursor-configuration/README b/unstable/xcursor-configuration/README new file mode 100644 index 000..472e3bf --- /dev/null +++ b/unstable/xcursor-configuration/README @@ -0,0 +1,4 @@ +xcursor configuration protocol + +Maintainers: +Simon Ser diff --git a/unstable/xcursor-configuration/xcursor-configuration-unstable-v1.xml b/unstable/xcursor-configuration/xcursor-configuration-unstable-v1.xml new file mode 100644 index 000..b479c6f --- /dev/null +++ b/unstable/xcursor-configuration/xcursor-configuration-unstable-v1.xml @@ -0,0 +1,115 @@ + + + +Copyright © 2018 Simon Ser + +Permission is hereby granted, free of charge, to any person obtaining a +copy of this software and associated documentation files (the "Software"), +to deal in the Software without restriction, including without limitation +the rights to use, copy, modify, merge, publish, distribute, sublicense, +and/or sell copies of the Software, and to permit persons to whom the +Software is furnished to do so, subject to the following conditions: + +The above copyright notice and this permission notice (including the next +paragraph) shall be included in all copies or substantial portions of the +Software. + +THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR +IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, +FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL +THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER +LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING +FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER +DEALINGS IN THE SOFTWARE. + + + +This protocol allows compositors to advertize XCursor configuration to +clients. + +Once compositor configuration is received, clients are responsible for +loading the XCursor theme, creating wl_buffers with cursor images and +setting the cursor. Clients are free to ignore configuration set by this +protocol and use different settings: this protocol merely exposes hints. + +Warning! The protocol described in this file is experimental and +backward incompatible changes may be made. Backward compatible changes +may be added together with the corresponding interface version bump. +Backward incompatible changes are done by bumping the version number in +the protocol and interface names and resetting the interface version. +Once the protocol is to be declared stable, the 'z' prefix and the +version number in the protocol and interface names are removed and the +interface version number is reset. + + + + + A global factory interface for wp_xcursor_configuration objects. + + + + +Destroy the XCursor configuration manager. This doesn't destroy objects +created with the manager. + + + + + +Describes input devices that have a cursor and are attached to a seat. + + + + + + + +This creates a new wp_xcursor_configuration object for the input device +attached to the given seat. + + + + + + + + + + A Xcursor configur
Re: [PATCH RFC wayland-protocols] unstable: add xcursor-configuration
On Tuesday, October 16, 2018 2:10 PM, Johan Helsing wrote: > Hi Simon, > > Thanks for working on this! :) Thanks for your feedback! I've sent a first version of this patch. I've added per-device configuration and addressed your comments. Let me know what you think. > Is the intention to implement the client side inside libwayland-cursor? No > changes needed for toolkits except calling some new API when initializing > libwayland-cursor? Yeah, this is what's planned. The new design of the libwayland-cursor API will be the difficult part of this task. I'll try to send a proposal soon. > I guess it's also possible to implement it on the toolkit level using the old > libwayland-cursor API... Which would allow us to use the extension before > everyone has upgraded to the new libwayland-cursor. Aye, this is possible. > > + > > To me, this sounds a bit like we're getting some kind of seat from the > request. How about get_seat_xcursor_configuration? Or simply > get_xcursor_configuration? This makes sense, I'll rename to get_device_xcursor_configuration. I'd like to make sure we can add new requests to create xcursor configuration objects in the future, so I'd like to keep "device" in there. > > + > > + > > + The default_cursor event describes the default XCursor cursor name > > to be > > + used for this seat. > > + > > Maybe explain the use case here? The use-case is to be able to tell the difference between two cursors without having to pick two different cursor themes. For instance one could choose left_ptr for the pointer and cross for the tablet tool. Do you think we should include this example in the protocol? > And another thing, maybe we can explicitly say this is a hint for the client? > I'm asking because I don't think we have a matching concept of a default > cursor in Qt... We just have Qt::QCursorShape::ArrowCursor. We could > make this request override what that shape is, but that might be confusing > to application developers if some compositor decides to set the default > cursor to a cross or some other non-arrow cursor. Anyway, this event is > going to cause some minor issues in Qt, perhaps in other toolkits as well. You're right, I've mentioned this in the protocol description. Everything in this protocol is a hint, clients could use it to e.g. just choose the cursor size and use a custom theme. For Qt, you could e.g. use default_cursor if the app doesn't set the cursor itself, and switch to Qt::QCursorShape::ArrowCursor if the app requests it. Of course, having Qt::QCursorShape::DefaultCursor would be nice too. > Otherwise, this looks great :) Looking forward to having uniform cursor > sizes! > > Johan ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH RFC] cursor: add wl_cursor_manager
Signed-off-by: Simon Ser
---
This patch only includes changes to libwayland-cursor's header file.
The goal is to show how the new API could look like.
This patch adds a new wl_cursor_manager. When created, it only binds
to wl_shm and discovers additional protocols the compositor might
support. These include the xcursor-configuration protocol draft [1]
and the future compositor cursors protocol. In order to make sure this
libwayland-cursor API is compatible with the latter, a proof-of-concept
(undocumented) protocol has been drafted [2].
This manager allows users to create cursor themes (wl_cursor_theme) by
specifying a seat, an input device type and a scale factor. Then
individual cursors (wl_cursor) with cursor image metadata
(wl_cursor_image) can be retrieved as usual. Buffers (wl_buffer) can
be created with cursor images.
We are pretty lucky because wl_cursor_theme is an opaque struct and
wl_cursor doesn't expose raw image data. I hope we can continue to
use the existing API and make it work with both protocols by simply
adding this new wl_cursor_manager.
Is it necessary to add a default_theme and a default_size argument
to wl_cursor_manager_create?
As always, comments and questions are welcome!
[1]: https://patchwork.freedesktop.org/series/50948/
[2]: https://gist.github.com/emersion/ad8225bbe30767d6821346c08fda407a
cursor/wayland-cursor.h | 20
1 file changed, 20 insertions(+)
diff --git a/cursor/wayland-cursor.h b/cursor/wayland-cursor.h
index 40d3fc5..9523de6 100644
--- a/cursor/wayland-cursor.h
+++ b/cursor/wayland-cursor.h
@@ -70,6 +70,26 @@ int
wl_cursor_frame_and_duration(struct wl_cursor *cursor, uint32_t time,
uint32_t *duration);
+struct wl_cursor_manager;
+struct wl_registry;
+
+enum wl_cursor_device_type {
+ WL_CURSOR_DEVICE_TYPE_POINTER,
+ WL_CURSOR_DEVICE_TYPE_TABLET_TOOL,
+};
+
+struct wl_cursor_manager *
+wl_cursor_manager_create(struct wl_registry *registry);
+
+void
+wl_cursor_manager_destroy(struct wl_cursor_manager *manager);
+
+struct wl_cursor_theme *
+wl_cursor_manager_get_theme(struct wl_cursor_manager *manager,
+ struct wl_seat *seat,
+ enum wl_cursor_device_type device,
+ int32_t scale);
+
#ifdef __cplusplus
}
#endif
--
2.19.1
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH RFC] cursor: add wl_cursor_manager
Ah, I forgot to say that an issue with this design is that some libwayland-cursor would need to block until the compositor sends the required metadata (ala-wl_display_roundtrip). I'm not sure if this is an issue or not. If we don't want to block, then we'll need a much more complicated design with callbacks or signals, and we wouldn't be able to re-use parts of the current API. Thoughts? ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH] cursor: add wl_cursor_manager and xcursor-configuration-unstable-v1
The xcursor-configuration protocol allows compositors to send
xcursor theme configuration to clients.
Support for this protocol has been added to libwayland-cursor via
a new wl_cursor_manager API.
Signed-off-by: Simon Ser
---
This patch implements the new libwayland-cursor API. A simple client
proof-of-concept [1] and a wlroots compositor implementation [2] are
available.
Known issues:
1. This design requires to call wl_display_dispatch in libwayland-cursor,
is this acceptable?
2. This design doesn't support live theme updates. Toolkits can always
roll their own implementation of the protocol if they want to support
it. Is this an issue?
3. To avoid circular dependencies to wayland-protocols, the protocol file
has been copied over. Is there a better solution?
I'm also not sure about code style, especially when there are very long
function names.
Comments and ideas welcome!
[1]: https://github.com/emersion/hello-wayland/tree/xcursor-configuration
[2]: https://github.com/swaywm/wlroots/pull/1324
Makefile.am | 7 +-
cursor/wayland-cursor.c | 187 +-
cursor/wayland-cursor.h | 21 ++
.../xcursor-configuration-unstable-v1.xml | 115 +++
4 files changed, 328 insertions(+), 2 deletions(-)
create mode 100644 protocol/xcursor-configuration-unstable-v1.xml
diff --git a/Makefile.am b/Makefile.am
index 697c517..1624c75 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -117,7 +117,9 @@ BUILT_SOURCES = \
$(nodist_libwayland_server_la_SOURCES) \
$(nodist_libwayland_client_la_SOURCES) \
$(nodist_headers_test_SOURCES) \
- $(nodist_display_test_SOURCES)
+ $(nodist_display_test_SOURCES) \
+ protocol/xcursor-configuration-unstable-v1-client-protocol.h \
+ protocol/xcursor-configuration-unstable-v1-protocol.c
CLEANFILES = $(BUILT_SOURCES) doc/doxygen/doxygen_sqlite3.db
DISTCLEANFILES = src/wayland-version.h
@@ -136,6 +138,9 @@ libwayland_cursor_la_SOURCES = \
cursor/cursor-data.h\
cursor/xcursor.c\
cursor/xcursor.h
+nodist_libwayland_cursor_la_SOURCES = \
+ protocol/xcursor-configuration-unstable-v1-client-protocol.h \
+ protocol/xcursor-configuration-unstable-v1-protocol.c
libwayland_cursor_la_LIBADD = libwayland-client.la
pkgconfig_DATA += cursor/wayland-cursor.pc
diff --git a/cursor/wayland-cursor.c b/cursor/wayland-cursor.c
index d40c5c8..bdd8464 100644
--- a/cursor/wayland-cursor.c
+++ b/cursor/wayland-cursor.c
@@ -27,6 +27,7 @@
#include "xcursor.h"
#include "wayland-cursor.h"
#include "wayland-client.h"
+#include
#include
#include
#include
@@ -37,6 +38,7 @@
#include
#include "os-compatibility.h"
+#include "xcursor-configuration-unstable-v1-client-protocol.h"
#define ARRAY_LENGTH(a) (sizeof (a) / sizeof (a)[0])
@@ -137,6 +139,8 @@ struct wl_cursor_theme {
struct shm_pool *pool;
char *name;
int size;
+
+ char *default_cursor;
};
struct cursor_image {
@@ -403,6 +407,7 @@ wl_cursor_theme_load(const char *name, int size, struct
wl_shm *shm)
theme->size = size;
theme->cursor_count = 0;
theme->cursors = NULL;
+ theme->default_cursor = NULL;
theme->pool = shm_pool_create(shm, size * size * 4);
if (!theme->pool)
@@ -436,6 +441,7 @@ wl_cursor_theme_destroy(struct wl_cursor_theme *theme)
shm_pool_destroy(theme->pool);
+ free(theme->default_cursor);
free(theme->name);
free(theme->cursors);
free(theme);
@@ -444,7 +450,7 @@ wl_cursor_theme_destroy(struct wl_cursor_theme *theme)
/** Get the cursor for a given name from a cursor theme
*
* \param theme The cursor theme
- * \param name Name of the desired cursor
+ * \param name Name of the desired cursor or %NULL for the default one
* \return The theme's cursor of the given name or %NULL if there is no
* such cursor
*/
@@ -454,6 +460,11 @@ wl_cursor_theme_get_cursor(struct wl_cursor_theme *theme,
{
unsigned int i;
+ if (!name)
+ name = theme->default_cursor;
+ if (!name)
+ name = "left_ptr";
+
for (i = 0; i < theme->cursor_count; i++) {
if (strcmp(name, theme->cursors[i]->name) == 0)
return theme->cursors[i];
@@ -527,3 +538,177 @@ wl_cursor_frame(struct wl_cursor *_cursor, uint32_t time)
{
return wl_cursor_frame_and_duration(_cursor, time, NULL);
}
+
+struct wl_cursor_manager {
+ struct wl_display *display;
+ struct wl_registry *registry;
+ struct wl_shm *shm;
+ struct zwp_xcursor_configuration_manager_v1 *configuration_manager;
+};
+
+s
Re: [PATCH wayland-protocols v3] unstable: add primary-selection protocol
Hi Jonas, Any news about this? Thanks, Simon ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH v3] protocol: warn clients about some wl_output properties
All wl_output properties don't always make sense for all compositors. Some compositors might not implement a "global compositor space", (e.g. 3D compositors) in which case properties like x and y don't make sense. Some compositors might expose virtual outputs, in which case modes, make and model are not relevant. In a lot of these situations, information from xdg_output is better suited. Compositors also expose output refresh rate, which shouldn't be used for synchronization purposes. Signed-off-by: Simon Ser --- Thoughts? Changes from v2 to v3: forgot to mention wl_surface.frame. protocol/wayland.xml | 19 ++- 1 file changed, 18 insertions(+), 1 deletion(-) diff --git a/protocol/wayland.xml b/protocol/wayland.xml index 141038b..9a841f8 100644 --- a/protocol/wayland.xml +++ b/protocol/wayland.xml @@ -2402,6 +2402,13 @@ The physical size can be set to zero if it doesn't make sense for this output (e.g. for projectors or virtual outputs). + + Note: wl_output only advertises partial information about the output + position and identification. Some compositors, for instance those not + implementing a desktop-style output layout or those exposing virtual + outputs, might fake this information. Instead of using x and y, clients + should use xdg_output.logical_position. Instead of using make and model, + clients should use xdg_output.name and xdg_output.description. @@ -2446,7 +2453,17 @@ the output device. This is not necessarily the same as the output size in the global compositor space. For instance, the output may be scaled, as described in wl_output.scale, - or transformed, as described in wl_output.transform. + or transformed, as described in wl_output.transform. Clients + willing to retrieve the output size in the global compositor + space should use xdg_output.logical_size instead. + + Clients should not use the refresh rate to schedule frames. Instead, + they should use the wl_surface.frame event or the presentation-time + protocol. + + Note: this information is not always meaningful for all outputs. Some + compositors, such as those exposing virtual outputs, might fake the + refresh rate or the size. -- 2.19.1 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] protocol: allow to send a zero output refresh rate
Hi, What do you think of this patch? Thanks, Simon ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] cursor: use memfd_create or shm_open for anonymous in-memory files
Bump. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
