Re: [PATCH wayland-protocols v7] unstable: add xdg-decoration protocol

[Alan Griffiths]

Reviewed-by: Alan Griffiths 


On 18/06/18 11:16, 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 announce support for server-side
> +  decorations.
> +
> +  A window decorati

Re: wayland-protocols scope and governance

[Alan Griffiths]

On 13/11/2019 21:22, Christopher James Halse Rogers wrote:
>
>
> On Wed, Nov 13, 2019 at 16:21, Jonas Ådahl  wrote:
>> On Tue, Nov 12, 2019 at 08:13:58PM +, Daniel Stone wrote:
>>
>> Hi, On Thu, 10 Oct 2019 at 16:12, Simon Ser > > wrote: > This document governs the
>> maintenance of wayland-protocols and serves to outline > the
>> broader process for standardization of protocol extensions in the
>> Wayland > ecosystem. 
>>
> We at Mir would also be interested; developing and pushing extensions
> has not (yet) hit the top of our TODO list, but we have Thoughts,
> experience, and a place to implement them :).
I can confirm that, both for Mir and also for our wlcs project.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH wayland-protocols] Add governance document

[Alan Griffiths]

Acked-by: Mir team (alan.griffi...@canonical.com)
On 14/11/2019 16:10, Simon Ser wrote:
> The idea of a better-defined governance model for wayland-protocols has
> been discussed for quite a while [1].
>
> A new GOVERNANCE document describes how changes to the wayland-protocols
> repository are accepted. A set of members representing projects can vote
> on merge requests sent via GitLab. The initial list of members is
> available in the MEMBERS file.
>
> [1]: 
> https://lists.freedesktop.org/archives/wayland-devel/2019-February/040076.html
>
> Signed-off-by: Drew DeVault 
> Signed-off-by: Simon Ser 
> Acked-by: Daniel Stone 
> Acked-by: Pekka Paalanen 
> Acked-by: Johan Helsing 
> Acked-by: Roman Gilg 
> Cc: Mike Blumenkrantz 
> Cc: Jonas Ådahl 
> Cc: Carlos Garnacho 
> Cc: David Edmundson 
> Cc: Christopher James Halse Rogers 
> Cc: Alan Griffiths 
> ---
>  GOVERNANCE | 149 +
>  MEMBERS|  11 
>  2 files changed, 160 insertions(+)
>  create mode 100644 GOVERNANCE
>  create mode 100644 MEMBERS
>
> diff --git a/GOVERNANCE b/GOVERNANCE
> new file mode 100644
> index ..912ae5bb8808
> --- /dev/null
> +++ b/GOVERNANCE
> @@ -0,0 +1,149 @@
> +  wayland-protocols governance
> +
> +This document governs the maintenance of wayland-protocols and serves to 
> outline
> +the broader process for standardization of protocol extensions in the Wayland
> +ecosystem.
> +
> + 1. Membership
> +
> +Membership in wayland-protocols is offered to stakeholders in the Wayland
> +ecosystem who have an interest in participating in protocol extension
> +standardization.
> +
> +  1.1. Membership requirements
> +
> +a. Membership is extended to projects, rather than individuals.
> +b. Members represent general-purpose projects with a stake in multiple 
> Wayland
> +   protocols (e.g. compositors, GUI toolkits, etc), rather than 
> special-purpose
> +   applications with a stake in only one or two.
> +c. Each project must provide one or two named individuals as 
> points-of-contact
> +   for that project who can be reached to discuss protocol-related matters.
> +d. During a vote, if two points-of-contact for the same member disagree, the
> +   member's vote is considered blank.
> +
> + 1.2. Becoming a member
> +
> +a. New members who meet the criteria outlined in 1.1 are established by
> +   invitation from an existing member. Projects hoping to join should reach 
> out
> +   to an existing member asking for this invitation.
> +b. New members shall write to the wayland-devel mailing list stating their
> +   intention of joining and their sponsor.
> +c. The sponsor shall respond acknowledging their sponsorship of the 
> membership.
> +d. A 14 day discussion period for comments from wayland-protocols members 
> will
> +   be held.
> +e. At the conclusion of the discussion period, the new membership is 
> established
> +   unless their application was NACKed by a 1/2 majority of all existing 
> members.
> +
> +1.3. Ceasing membership
> +
> +a. A member may step down by writing their intention to do so to the
> +   wayland-devel mailing list.
> +b. A removal vote may be called for by an existing member by posting to the
> +   wayland-devel mailing list. This begins a 14 day voting & discussion
> +   period.
> +c. At the conclusion of the voting period, the member is removed if the votes
> +   total 2/3rds of all current members.
> +d. Removed members are not eligible to apply for membership again for a 
> period
> +   of 1 year.
> +e. Following a failed vote, the member who called for the vote cannot
> +   call for a re-vote or propose any other removal for 90 days.
> +
> +  2. Protocols
> +
> +2.1. Protocol namespaces
> +
> +a. Namespaces are implemented in practice by prefixing each interface name 
> in a
> +   protocol definition (XML) with the namespace name, and an underscore (e.g.
> +   "xdg_wm_base").
> +b. Protocols in a namespace may optionally use the namespace followed by a 
> dash
> +   in the name (e.g. "xdg-shell").
> +c. The "xdg" namespace is established for protocols letting clients
> +   configure its surfaces as "windows", allowing clients to affect how they
> +   are managed.
> +d. The "wp" namespace is established for protocols generally useful to 
> Wayland
> +   implementations (i.e. "plumbing" protocols).
> +e. The "ext" namespace i

