Re: Weston mirror/clone to 2 different displays

[Marius Vlad]

On Mon, Apr 29, 2024 at 08:55:31PM +, Dawn HOWE wrote:
> Hello,
Hi,
> 
> I posted a question last year about mirroring/cloning to LVDS/hdmi on
> an imx8, which is not supported by the display driver. This thread
> suggests that a solution for this was being worked last June, but I
> have not seen follow up on the topic since then.  Is there any change
> in the status?
Yes, we landed that in Weston 13, but configuring was left out
for the next version. That work is currently WIP at 
https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1476
> 
> thanks,
> Dawn
> 
> 
> 
> 
> From: Daniel Stone 
> Sent: Friday, June 23, 2023 10:04 AM
> To: Dawn HOWE 
> Cc: wayland-devel@lists.freedesktop.org 
> Subject: Re: Weston mirror/clone to 2 different displays
> 
> Hi Dawn,
> 
> On Thu, 22 Jun 2023 at 18:09, Dawn HOWE 
> mailto:dawn.h...@alten.com>> wrote:
> 
> I am developing an (embedded) medical device which is required to have a 
> touchscreen display and also mirror the output to a monitor connected via 
> HDMI. The device is using Wayland/Weston on TorizonCore (based on a yocto 
> kirkstone). I am able to get the display extended from HDMI to LVDS, but not 
> have the output mirrored to both displays. I posted a query on the Toradex 
> community, and received a response that Weston may not be capable of doing 
> this. 
> (https://community.toradex.com/t/apalis-imx8-hdmi-and-lvds-display-not-mirroring-cloning/19869).
> 
> 
> 
> I have searched and found some old posts from several years ago indicating 
> that it was not supported, but may be with a patch. I understand that 
> “same-as” configuration in weston.ini does not work for my scenario.
> 
> 
> 
> What is the current state of cloning/mirroring to two different outputs, but 
> on the same card. E.g (card1-HDMI-A-1 and card1-LVDS-1):
> 
> 
> ls /sys/class/drm
> 
> card0  card1  card1-HDMI-A-1  card1-LVDS-1  renderD128  
> renderD129  version
> 
> Weston can currently mirror it if the display driver directly supports it. 
> You can use the same-as configuration option (see man weston-drm) to enable 
> this. If your display driver doesn't support this in the kernel, then Weston 
> won't do it for now, but we are actively working on this and expect to have a 
> branch capable of this within the next couple of weeks or so.
> 
> Cheers,
> Daniel
> The information contained in this e-mail and any attachments are intended 
> solely for the addressees. If you have received this email in error, please 
> contact the sender and delete the email from your system.


signature.asc
Description: PGP signature

Re: Wayland design principles (Re: wayland and gambas)

[Thiago Macieira]

On Monday 29 April 2024 14:38:10 GMT-7 Bruce Steers wrote:
> Some have no issue like my text editor for example, a standard looking
> editor with window and title bar.
> 
> Although gambas provides a Settings.Write(window_name) /
> Settings.Read(window_name) that saves/restores the window placement and
> size. It's bearable Wayland does not handle this.

Indeed. I don't see the need for most applications to attempt to remember 
their last position. They'll often get it wrong, like opening on the monitor 
I'm not looking at (this annoyed me a lot in X).

Quite frankly, the majority of applications that thought they knew better, 
didn't.

> Other applications I have made include a customizable LCD clock that runs
> at startup and places itself "where I want it"
>
> And a program called Desktop-ish that shows .desktop file folders I can
> customize/add and has many features like customizable menus I have added
> many many things to that are very useful to me.
>
> This also places itself "where I want it"

Both of those sound like like a compositor / window manager feature, not in-
application. The compositor knows the full extent of the display and what else 
is there. For example, if you placed the window on the top-right corner of 
your display, but later enlarged to another monitor, the compositor would know 
whether to move there or not, possibly depending on some characteristics of 
the monitor that was connected (is it a monitor, a TV or a projector?)

By moving this functionality into the compositor / window manager, it can also 
be done for other applications that didn't think to code it. For example, a 
developer may want to always have a terminal on the bottom half of the screen 
or the left half or something, or a web browser window opened on their chat 
website. Or a system monitor application always overlaid on top.

Yes, this would remove some functionality for those users who don't use a 
compositor with those features.

> My Linux is very personalized and works very well for my needs. (It's
> awesome 😎)

Have you tried choosing a better compositor?

> The same could probably be said for many gambas coders.

And of Wayland developers too, as well as a good chunk of all UI developers on 
Linux. I'm not either, actually: I develop a non-graphical library. And I have 
a very customised desktop.

I have a couple of annoyances after the switch to Wayland (for example, 
Firefox can't restore the windows to the virtual desktops they used to be on). 
So I file bugs and requests for improvement where I can't fix things myself. 
There's nothing I've found that would be a *Wayland* showstopper; most of what 
I've found are regular bugs or unimplemented features in the compositor I'm 
using.

The only functionality I've completely lost is KeyPassXC's auto-type feature.

> Now Wayland has come along and seems to be...
> "you can no longer control window placement, deal with it, why even want
> it?, we decided you don't need it"
> 😕
> 
> It is unacceptable for the many who have customized their Linux world with
> their own work.

Are we talking about people who write applications for a single user, 
themselves? That's an incredibly rare type of user and application.

The majority of applications are written for multiple users, who will each 
have different preferences. Compositors are also written for the majority of 
applications, which have little need for absolute positioning. I'm not saying 
there are no use cases: your application and your compositor can have an 
extension that allows them to do something not in the standard Wayland or the 
XDG shell extension. Absolute positioning has been implemented for some 
compositors.

Also, it's not "now". This decision is about 15 years old.

> There is worry in our community that Wayland is going to take over and x11
> will become obsolete.

That's a feature, not a bug. It's the intent. You should also look at the pace 
of development of the implementations: you'll notice that X.org is very much 
in maintenance mode, going on "bug compatibility" mode.

That being the case, you and your community should engage the Wayland 
community and advocate for the features you need given the use-cases you have 
(not the solutions you've had). That community also includes compositor 
developers, some of whom may be more open to further extensions than others. 
For example, kwin_wayland does implement "server-side decorations", a feature 
that other Wayland compositors, including Weston, (IIUC) don't want.

> And because nobody at Wayland seems to care to provide a means of placement
> choice, should you want/need it.

That's factually incorrect.

There are Wayland compositors that implement absolute positioning as an 
extension. They are not mainstream and the extension isn't a standard one, but 
they exist.

> Yes I forgot the screen grabs not being available is a downgrade for us.
> For example simple colour picker routines many of us have don't work now.
> Eg.
> PickedC

Re: Wayland design principles (Re: wayland and gambas)

[Bruce Steers]

On Mon, 29 Apr 2024, 20:53 Thiago Macieira,  wrote:

> On Monday 29 April 2024 10:05:32 GMT-7 Bruce Steers wrote:
> > I guess/hope a similar thing will happen to x11 or Wayland will accept
> this
> > particular issue needs addressing and provide a workaround.
> >
> > As fundamentally Wayland principles are to us, restrictive in a way that
> I
> > think many will simply not tolerate.
>
> Please describe the need you have, not the means by which you think you
> can
> solve the need. For example, why do you think you need to specify absolute
> positioning for certain windows?
>

I personally have written many applications with gambas.

Some have no issue like my text editor for example, a standard looking
editor with window and title bar.

Although gambas provides a Settings.Write(window_name) /
Settings.Read(window_name) that saves/restores the window placement and
size. It's bearable Wayland does not handle this.

Other applications I have made include a customizable LCD clock that runs
at startup and places itself "where I want it"

And a program called Desktop-ish that shows .desktop file folders I can
customize/add and has many features like customizable menus I have added
many many things to that are very useful to me.

This also places itself "where I want it"

My Linux is very personalized and works very well for my needs. (It's
awesome 😎)

The same could probably be said for many gambas coders.

Now Wayland has come along and seems to be...
"you can no longer control window placement, deal with it, why even want
it?, we decided you don't need it"
😕

It is unacceptable for the many who have customized their Linux world with
their own work.

There is worry in our community that Wayland is going to take over and x11
will become obsolete.

And because nobody at Wayland seems to care to provide a means of placement
choice, should you want/need it.

I hope you understand.


> The Wayland philosophy on this has been that the compositor knows best
> where
> to place the windows for regular applications. That does not include fixed
> desktop components, such as the task bar or desktop wallpapers, but those
> need
> to communicate directly with the compositor they are a desktop for.
>

For the most part, sure why not?

For the case detailed above. Most definitely not mine and many others
philosophy.


> Someone may have said they had a need to grab the keyboard and obtain key
> events even when the window wasn't focused. But why is that? X11 uses
> keyboard-grabbing to implement dismissal of popup menus, something that
> Wayland solved properly instead. Another use-case was to ensure that focus
> couldn't be stolen while typing a password... again, Wayland can solve
> that by
> the window describing itself as "I'm recording a password" so the
> compositor
> can implement a higher focus-stealing threshold or other
> attention-grabbing
> techniques (how many of us have typed passwords in the wrong window?).
>
> Other things are done for security: you can't inject events into other
> windows, so we lose the auto-type feature in KeyPassXC. You can't perform
> arbitrary screengrabs any more, but instead screensharing applications
> must
> ask the compositor to let the user choose which window(s) to share.
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>Principal Engineer - Intel DCAI Cloud Engineering
>

Yes I forgot the screen grabs not being available is a downgrade for us.
For example simple colour picker routines many of us have don't work now.
Eg.
PickedColour = Desktop.Screenshot(Mouse.x, Mouse.y).Image[0, 0]

It was that simple.

Mostly Wayland seems okay.
But paranoid it seems as mostly citing "security" for all it's misgivings.
I'm not a govt agency my computer has no nasty secrets I need to hide and
is secure enough for me.

 I hope you understand our dilemma here.

With respects
Bruce Steers

Re: Weston mirror/clone to 2 different displays

[Dawn HOWE]

Hello,

I posted a question last year about mirroring/cloning to LVDS/hdmi on an imx8, 
which is not supported by the display driver. This thread suggests that a 
solution for this was being worked last June, but I have not seen follow up on 
the topic since then.  Is there any change in the status?

thanks,
Dawn




From: Daniel Stone 
Sent: Friday, June 23, 2023 10:04 AM
To: Dawn HOWE 
Cc: wayland-devel@lists.freedesktop.org 
Subject: Re: Weston mirror/clone to 2 different displays

Hi Dawn,

On Thu, 22 Jun 2023 at 18:09, Dawn HOWE 
mailto:dawn.h...@alten.com>> wrote:

I am developing an (embedded) medical device which is required to have a 
touchscreen display and also mirror the output to a monitor connected via HDMI. 
The device is using Wayland/Weston on TorizonCore (based on a yocto kirkstone). 
I am able to get the display extended from HDMI to LVDS, but not have the 
output mirrored to both displays. I posted a query on the Toradex community, 
and received a response that Weston may not be capable of doing this. 
(https://community.toradex.com/t/apalis-imx8-hdmi-and-lvds-display-not-mirroring-cloning/19869).



I have searched and found some old posts from several years ago indicating that 
it was not supported, but may be with a patch. I understand that “same-as” 
configuration in weston.ini does not work for my scenario.



What is the current state of cloning/mirroring to two different outputs, but on 
the same card. E.g (card1-HDMI-A-1 and card1-LVDS-1):


ls /sys/class/drm

card0  card1  card1-HDMI-A-1  card1-LVDS-1  renderD128  renderD129  
version

Weston can currently mirror it if the display driver directly supports it. You 
can use the same-as configuration option (see man weston-drm) to enable this. 
If your display driver doesn't support this in the kernel, then Weston won't do 
it for now, but we are actively working on this and expect to have a branch 
capable of this within the next couple of weeks or so.

Cheers,
Daniel
The information contained in this e-mail and any attachments are intended 
solely for the addressees. If you have received this email in error, please 
contact the sender and delete the email from your system.

Re: Wayland design principles (Re: wayland and gambas)

[Bruce Steers]

On Mon, 29 Apr 2024, 20:32 Thiago Macieira,  wrote:

> On Monday 29 April 2024 10:17:53 GMT-7 Bruce Steers wrote:
> > I thought to redesign my software using a system tray as there was no way
> > to position a window but without system tray working I'm stuck for ideas.
>
> The system tray is not conveyed through Wayland in the first place (it
> goes
> through D-Bus), so any issues you may be facing aren't Wayland. It's
> possible
> the SNI implementation you've got access to is broken and system trays
> work on
> X11 because it falls back to the old XEmbed. It might also be an issue
> with
> your specific desktop of choice.
>
> Either way, the system tray is not a Wayland issue. I recommend treating
> it as
> a regular bug and working with the implementation's and desktop's
> developers
> to fix it.
>

Many thanks Thiago
Apologies for that.
I will see if it can be fixed this end. 😎

Bruce


> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>Principal Engineer - Intel DCAI Cloud Engineering
>
>
>
>

Re: Wayland design principles (Re: wayland and gambas)

[Thiago Macieira]

On Monday 29 April 2024 10:05:32 GMT-7 Bruce Steers wrote:
> I guess/hope a similar thing will happen to x11 or Wayland will accept this
> particular issue needs addressing and provide a workaround.
> 
> As fundamentally Wayland principles are to us, restrictive in a way that I
> think many will simply not tolerate.

Please describe the need you have, not the means by which you think you can 
solve the need. For example, why do you think you need to specify absolute 
positioning for certain windows?

The Wayland philosophy on this has been that the compositor knows best where 
to place the windows for regular applications. That does not include fixed 
desktop components, such as the task bar or desktop wallpapers, but those need 
to communicate directly with the compositor they are a desktop for.

Someone may have said they had a need to grab the keyboard and obtain key 
events even when the window wasn't focused. But why is that? X11 uses 
keyboard-grabbing to implement dismissal of popup menus, something that 
Wayland solved properly instead. Another use-case was to ensure that focus 
couldn't be stolen while typing a password... again, Wayland can solve that by 
the window describing itself as "I'm recording a password" so the compositor 
can implement a higher focus-stealing threshold or other attention-grabbing 
techniques (how many of us have typed passwords in the wrong window?).

Other things are done for security: you can't inject events into other 
windows, so we lose the auto-type feature in KeyPassXC. You can't perform 
arbitrary screengrabs any more, but instead screensharing applications must 
ask the compositor to let the user choose which window(s) to share.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Principal Engineer - Intel DCAI Cloud Engineering

Re: Wayland design principles (Re: wayland and gambas)

[Thiago Macieira]

On Monday 29 April 2024 10:17:53 GMT-7 Bruce Steers wrote:
> I thought to redesign my software using a system tray as there was no way
> to position a window but without system tray working I'm stuck for ideas.

The system tray is not conveyed through Wayland in the first place (it goes 
through D-Bus), so any issues you may be facing aren't Wayland. It's possible 
the SNI implementation you've got access to is broken and system trays work on 
X11 because it falls back to the old XEmbed. It might also be an issue with 
your specific desktop of choice.

Either way, the system tray is not a Wayland issue. I recommend treating it as 
a regular bug and working with the implementation's and desktop's developers 
to fix it.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Principal Engineer - Intel DCAI Cloud Engineering

Re: Wayland design principles (Re: wayland and gambas)

[Bruce Steers]

I believe so.
It uses dbus org.kde.StatusNotifierItem

The source code is here...
https://gitlab.com/gambas/gambas/-/tree/master/comp/src/gb.dbus.trayicon/.src

Note. I am not "the" gambas ide/source developer I am "a" gambas developer
(programmer) I have made some small contributions to the gambas environment
but Benoit is the main man.

I will forward any useful info to Benoit Minisini who is "the" gambas main
developer

Hopefully we can get everything else working.

I thought to redesign my software using a system tray as there was no way
to position a window but without system tray working I'm stuck for ideas.

Respects and thank you

Bruce Steers



On Mon, 29 Apr 2024, 17:42 Thiago Macieira,  wrote:

> On Monday 29 April 2024 05:43:30 GMT-7 Pekka Paalanen wrote:
> > The system tray case I am not familiar
> > with, so I cannot say anything about that.
>
> That sounds like the issue is not using the StatusNotifierItem[1]
> specification.
> The old XEmbed system tray protocol is not expected to work on Wayland. I
> don't know if xembedsniproxy works on Wayland, actually. It's running on
> my
> machine but I don't know if anything is using it.
>
> So turning the question back to Bruce: have your applications been updated
> to
> use the SNI protocol? It's over 10 years old now.
>
> [1] https://www.freedesktop.org/wiki/Specifications/StatusNotifierItem/
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>Principal Engineer - Intel DCAI Cloud Engineering
>
>
>
>

Re: Wayland design principles (Re: wayland and gambas)

[Bruce Steers]

Many thanks for you detailed response Pekka.

Kinda wasn't the answer I was hoping for but the explanation helps a lot
with our understanding.

Seems like a similar situation to when gnome2 became gnome3 and unity and
as popular as It was and adopted by many systems so many people didn't like
it and wanted what they knew that MATE and cinnamon happened and saved the
day. And they are still very popular today.

I guess/hope a similar thing will happen to x11 or Wayland will accept this
particular issue needs addressing and provide a workaround.

As fundamentally Wayland principles are to us, restrictive in a way that I
think many will simply not tolerate.

Respects and thanks again.
Bruce Steers


On Mon, 29 Apr 2024, 13:43 Pekka Paalanen, 
wrote:

> On Sat, 27 Apr 2024 08:28:00 +0100
> Bruce Steers  wrote:
>
> > Hello
> > I am a gambas basic developer and would like to report some wayland
> > problems. (major issues) that we hear of on the gambas mailing list all
> the
> > time.
> >
> > The attitude towards wayland with gambas coders at present is ,, ditch
> > wayland it sucks, use x11.
> >
> > All gambas users are used to having window X and Y properties to get/set
> > window position and with wayland it is not possible.
> >
> > So any custom home made widgets cannot work as expected.
> > My own desktop has 3 running programs from startup that all have their
> own
> > position set and do not work with wayland as they are borderless (no
> > titlebar) or tray icons and wayland is functionally limited/restrictive.
> >
> > Other things not working with gambas in wayland but okay on X
> >
> > SystemTray icons do not work
> > Form.Sticky (show window on all workspaces) does not work.
> > Form.SkipTaskbar , not working.
> >
> > Like I say due to all these problems our current attitude towards wayland
> > that we have to tell everyone is "get rid of wayland because of the
> > limitations, many things it is lacking"
> >
> > Are there no plans to change any of this?
> > Is waylands attitude towards window positioning just forget it, you are
> no
> > longer in control.
> > Because if yes then it will NEVER be the system of choice (or little
> choice
> > as the case may be) for many of us.
> >
> > Could any wayland developers join the gambas mailing list to possibly
> help
> > us work through some of the issues wayland introduces?
> >
> > gambas is pretty popular and by far the best UI IDE available for
> > freedesktop so please help us work out some of the major problems that
> come
> > with wayland and the wayland limited non-functionality.
> >
> > It would be nice to say "wayland is okay"  but that's not what we are
> > saying at all because wayland just causes many problems. So we say "get
> rid
> > of wayland limited and use X11" and have to explain how restricted
> wayland
> > is for gambas.
>
> Hi Bruce,
>
> I'm sorry, but at least I do not expect the situation to change much
> from the Wayland side. This is a question of fundamental design
> principles being incompatible, especially for the window positioning
> with x,y coordinates topic. The system tray case I am not familiar
> with, so I cannot say anything about that.
>
> I will explain these principles here the best I can, because to my
> knowledge, they still have not been properly documented. Perhaps this
> email could serve as a basis for the Wayland community to document
> them. Sorry for the wall of text, but this for everyone rather than
> just a reply to you. Maybe this explains why the Wayland project seems
> so "stubborn".
>
>
> Wayland's fundamental design principles on the desktop have been
> crystallised to "descriptive, not prescriptive". In other words,
> regular desktop applications are expected to describe their windows
> with enough detail, purpose and intent to let a window system server
> (any of the desktop compositor projects) do the right thing and present
> them the way the end user wants them. This is very much the opposite of
> prescriptive design, where the server does what applications tell it to
> without knowing the intentions or limitations. In other words, in
> Wayland, desktop applications say "here is what I have", not "do as I
> say".
>
> This applies to "regular" desktop applications that are expected to
> work on a very wide range of (desktop) systems, regardless of the
> shape, size, resolution, and number of screens a display system might
> have, or even bringing desktop applications into virtual or augmented
> reality where screens might not even exist.
>
> This might not apply to desktop environment components, and it might
> not apply to non-desktop environments: in-vehicle-entertainment,
> digital signage, set-top boxes, or special equipment displays for
> example. Special programs often use special protocol extensions,
> Wayland or other, to do what they cannot do with just the common set of
> public Wayland interfaces. These special extensions may not be widely
> supported, and they may require special privilege

Re: Wayland design principles (Re: wayland and gambas)

[Thiago Macieira]

On Monday 29 April 2024 05:43:30 GMT-7 Pekka Paalanen wrote:
> The system tray case I am not familiar
> with, so I cannot say anything about that.

That sounds like the issue is not using the StatusNotifierItem[1] 
specification. 
The old XEmbed system tray protocol is not expected to work on Wayland. I 
don't know if xembedsniproxy works on Wayland, actually. It's running on my 
machine but I don't know if anything is using it.

So turning the question back to Bruce: have your applications been updated to 
use the SNI protocol? It's over 10 years old now.

[1] https://www.freedesktop.org/wiki/Specifications/StatusNotifierItem/
-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Principal Engineer - Intel DCAI Cloud Engineering

Wayland design principles (Re: wayland and gambas)

[Pekka Paalanen]

On Sat, 27 Apr 2024 08:28:00 +0100
Bruce Steers  wrote:

> Hello
> I am a gambas basic developer and would like to report some wayland
> problems. (major issues) that we hear of on the gambas mailing list all the
> time.
> 
> The attitude towards wayland with gambas coders at present is ,, ditch
> wayland it sucks, use x11.
> 
> All gambas users are used to having window X and Y properties to get/set
> window position and with wayland it is not possible.
> 
> So any custom home made widgets cannot work as expected.
> My own desktop has 3 running programs from startup that all have their own
> position set and do not work with wayland as they are borderless (no
> titlebar) or tray icons and wayland is functionally limited/restrictive.
> 
> Other things not working with gambas in wayland but okay on X
> 
> SystemTray icons do not work
> Form.Sticky (show window on all workspaces) does not work.
> Form.SkipTaskbar , not working.
> 
> Like I say due to all these problems our current attitude towards wayland
> that we have to tell everyone is "get rid of wayland because of the
> limitations, many things it is lacking"
> 
> Are there no plans to change any of this?
> Is waylands attitude towards window positioning just forget it, you are no
> longer in control.
> Because if yes then it will NEVER be the system of choice (or little choice
> as the case may be) for many of us.
> 
> Could any wayland developers join the gambas mailing list to possibly help
> us work through some of the issues wayland introduces?
> 
> gambas is pretty popular and by far the best UI IDE available for
> freedesktop so please help us work out some of the major problems that come
> with wayland and the wayland limited non-functionality.
> 
> It would be nice to say "wayland is okay"  but that's not what we are
> saying at all because wayland just causes many problems. So we say "get rid
> of wayland limited and use X11" and have to explain how restricted wayland
> is for gambas.

Hi Bruce,

I'm sorry, but at least I do not expect the situation to change much
from the Wayland side. This is a question of fundamental design
principles being incompatible, especially for the window positioning
with x,y coordinates topic. The system tray case I am not familiar
with, so I cannot say anything about that.

I will explain these principles here the best I can, because to my
knowledge, they still have not been properly documented. Perhaps this
email could serve as a basis for the Wayland community to document
them. Sorry for the wall of text, but this for everyone rather than
just a reply to you. Maybe this explains why the Wayland project seems
so "stubborn".


Wayland's fundamental design principles on the desktop have been
crystallised to "descriptive, not prescriptive". In other words,
regular desktop applications are expected to describe their windows
with enough detail, purpose and intent to let a window system server
(any of the desktop compositor projects) do the right thing and present
them the way the end user wants them. This is very much the opposite of
prescriptive design, where the server does what applications tell it to
without knowing the intentions or limitations. In other words, in
Wayland, desktop applications say "here is what I have", not "do as I
say".

This applies to "regular" desktop applications that are expected to
work on a very wide range of (desktop) systems, regardless of the
shape, size, resolution, and number of screens a display system might
have, or even bringing desktop applications into virtual or augmented
reality where screens might not even exist.

This might not apply to desktop environment components, and it might
not apply to non-desktop environments: in-vehicle-entertainment,
digital signage, set-top boxes, or special equipment displays for
example. Special programs often use special protocol extensions,
Wayland or other, to do what they cannot do with just the common set of
public Wayland interfaces. These special extensions may not be widely
supported, and they may require special privileges. However, even
though the Wayland principles may not fully apply, they do make system
integration easier when they do apply.

The descriptive design principle has allowed a set of protocol
extensions (xdg) to arise that cater for many kinds of environments
without actually needing environment-specific extensions. An application
developed with these principles can work well on a normal desktop, in a
TV/set-top box, and in a kiosk machine without needing much or any
tailoring. The kiosk environment makes the active application
top-level window always fullscreen or maximized, for instance.

As another example, not defining a global coordinate system like X11
has, has allowed HiDPI display support to be designed in a way that can
accommodate also mixed-DPI multi-display systems. I believe it would
have been much harder if not impossible to do if a global coordinate
system had been defined. For better or worse, this als