Re: XDG_RUNTIME_DIR on a system with no "logins"

[Alan Griffiths]

On 19/12/2019 10:28, Guillermo Rodriguez wrote:
> Uhm. I am not sure I can switch to systemd at this point.
> How does this (Weston being ready / not ready) look like from the client side?
>
> i.e. if I want to make sure the client is launched once Weston is ready,
> 1. Is there any way to manually check whether Weston is ready? (e.g.
> some sentinel file being created or similar)
> or failing that,
> 2. Is there any recognizable error code if the client tries to launch
> before Weston is ready (so that I can wait a bit and retry)

I can't answer specifically for Weston, but I imagine this would be the
same for any Wayland compositor.

With our IoT solutions we wait for the $XDG_RUNTIME_DIR/$WAYLAND_DISPLAY
file (or $XDG_RUNTIME_DIR/wayland-0) file before trying to connect. The
server ought to be ready once that has been created.

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

zwp_fullscreen_shell_v1

[Alan Griffiths]

Hi,

with Mir's "mir-kiosk" being deployed for running single, fullscreen
apps there are requests for ways that the apps can control the output
mode. Looking at zwp_fullscreen_shell_v1 this appears to meet many of
these requirements. However, it is "unstable" and I don't see evidence
of it being widely used.

So, what is the status of this extension protocol? Is it mostly
forgotten? Or just waiting for a final push to stable?

Thanks,
Alan

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: zwp_fullscreen_shell_v1

[Alan Griffiths]

On 08/01/2020 10:01, Jonas Ådahl wrote:
> This idea has more or less been abandoned however, so I'd say it's more
> likely we can "archive" it rather than marking it as stable, as there
> are as far as I know no real users of it.

Thanks for that

> For kiosk mode, you still probably want to use xdg-shell, as it's not
> unlikely the kiosk application still wants to use things like popup
> surfaces for drop down menus etc. Your compositor can, when in kiosk
> mode, for example only allow one client, with only a single toplevel,
> that is always configured as fullscreen.

Yes, we do that already. I was looking for an approach that also allows
the app to configure, for example, the screen resolution.

Alan

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Call for an EDID parsing library

[Alan Griffiths]

On 07/04/2021 13:40, Jonas Ådahl wrote:

On Wed, Apr 07, 2021 at 10:59:18AM +, Simon Ser wrote:

FWIW, with my Sway/wlroots hat on I think this is a great idea and I'd
definitely be interested in using such as library. A C API with no
dependencies is pretty important from my point-of-view.

I'd prefer if C++ was not used at all (and could almost be baited into
doing the work if that were the case), but it seems that ship has
sailed already.

The same for Mutter / GNOME, not having to maintain a EDID parser would
be great. Though personally I don't care if it's implemented in C++, C
or whatever, as long as there is a C API to use.

Mir too - although a C++ API would be also fine for us.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Window positions under wayland

[Alan Griffiths]

On 08/08/2022 09:05, JiDe Zhang wrote:

Hi:

Is it that more people think that not allowed the window to set their 
position is better? I think that Wayland is better than X11 In this 
regard. It is correct to not let the window be set position, But some 
people will have doubts, because their know that some windows need to 
set their own position. We should pay attention to these needs and 
analyze what is the real reason their need for this interface,



It is entirely understandable for the designers of applications and 
application toolkits to be surprised they don't have the control they 
have in other windowing systems (X11, Windows, whatever). For decades 
they've been used to deciding where their windows go. Trusting the 
compositor to do that is a surprise.



But in the real world, they have to conform to a small number idioms 
that users recognise, and supporting those is very possible without 
allowing "full control". We've done some work on classifying these 
idioms for Mir and there's a presentation of our findings here:



https://mir-server.io/docs/window-positions-under-wayland


The tl;dr is that most of the idioms (regular windows, dialogs, menus, 
popus, tooltips, hovers, satellites, toolboxes) are already supported 
and there's no fundamental problem extending the existing approach used 
by Wayland to cover others. (Most of the support needed can be cut & 
paste from other idioms.)

Re: Window positions under wayland

[Alan Griffiths]

On 09/08/2022 03:36, JiDe Zhang wrote:
Thanks. I read 
https://mir-server.io/docs/window-positions-under-wayland, Is your 
standpoint by adding more shell protocols to support windows that 
behave differently rather than allowing the client to take full 
control window position to implement some special behavior? Agree, 
wayland should maintain its current design goals.


--JiDe Zhang -- linuxdeepin.



Note that I don't speak for the whole Wayland community, just as an 
implementer of one of many Wayland compositors. But yes, that's what has 
happened with moving from wl-shell to xdg-shell and with more 
specialised extensions such as xdg-foreign and wlr-layer-shell. I 
anticipate that where there is sufficient justification additional 
features will be added either by updating existing extensions or by 
adding new ones.

Re: Qustion: Support for Splitting Application Output Across Multiple Displays in Weston

[Alan Griffiths]

On 29/03/2024 01:20, Yosuke Nakayama wrote:

Dear Wayland-devel Community,

I am currently exploring the capabilities of Weston, the reference 
compositor for Wayland, specifically in the context of an application 
use case that I am working on. My goal is to achieve a functionality 
where the graphical output of a single application can be divided and 
displayed simultaneously across two separate displays. This 
functionality would enable part of the application window to be shown 
on one display and the rest on another, effectively spanning the 
application window across multiple screens.


From my understanding and current experimentation with Weston, this 
particular use case does not seem to be directly supported, but I'm 
not sure. Does functionality exist at this time to achieve such a use 
case?


I don't think this is currently supported by Weston. But it is supported 
by Ubuntu Frame 
<https://mir-server.io/docs/how-to-configure-ubuntu-frame-for-multiple-outputs>. 
Does you usecase allow you to consider alternative compositors?




Thank you for your time and assistance!

Best regards,



--
Canonical-20th-anniversary

Alan Griffiths

Senior Engineer (Mir)

Location:



United Kingdom

canonical.com

<https://canonical.com/>

ubuntu.com

<https://ubuntu.com/>