Wayland vs X

[Kevin Exton]

I tried Wayland some years ago now (might have been when they first trialled it in Ubuntu) but decided not to stick with it.

Since more desktop environments are beginning to choose Wayland as the default display protocol, I was wondering if others think there's significant user benefits to making the change?

- Kevin

[Georgi Naplatanov]

Hi Kevin,

Wayland has new features, better security model and improved
performance, and these areas of improvements seem considerable to me.

Kind regards
Georgi

[Emanuel Berg]

Georgi Naplatanov wrote:

> Wayland has new features, better security model and improved
> performance, and these areas of improvements seem
> considerable to me.

When I tried it the last time I looked for a xinit or startx
which are the ways I start X (from scripts, e.g.
https://dataswamp.org/~incal/conf/.zprofile )

I then run a bunch of programs in ~/.xinitrc

I asked what the equivalence was and was told there
wasn't any. I was instead pointed to a login manager (I don't
use one and don't want one).

Then instead of all my software [1] I saw some weird GUI,
totally unappealing.

Is there, this day and age, a Wayland equivalent to
xinit/startx, the .xinitrc and .Xresources files and so on?

Or better yet, maybe it can even use them transparently?

If so, and if it is better, I'd be happy to try ... if not,
these guys missed an obvious opportunity that should have been
the way (or one of the available ways) from day 1.

[1] https://dataswamp.org/~incal/conf/.xinitrc

--
underground experts united
https://dataswamp.org/~incal

[Pascal Obry]

Hello,

One drawback at the moment is the color management of Wayland when
using the NVidia proprietary driver (not sure about Wayland on
nouveau). This is just not supported and if you need proper color
management like me using for example darktable then Wayland is not an
option yet.

If I understand correctly there is work on this part, so at some point
Wayland will be the best choice for the already mentioned big
enhancements it brings.

Regards,

--
  Pascal Obry /  Magny Les Hameaux (78)

  The best way to travel is by means of imagination

  http://www.obry.net

  gpg --keyserver keys.gnupg.net --recv-key F949BD3B

[Christian Britz]

Hi Kevin,

I had it running for a while recently with KDE Plasma, because I wanted
to try out waydroid, which only supports Wayland. My impression was,
that it has improved a lot and is in a somewhat usable state, but I
quickly changed back to X.

I felt that programs designed for X and programs designed for Wayland
don't interact well (copy/paste and so on) and Plasma support for
Wayland is not as mature as for X. The worst experience was the
proprietary Citrix client, which I need to use on a daily basis for my
work. They say they don't support Wayland at all. Well it did somehow
work but it was absolutely not satisfying (again copy/paste, alt+tab
behaviour and so on).

I came to the conclusion that I don't really need or want Wayland at
this point of time. It might be technically better, but X does all I
need these days. And I like the X forwarding feature of SSH.

My biggest concern is that we will see over the next years a big
division of the GUI application eco system. Some programs will stay
optimised for X, some will even require Wayland, like the mentioned
waydroid. Hopefully a full transparency can somehow be achieved.

Regards,
Christian

--
http://www.cb-fraggle.de

[Emanuel Berg]

Pascal Obry wrote:

> One drawback at the moment is the color management of
> Wayland when using the NVidia proprietary driver (not sure
> about Wayland on nouveau). This is just not supported and if
> you need proper color management like me using for example
> darktable then Wayland is not an option yet.

Hm, those sound familiar, do you have a command to find out
which one is used?

[Emanuel Berg]

Christian Britz wrote:

> My biggest concern is that we will see over the next years
> a big division of the GUI application eco system.
> Some programs will stay optimised for X, some will even
> require Wayland, like the mentioned waydroid.
> Hopefully a full transparency can somehow be achieved.

That so, I was told the applications would remain the same,
only the protocols were to be changed.

I have tons of X stuff in shell functions, that means that
won't work with Wayland?

[didier gaumet]

Le mercredi 09 mars 2022 à 11:14 +0100, Emanuel Berg a écrit :
>
> When I tried it the last time I looked for a xinit or startx
> which are the ways I start X (from scripts, e.g.
> https://dataswamp.org/~incal/conf/.zprofile )
>
> I then run a bunch of programs in ~/.xinitrc
>
> I asked what the equivalence was and was told there
> wasn't any. I was instead pointed to a login manager (I don't
> use one and don't want one).
>
> Then instead of all my software [1] I saw some weird GUI,
> totally unappealing.
>
> Is there, this day and age, a Wayland equivalent to
> xinit/startx, the .xinitrc and .Xresources files and so on?
>
> Or better yet, maybe it can even use them transparently?
>
> If so, and if it is better, I'd be happy to try ... if not,
> these guys missed an obvious opportunity that should have been
> the way (or one of the available ways) from day 1.
>
> [1] https://dataswamp.org/~incal/conf/.xinitrc
>

Hello,

I use Gnome Classic (with Debian that means Xorg, not Wayland) so I am definitely not familiar (nor knowledgeable) with Wayland.

But am I wrong? I was thinking that one could start a Wayland compositor from a TTY (so, also from a script), with a particular configuration if she/he wishes, and launch GUI programs in this environment?

For example:
https://wiki.archlinux.org/title/Wayland
https://unix.stackexchange.com/questions/497647/start-a-qt-wayland-application-on-top-of-weston-on-startup

[Emanuel Berg]

didier gaumet wrote:

> But am I wrong? I was thinking that one could start
> a Wayland compositor from a TTY (so, also from a script),
> with a particular configuration if she/he wishes, and launch
> GUI programs in this environment?

Okay, that's how I start X (from a tty, tty6 to be precise)

https://dataswamp.org/~incal/conf/.zprofile [line 50]

how do I do the same with Wayland?

Il frappe ... il frappe duuur

[Nicholas Geovanis]

On Wed, Mar 9, 2022 at 4:40 AM Christian Britz <cbr...@t-online.de> wrote:

Hi Kevin,

On 2022-03-08 23:01 UTC+0100, Kevin Exton wrote:
> I tried Wayland some years ago now (might have been when they first
> trialled it in Ubuntu) but decided not to stick with it.
>
> Since more desktop environments are beginning to choose Wayland as the
> default display protocol, I was wondering if others think there's
> significant user benefits to making the change?

I had it running for a while recently with KDE Plasma, because I wanted
to try out waydroid, which only supports Wayland. My impression was,
that it has improved a lot and is in a somewhat usable state, but I
quickly changed back to X.

Here's something about the X ecosystem that I don't understand anymore. I've read the statement

that "X isn't developed anymore, only XFree86". In other words, X source was re-based to Xfree86

a long time ago. So it must be that in the XFree86-based X Windows, only the X server is under active

development, nothing more than that. Is that accurate?

 

I felt that programs designed for X and programs designed for Wayland
don't interact well (copy/paste and so on) and Plasma support for
Wayland is not as mature as for X.

........ 

My biggest concern is that we will see over the next years a big
division of the GUI application eco system. Some programs will stay
optimised for X, some will even require Wayland, like the mentioned
waydroid. Hopefully a full transparency can somehow be achieved.

And isn't that what happened once already? When XFree86 re-based X Windows?

[to...@tuxteam.de]

On Wed, Mar 09, 2022 at 11:15:54AM -0600, Nicholas Geovanis wrote:

[...]

> Here's something about the X ecosystem that I don't understand anymore.
> I've read the statement
> that "X isn't developed anymore, only XFree86". In other words, X source
> was re-based to Xfree86
> a long time ago. So it must be that in the XFree86-based X Windows, only
> the X server is under active
> development, nothing more than that. Is that accurate?

I think the authoritative place is:

https://x.org/wiki/

(you can donate via SPI, if you wish ;-)

Cheers
--
t

[Nicholas Geovanis]

See I can't tell if that supports my claim or yours :-)

Here's why: I went to that site and among others, looked at the page for distribution-specific X mail lists. Out of Redhat, Suse, Oracle OpenSolaris and OpenBSD, not one of those X-specific lists was active. Most not in years.

But Debian's X list is thriving. Does that imply that only Debian carries a torch for truly platform- and server-agnostic X Windows?

I didn't check Canonical/ubuntu.

Cheers
--
t

[to...@tuxteam.de]

On Wed, Mar 09, 2022 at 12:51:24PM -0600, Nicholas Geovanis wrote:

[...]

> See I can't tell if that supports my claim or yours :-)

When in doubt, it supports your claim. I'm not aware of having made
a significant one ;-)

> Here's why: I went to that site and among others, looked at the page for
> distribution-specific X mail lists. Out of Redhat, Suse, Oracle OpenSolaris
> and OpenBSD, not one of those X-specific lists was active. Most not in
> years.
>
> But Debian's X list is thriving. Does that imply that only Debian carries a
> torch for truly platform- and server-agnostic X Windows?
> I didn't check Canonical/ubuntu.

I think Wayland has taken all the hype for a while. But I think the
people involved are smart enough to try to factor out common work

I hope X isn't going anywhere the next 10..15 years. After that, I'll
be gone myself, so... ;-)

Cheers
--
t

[Emanuel Berg]

tomas wrote:

> I hope X isn't going anywhere the next 10..15 years.
> After that, I'll be gone myself, so... ;-)

:( *sob*

[Christian Britz]

On 2022-03-09 18:15 UTC+0100, Nicholas Geovanis wrote:
> Here's something about the X ecosystem that I don't understand anymore.
> I've read the statement
> that "X isn't developed anymore, only XFree86". In other words, X source
> was re-based to Xfree86
> a long time ago. So it must be that in the XFree86-based X Windows, only
> the X server is under active
> development, nothing more than that. Is that accurate?

That statement is wrong, you are confusing some things. XFree86 was the
important free implementation of the X11 stack for many years. XFree86
as a whole software stack was forked by some of it's developers under
the umbrella of X.org, when they became unhappy with the project leader.

X.org has the only relevant X11 implementation today (XFree86 does not
exist anymore), but it's development seems to have slowed down very much
in the last years, probably in favour of Wayland. Recently the project
showed some activity again, as far as I have heard.

My personal opinion: X11 may have some design flaws, but I can live with
them very well, I especially like the network transparency of it, which
Wayland does not offer, AFAIK. I would prefer to see the development
resources invested into X11, instead of Wayland.

[didier gaumet]

Le mercredi 09 mars 2022 à 16:29 +0100, Emanuel Berg a écrit :
> didier gaumet wrote:
>
> > But am I wrong? I was thinking that one could start
> > a Wayland compositor from a TTY (so, also from a script),
> > with a particular configuration if she/he wishes, and launch
> > GUI programs in this environment?
>
> Okay, that's how I start X (from a tty, tty6 to be precise)
>
> https://dataswamp.org/~incal/conf/.zprofile [line 50]
>
> how do I do the same with Wayland?
>
> Il frappe ... il frappe duuur

from what I understand (but I am not familiar with nor have never tried all of this):

- with X, you launch X with startx that is set up via .xinitrc and/or .xsession to suit your goals

- with Wayland, instead, you launch a compositor (a window-manager that implements the Wayland protocol, sort of). You have the choice of the compositor ( https://en.wikipedia.org/wiki/List_of_display_servers#Wayland ).
So how you set up and launch the compositor depends on the compositor chosen , I imagine (cf respective manpages).
And if you want to execute pure X applications that are not Wayland compatible, you must first launch Xwayland ( https://wiki.debian.org/Wayland#Xwayland )

(as always, if what I say is wrong or inaccurate and someone can correct or precise it, please do)

[to...@tuxteam.de]

On Wed, Mar 09, 2022 at 08:42:31PM +0100, Emanuel Berg wrote:
> tomas wrote:
>
> > I hope X isn't going anywhere the next 10..15 years.
> > After that, I'll be gone myself, so... ;-)
>
> :( *sob*

Don't worry. Life is like that :)

Cheers
--
t

[gene heskett]

Or Tomas, you could be like me. He's had several good chances to put a
~30~ on my story, but he knows he'd have to send me down, I'd fix the
stoker, rewind the generator to power it and some AC, and open an air
conditioned bar serving good WV hooch in mason jars. And both are so
afraid of that that they keep sending me back. So at 87, you're stuck
with me till? ;o) Take care my friend.

> Cheers
> --
> t


Cheers, Gene Heskett.
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
- Louis D. Brandeis

[to...@tuxteam.de]

On Wed, Mar 09, 2022 at 03:37:17PM -0500, gene heskett wrote:

[...]

> > Don't worry. Life is like that :)
> >
> Or Tomas, you could be like me. He's had several good chances to put a
> ~30~ on my story, but he knows he'd have to send me down, I'd fix the
> stoker, rewind the generator to power it and some AC, and open an air
> conditioned bar serving good WV hooch in mason jars. And both are so
> afraid of that that they keep sending me back. So at 87, you're stuck
> with me till? ;o) Take care my friend.

Well, you take care, too :)

Cheers
--
t

[Emanuel Berg]

didier gaumet wrote:

> - with X, you launch X with startx that is set up via .xinitrc
> and/or .xsession to suit your goals

Yes, well, there are other files of course, notably
~/.Xresources (loaded with 'xrdb ~/.Xresources', conveniently
from ~/.xinitrc) which hold settings that are/can be general
(cross-application) to some extent, e.g.

https://dataswamp.org/~incal/conf/.Xresources

> - with Wayland, instead, you launch a compositor (a
> window-manager that implements the Wayland protocol, sort of).
> You have the choice of the compositor (
> https://en.wikipedia.org/wiki/List_of_display_servers#Wayland
> ).

Hm, I use a compositor for/in X as well, it is launched in
.xinitrc before the window manager, I've heard it makes
toggling between windows in X faster and what I can tell (not
100) it seems to be the case as well. E.g.

picom &
openbsd-cwm &

in

https://dataswamp.org/~incal/conf/.xinitrc

> So how you set up and launch the compositor depends on the
> compositor chosen , I imagine (cf respective manpages).
> And if you want to execute pure X applications that are not
> Wayland compatible, you must first launch Xwayland (
> https://wiki.debian.org/Wayland#Xwayland )

What are the pure X applications? This is the software I use
almost every day

https://dataswamp.org/~incal/SOFTWARE

The ones that start with an "x" are xterm and xpdf ...

[didier gaumet]

Le jeudi 10 mars 2022 à 16:27 +0100, Emanuel Berg a écrit :
[...]

> What are the pure X applications? This is the software I use
> almost every day
>
> https://dataswamp.org/~incal/SOFTWARE
>
> The ones that start with an "x" are xterm and xpdf ...

If I understand correctly, a GUI application is (or not) compatible with Wayland, depending on the graphical toolkit with which it has been developed.
https://wiki.debian.org/Wayland#Toolkits
So I think that the apps developed with an incompatible toolkit or no toolkit at all are not wayland compatible and need to run on a nested X server (Xwayland) inside Wayland.

[didier gaumet]

[...]

> What are the pure X applications? This is the software I use
> almost every day
>
> https://dataswamp.org/~incal/SOFTWARE

[...]

I just took a look at two of these apps:
- mpv uses libsdl2, so it should be Wayland compatible
- feh uses libx11-6, so it should not be Wayland compatible

[Emanuel Berg]

didier gaumet wrote:

> I just took a look at two of these apps:
> - mpv uses libsdl2, so it should be Wayland compatible
> - feh uses libx11-6, so it should not be Wayland compatible

OK, thanks, I won't switch then I think ... I like feh and use
it a lot.

[didier gaumet]

Le jeudi 10 mars 2022 à 19:00 +0100, Emanuel Berg a écrit :
> didier gaumet wrote:
>
> > I just took a look at two of these apps:
> > - mpv uses libsdl2, so it should be Wayland compatible
> > - feh uses libx11-6, so it should not be Wayland compatible
>
> OK, thanks, I won't switch then I think ... I like feh and use
> it a lot.
>

Just to be clear in case there would be a misunderstanding because my sentence was not accurate enough: what I meant is feh (for example) is not directly compatible with Wayland, but can be run in the X11 compatibility layer of Wayland (Xwayland, the nested X server that can be run inside Wayland)

[Emanuel Berg]

didier gaumet wrote:

>> OK, thanks, I won't switch then I think ... I like feh and
>> use it a lot.
>
> Just to be clear in case there would be a misunderstanding
> because my sentence was not accurate enough: what I meant is
> feh (for example) is not directly compatible with Wayland, but
> can be run in the X11 compatibility layer of Wayland
> (Xwayland, the nested X server that can be run inside
> Wayland)

No, I understood, but that sounds like too much emulator ...

[Nate Bargmann]

* On 2022 10 Mar 17:04 -0600, Emanuel Berg wrote:
> didier gaumet wrote:
>
> >> OK, thanks, I won't switch then I think ... I like feh and
> >> use it a lot.
> >
> > Just to be clear in case there would be a misunderstanding
> > because my sentence was not accurate enough: what I meant is
> > feh (for example) is not directly compatible with Wayland, but
> > can be run in the X11 compatibility layer of Wayland
> > (Xwayland, the nested X server that can be run inside
> > Wayland)
>
> No, I understood, but that sounds like too much emulator ...

My understanding is that xwayland is an X server that runs under
Wayland and the idea is that it handles X protocols but Wayland handles
the video drivers and screen drawing.

I have used Gnome on Wayland since late 2018. It improved a lot with
the release of Bullseye. I use this setup on two machines, a laptop and
a desktop that has two monitors. So far I have not had any issues with
any Debian provided packages. They just work, including feh which I call
from neomutt to display images. No fuss, no configuration, it just
works. I've even built and locally installed GTK2 apps without issue.

I did have a display issue with a proprietary third party program that
was built with some older version of Qt, as I recall. That has been
replaced by a version that is FOSS and it works fine. On the desktop
with dual monitors I have xscreensaver running and it has the most
issues with detecting events as when I do strictly keyboard work it will
time out and start running a saver. Moving the mouse wakes it up. It
also glitches at other times even when using the mouse, but this is not
a show stopper for me. It also doesn't handle DPMS on Wayland either
which I can live with (I'm sure the built in Gnome blanker works just
fine).

My GPUs are stock Intel on board graphics as I don't game nor do I need
fancy 3D capability. This hardware is sufficient for displaying the GL
screen savers and for whatever compositing requirements Gnome has.

HTH

- Nate

--
"The optimist proclaims that we live in the best of all
possible worlds. The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819

[Christian Britz]

On 2022-03-11 12:47 UTC+0100, Nate Bargmann wrote:

> I have used Gnome on Wayland since late 2018. It improved a lot with
> the release of Bullseye. I use this setup on two machines, a laptop and
> a desktop that has two monitors. So far I have not had any issues with

And what is the practical _advantage_ over a X11 setup?

The question is serious. Everytime I tried Wayland, something was not
working as expected, uncomfortable to use and so on. Yes, Wayland
support has improved a lot, but I still do not really see what I miss
because I stick to X11. I know that Wayland has a cleaner design, but
that bothers me not too much as a user.

[Nate Bargmann]

* On 2022 11 Mar 07:16 -0600, Christian Britz wrote:
>
>
> On 2022-03-11 12:47 UTC+0100, Nate Bargmann wrote:
>
> > I have used Gnome on Wayland since late 2018. It improved a lot with
> > the release of Bullseye. I use this setup on two machines, a laptop and
> > a desktop that has two monitors. So far I have not had any issues with
>
> And what is the practical _advantage_ over a X11 setup?

Gnome is now native with Wayland and its visual effects only work with
Wayland as I understand it. I did try Gnome Flashback as it runs on X11
and the visual effects were disabled. In some cases that's not an
issue and is likely appropriate for some hardware.

> The question is serious. Everytime I tried Wayland, something was not
> working as expected, uncomfortable to use and so on. Yes, Wayland
> support has improved a lot, but I still do not really see what I miss
> because I stick to X11. I know that Wayland has a cleaner design, but
> that bothers me not too much as a user.

Interesting as no one uses Wayland or X11 directly but through a window
manager or quite likely one of the desktop environments. Debian
packaging seems to sort this out where a DE like Xfce only installs Xorg
packages and Gnome installs Wayland and Xwayland.

That said, if hardware support is not present, then I suspect that any
advanced features will have problems. Use what works for you. I am
just providing my experience as I'm not a cheerleader for Wayland or
against Xorg, just a satisfied user of both.

[didier gaumet]

Le vendredi 11 mars 2022 à 08:07 -0600, Nate Bargmann a écrit :
>
> Gnome is now native with Wayland and its visual effects only work
> with
> Wayland as I understand it.  I did try Gnome Flashback as it runs on
> X11
> and the visual effects were disabled.  In some cases that's not an
> issue and is likely appropriate for some hardware.

[...]

If I am not wrong:
- Gnome (aka Gnome shell) can run in X or Wayland (Debian defaults to
Wayland), its window manager is Mutter and it needs an hardware
accelerated graphic card
- Gnome Classic is a pre-configured Gnome2-like DE based on Gnome
shell, it cans also run in X or Wayland (but Debian still defaults to X
in Bullseye), its window manager is Mutter and it needs an hardware
accelerated graphic card
- Gnome Flashback is an evolution of the old Gnome Fallback, it can run
in X but not in Wayland as its window manager is Metacity (like
Gnome2). It's a Gnome2-like DE that does not require an hardware
accelerated graphic card

So Gnome Classic would probably suits you better than Gnome Flashback

[Marco Möller]

Isn't it all about X by design to not be able to safely protect a
running X applications to snoop on other running X applications,
something like the content of a window cannot safely kept private? I
remember to have read that Wayland was invented for this reason, to
overcome these security flaws of X which in the beginning of X have not
been a concern to anyone, but nowadays security issues are of much
importance to almost everyone.
(I have no reference for this statement, just remember to have something
like this read in the past)
And isn't it because of Wayland protecting windows by design against
other windows, that operations like Copy&Paste between GUI applications
are (still) not always running smoothly and need extra efforts to become
well implemented?
(Again, I have no reference for this statement, just remember to have
something like this read in the past)

Regards,
Marco

[Tim Woodall]

On Fri, 11 Mar 2022, Marco M?ller wrote:

> Isn't it all about X by design to not be able to safely protect a running X
> applications to snoop on other running X applications, something like the
> content of a window cannot safely kept private? I remember to have read that
> Wayland was invented for this reason, to overcome these security flaws of X
> which in the beginning of X have not been a concern to anyone, but nowadays
> security issues are of much importance to almost everyone.
> (I have no reference for this statement, just remember to have something like
> this read in the past)

This is definitely true. Not sure if xev lets you pass in a window on
the commandline but if not it's trivial to hack it to snoop on say
keystrokes to any window. My ipmi-on-rpi uses exactly this trick to hook
keystrokes typed to the video player without having to patch the code.

[Emanuel Berg]

Nate Bargmann wrote:

> Interesting as no one uses Wayland or X11 directly but
> through a window manager or quite likely one of the desktop
> environments.

I don't know, I think it is fair to say I use X "directly",
I start it manually (but automatically, the command is in
a file) in a tty and then in ~/xinitrc launch a compositor and
WM, then xterm with tmux:

picom &
openbsd-cwm &

xterm \
-T 'xterm' \
-fullscreen \
-e 'tmux new-session\; split-window -v\; select-pane -U'

[Emanuel Berg]

Nate Bargmann wrote:

>> No, I understood, but that sounds like too much emulator ...
>
> My understanding is that xwayland is an X server that runs
> under Wayland and the idea is that it handles X protocols
> but Wayland handles the video drivers and screen drawing.
>
> I have used Gnome on Wayland since late 2018. It improved
> a lot with the release of Bullseye.

Okay, I'm on Bullseye as well.

You have commands so I can try?

[The Wanderer]

On 2022-03-11 at 06:47, Nate Bargmann wrote:

> * On 2022 10 Mar 17:04 -0600, Emanuel Berg wrote:
>
>> didier gaumet wrote:
>>
>>>> OK, thanks, I won't switch then I think ... I like feh and use
>>>> it a lot.
>>>
>>> Just to be clear in case there would be a misunderstanding
>>> because my sentence was not accurate enough: what I meant is feh
>>> (for example) is not directly compatible with Wayland, but can be
>>> run in the X11 compatibility layer of Wayland (Xwayland, the
>>> nested X server that can be run inside Wayland)
>>
>> No, I understood, but that sounds like too much emulator ...
>
> My understanding is that xwayland is an X server that runs under
> Wayland and the idea is that it handles X protocols but Wayland
> handles the video drivers and screen drawing.

That's a rough match for my own understanding, with the added
qualification that apparently there are some features of the X protocol
which Wayland doesn't support, and which XWayland therefore may well
also not (be able to) support. (Although, while writing this mail, I've
seen assertions that the XWayland codebase *is* the X.org codebase, just
with the hardware-related parts stripped out and replaced with calls to
Wayland - in which case maybe those features would be working after all.)


The most important one for my purposes, and therefore the one that I
remember, is the ability to have multiple desktop-like things which are
actually all just viewports on one much-larger single area. The big
advantage of this is that it lets you have a window that's larger than
any one single desktop, and switch around between desktops to look at
different parts of that window. One of my brothers and I have both made
productive use of this feature (for values of "productive" that relate
to games and entertainment, anyway), and would not be happy to lose
access to it.

(Possible FUD alert; I don't have any citations for the next paragraph,
although I trust the person from whom I learned of it.)

I remember having been informed that people had brought this up with the
Wayland developers, and that the upshot of the ensuing conversation was
that those developers considered this feature to be an odd historical
wart on the X specification, clearly of no value, and not worth
supporting or implementing - and because they considered it so, Wayland
had been designed in a way that made it difficult or impossible to
implement that feature, even with people now requesting it.


Another limitation of XWayland as I've heard it described (by the same
person on whose statements the previous paragraph is based, as well as
in online discussions related to XWeston, below), as compared to a full
X server: where you can (and, in fact, usually need to) run a window
manager on top of an X server, I'm given to understand that you cannot
run a window manager on top of XWayland. Instead, the window manager
needs to be implemented as a Wayland compositor, and you then run
XWayland inside of that. (I have not actually tried to do this myself,
for reasons which I'm about to get into, so I may have some of the
details wrong.)

That's a showstopper from my perspective, since the window manager I use
A: is in long-tail maintenance mode, with very little work done over the
past decade (relatively speaking), and will certainly not be rewritten
as a Wayland compositor, and B: includes features which are built on top
of that multiple-desktops windows-larger-than-the-desktop X feature, and
which therefore probably cannot be implemented on top of Wayland.

For reference in case anyone is interested, that window manager is
Enlightenment DR16, also known as e16. It hasn't been in Debian for
quite several releases now, I compile it from the upstream source tree.

The solution to this is apparently XWeston[1], but I remember that being
reported as having performance problems (though I'm not finding those
reports again now) and I don't know how well supported it is even by its
developer; it doesn't seem to have been touched since its initial
development work in 2015.

I keep meaning to try out running e16 inside of XWeston, but to date
have not acquired a sufficiently circular tuit.

[1] https://github.com/ackalker/Xweston
https://bbs.archlinux.org/viewtopic.php?id=185297

https://www.reddit.com/r/linux/comments/2dna8v/xweston_xwayland_with_weston_the_other_way_round/

https://www.linuxquestions.org/questions/slackware-14/how-can-i-install-wayland-on-slackware-4175694086/page2.html

--
The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw

[Nicholas Geovanis]

On Fri, Mar 11, 2022, 12:25 PM Marco Möller <ta...@debianlists.mobilxpress.net> wrote:

On 11.03.22 14:14, Christian Britz wrote:
>
>
> On 2022-03-11 12:47 UTC+0100, Nate Bargmann wrote:
>
>> I have used Gnome on Wayland since late 2018.  It improved a lot with
>> the release of Bullseye.  I use this setup on two machines, a laptop and
>> a desktop that has two monitors.  So far I have not had any issues with
>
> And what is the practical _advantage_ over a X11 setup?
>
> The question is serious. Everytime I tried Wayland, something was not
> working as expected, uncomfortable to use and so on. Yes, Wayland
> support has improved a lot, but I still do not really see what I miss
> because I stick to X11. I know that Wayland has a cleaner design, but
> that bothers me not too much as a user.
>
> Regards,
> Christian
>

Isn't it all about X by design to not be able to safely protect a
running X applications to snoop on other running X applications,
something like the content of a window cannot safely kept private? I
remember to have read that Wayland was invented for this reason, to
overcome these security flaws of X which in the beginning of X have not
been a concern to anyone, but nowadays security issues are of much
importance to almost everyone.
(I have no reference for this statement, just remember to have something
like this read in the past)

That was exactly what I asked here a few days ago. And I was told that I was incorrect, that Wayland was simply a better implementation of X. That the old implementation X.org was still under active development. Showing that I was mistaken.

But if you read stuff online on this subject, you read exactly what I wrote: that the X protocol is old and outdated, the X source is largely unused at runtime, no real mindshare for X.org among X developers. 

Here's an example of these views from 2021, at linuxiac.org:

"Most of the features that the X Server protocol provided were not used anymore. Pretty much all of the work that X11 did was redelegated to the individual applications and the window manager. And yet all of those old features are still there, weighing down on all of these applications, hurting performance and security".

https://linuxiac.com/xorg-x11-wayland-linux-display-servers-and-protocols-explained/

I'm just trying to find out what the real story is.

[Emanuel Berg]

The Wanderer wrote:

> Another limitation of XWayland as I've heard it described
> (by the same person on whose statements the previous
> paragraph is based, as well as in online discussions related
> to XWeston, below), as compared to a full X server: where
> you can (and, in fact, usually need to) run a window manager
> on top of an X server, I'm given to understand that you
> cannot run a window manager on top of XWayland. Instead, the
> window manager needs to be implemented as a Wayland
> compositor, and you then run XWayland inside of that. (I
> have not actually tried to do this myself, for reasons which
> I'm about to get into, so I may have some of the
> details wrong.)

OK, that stinks, I'm super-happy with my WM and it's
configured and all. See? How do they expect anyone to switch
to a supposedly superior solution when there are all these
obstacles and limitations? If it is just about replacing one
protocol by another why can't that be done for WMs as well?
And there are TONS of different WMs!

[Emanuel Berg]

Greg Wooledge wrote:

>> OK, that stinks, I'm super-happy with my WM and it's
>> configured and all. See? How do they expect anyone to
>> switch to a supposedly superior solution when there are all
>> these obstacles and limitations?
>

> I don't think anyone is switching. What I think is happening
> is that old users (like us) are staying with what we know,
> and some new users are using Wayland/GNOME because it's the
> default that Debian selected for them. Some of the new users
> who grow up on Wayland may eventually move on to other
> desktop environments, or other windowing systems, and will
> become the next generation of old cranky gurus.

I switched from mplayer to mpv ...

[Greg Wooledge]

On Fri, Mar 11, 2022 at 10:07:39PM +0100, Emanuel Berg wrote:
> OK, that stinks, I'm super-happy with my WM and it's
> configured and all. See? How do they expect anyone to switch
> to a supposedly superior solution when there are all these
> obstacles and limitations?

[Greg Wooledge]

On Fri, Mar 11, 2022 at 10:27:18PM +0100, Emanuel Berg wrote:
> I switched from mplayer to mpv ...

And I switched from Latin-1 to UTF-8.

But until I see fvwm (or something close enough) ported to Wayland,
I have *no* incentive to give up X.

[The Wanderer]

There may be multiple reasons, but one of them is that the feature set
supported by Wayland (and/or the associated protocol, if any) is not a
superset of the feature set supported by the X protocol.

That said, you may still find value in XWeston, and I'd be interested to
hear reports from anyone who tries it - the more obscure and niche the
window manager they try it with, the better.

[Emanuel Berg]

The Wanderer wrote:

> There may be multiple reasons, but one of them is that the
> feature set supported by Wayland (and/or the associated
> protocol, if any) is not a superset of the feature set
> supported by the X protocol.

They should have covered everything used anyway ... this must
be a blunder on their part.

[The Wanderer]

On 2022-03-11 at 16:52, Emanuel Berg wrote:

> The Wanderer wrote:
>
>> There may be multiple reasons, but one of them is that the feature
>> set supported by Wayland (and/or the associated protocol, if any)
>> is not a superset of the feature set supported by the X protocol.
>
> They should have covered everything used anyway ... this must be a
> blunder on their part.

My understanding (which is at best secondhand, and may well not be fully
accurate, if accurate at all) is that they thought they *were* doing
that, since obviously that one feature is a historical curiosity which
can't possibly be useful to anybody, and is only present in the spec
because the people who wrote the spec mistakenly thought it might turn
out to be useful.

Only to discover later that people actually *did* use that feature, but
by that point it was too late to implement that feature in Wayland
without breaking a lot of other things and/or requiring a deeper
redesign than would be deemed practical.

[John Conover]

Words of wisdom, Greg.

I'm 79 and still use FVWM(1), c. '90s. Concerned about things like
memory footprint, speed, configuration capability, reliability,
24/7/365 stability, intuitive operation, etc.

My ~/.emacs is set up like the 'e' editor from PL1, c. '60s with line
block moves and indent, 8^).

John

--

John Conover, con...@panix.com, http://www.johncon.com/

[Nate Bargmann]

* On 2022 11 Mar 14:10 -0600, Emanuel Berg wrote:
> Nate Bargmann wrote:
>
> >> No, I understood, but that sounds like too much emulator ...
> >
> > My understanding is that xwayland is an X server that runs
> > under Wayland and the idea is that it handles X protocols
> > but Wayland handles the video drivers and screen drawing.
> >
> > I have used Gnome on Wayland since late 2018. It improved
> > a lot with the release of Bullseye.
>
> Okay, I'm on Bullseye as well.
>
> You have commands so I can try?

I had just installed the system with the preselected Gnome desktop task
and everything was put in place. I simply log into the Gnome desktop
from GDM.

[Nate Bargmann]

* On 2022 11 Mar 14:06 -0600, Emanuel Berg wrote:
> Nate Bargmann wrote:
>
> > Interesting as no one uses Wayland or X11 directly but
> > through a window manager or quite likely one of the desktop
> > environments.
>
> I don't know, I think it is fair to say I use X "directly",
> I start it manually (but automatically, the command is in
> a file) in a tty and then in ~/xinitrc launch a compositor and
> WM, then xterm with tmux:
>
> picom &
> openbsd-cwm &
>
> xterm \
> -T 'xterm' \
> -fullscreen \
> -e 'tmux new-session\; split-window -v\; select-pane -U'

I suspect you're not the target audience for Wayland as it seems to me
to be oriented toward the main desktop projects. I don't see that your
use case would gain anything moving to Gnome or KDE.

That's the great thing about Free systems, we don't all have to do
things the same way.

[Emanuel Berg]

The Wanderer wrote:

>>> There may be multiple reasons, but one of them is that the
>>> feature set supported by Wayland (and/or the associated
>>> protocol, if any) is not a superset of the feature set
>>> supported by the X protocol.
>>
>> They should have covered everything used anyway ... this
>> must be a blunder on their part.
>
> My understanding (which is at best secondhand, and may well
> not be fully accurate, if accurate at all) is that they
> thought they *were* doing that, since obviously that one
> feature is a historical curiosity which can't possibly be
> useful to anybody, and is only present in the spec because
> the people who wrote the spec mistakenly thought it might
> turn out to be useful.
>
> Only to discover later that people actually *did* use that
> feature, but by that point it was too late to implement that
> feature in Wayland without breaking a lot of other things
> and/or requiring a deeper redesign than would be
> deemed practical.

Sounds like poor design/modularity to begin with ...

[Nate Bargmann]

* On 2022 11 Mar 15:10 -0600, Nicholas Geovanis wrote:
> That was exactly what I asked here a few days ago. And I was told that I
> was incorrect, that Wayland was simply a better implementation of X. That
> the old implementation X.org was still under active development. Showing
> that I was mistaken.
>
> But if you read stuff online on this subject, you read exactly what I
> wrote: that the X protocol is old and outdated, the X source is largely
> unused at runtime, no real mindshare for X.org among X developers.
>
> Here's an example of these views from 2021, at linuxiac.org:
> "Most of the features that the X Server protocol provided were not used
> anymore. Pretty much all of the work that X11 did was redelegated to the
> individual applications and the window manager. And yet all of those old
> features are still there, weighing down on all of these applications,
> hurting performance and security".
> https://linuxiac.com/xorg-x11-wayland-linux-display-servers-and-protocols-explained/
>
> I'm just trying to find out what the real story is.

Keith Packard, a long time X developer, gave a talk at Linux Conf.au[1]
in early 2020 about X history and politics[2]. As I recall (it's been
two years since I watched it), much of what you wrote above echos
Keith's comments.

- Nate

[1] https://www.keithp.com/blogs/tags/lca/
[2] https://youtu.be/cj02_UeUnGQ

[Emanuel Berg]

Nate Bargmann wrote:

>> picom &
>> openbsd-cwm &
>>
>> xterm \
>> -T 'xterm' \
>> -fullscreen \
>> -e 'tmux new-session\; split-window -v\; select-pane -U'
>
> I suspect you're not the target audience for Wayland as it
> seems to me to be oriented toward the main desktop projects.
> I don't see that your use case would gain anything moving to
> Gnome or KDE.

Sweet heavens, you are expected to do that with Wayland?!

[to...@tuxteam.de]

On Fri, Mar 11, 2022 at 03:41:09PM -0500, The Wanderer wrote:

[...]

> The most important one for my purposes, and therefore the one that I
> remember, is the ability to have multiple desktop-like things which are

> actually all just viewports on one much-larger single area [...]

There seems to be some basis to it. And some solution. But then, you're
perhaps bound to a specific toolkit [1] [2] or perhaps compositor.

> Another limitation of XWayland as I've heard it described (by the same
> person on whose statements the previous paragraph is based, as well as
> in online discussions related to XWeston, below), as compared to a full
> X server: where you can (and, in fact, usually need to) run a window

> manager on top of an X server [...]

This is absolutely my main beef: I do chose my window manager
judiciously; after long use I know it well and perceive it as my
ally in front of applications which sometimes have (to me) strange
ideas of GUI [0].

With X, the window manager is the one implementing window decorations
(this isn't in the protocol, but it is a strong convention applications
had to follow in practice).

With Wayland, you can see the appetite of applications and toolkits
to unleash their "creativity" on the unsuspecting user.

I don't look forward to the day where the browser gives some random
javascript advertisment control over its absolute position on my
screen or over its window decorations. But this day is coming: don't
forget that our main browser provider is an ad company, and this
industry (as the closely related DRM industry, too) tends to view
your computer as /their/ "content" delivery device.

You can get a feel of that taste now with all those "GUIs" badly
implemented by the never-ending horde of javascript frameworks.
Jamie Zawinski's CADT [2] was hell, we now discovered an even
worse place.

I'll stick to X. My computer feels a bit more... mine this way.

Cheers

[0] Heck, I've even a key shortcut for xkill, afer some incarnation
of... yes, Firefox, decided to ignore the window close button.
They've fixed it in the meantime, it seems, but I do keep that
shortcut around.

[1] https://www.phoronix.com/forums/forum/linux-graphics-x-org-drivers/wayland-display-server/1074550-kde-now-has-virtual-desktop-support-on-wayland
and the links therein.

[2] https://www.jwz.org/doc/cadt.html

--
tomás

[to...@tuxteam.de]

On Fri, Mar 11, 2022 at 03:09:08PM -0600, Nicholas Geovanis wrote:

[...]

> > Isn't it all about X by design to not be able to safely protect a
> > running X applications to snoop on other running X applications,
> > something like the content of a window cannot safely kept private? I
> > remember to have read that Wayland was invented for this reason, to
> > overcome these security flaws of X which in the beginning of X have not
> > been a concern to anyone, but nowadays security issues are of much
> > importance to almost everyone.
> > (I have no reference for this statement, just remember to have something
> > like this read in the past)
> >
>
> That was exactly what I asked here a few days ago. And I was told that I
> was incorrect, that Wayland was simply a better implementation of X. That
> the old implementation X.org was still under active development. Showing
> that I was mistaken.

They only removed the stuff me and you don't need. Promised ;-)

Cheers
--
t

[The Wanderer]

On 2022-03-12 at 01:29, to...@tuxteam.de wrote:

> On Fri, Mar 11, 2022 at 03:41:09PM -0500, The Wanderer wrote:
>
> [...]
>
>> The most important one for my purposes, and therefore the one that
>> I remember, is the ability to have multiple desktop-like things
>> which are actually all just viewports on one much-larger single
>> area [...]
>
> There seems to be some basis to it. And some solution. But then,
> you're perhaps bound to a specific toolkit [1] [2] or perhaps
> compositor.

> [1] https://www.phoronix.com/forums/forum/linux-graphics-x-org-drivers/wayland-display-server/1074550-kde-now-has-virtual-desktop-support-on-wayland
> and the links therein.

It's more complicated than that, unfortunately.

There's a reason I didn't use the phrase "virtual desktops" in my
description of this feature; the X spec defines *two* things which are
sometimes called by that name.

One of them has a single large "desktop" with multiple viewports into
it; on that one the parts of one window that stick off the edge of one
viewport overflow into, and can be seen through, an adjacent viewport.
That's the feature I was talking about, but it is *not* the feature most
commonly called "virtual desktops", although some WMs (including, IIRC,
e16) do call it that; I don't know if it has any other dedicated name,
although the X spec does refer to it in different terminology. My
understanding is that this is the thing the Wayland developers saw as so
odd that it couldn't possibly be used/wanted by anyone and had to just
be a historical-curiosity wart on the spec.

The other defines multiple separate "desktops", which are logically
arranged into a grid for purposes of indexing and access, but which are
individually independent; anything sticking off the edge of any one of
them is not visible anywhere. That, as I understand matters, is the
feature commonly called "virtual desktops". It's my understanding that
this feature *is* possible via, and maybe even directly supported by,
Wayland.

It's difficult or impossible to tell for certain from the limited
discussion in the links provided, but it looks to me (having dug through
as far as the Phabricator discussion) as if what KDE added support for
is the latter.

(FWIW, e16 apparently supports *both* of these features, although the
major rewrite that was e17 and later dropped support for the first one;
that's one of the reasons I haven't moved forward to newer versions of
Enlightenment.)

[to...@tuxteam.de]

On Sat, Mar 12, 2022 at 07:22:11AM -0500, The Wanderer wrote:
> On 2022-03-12 at 01:29, to...@tuxteam.de wrote:
>
> > On Fri, Mar 11, 2022 at 03:41:09PM -0500, The Wanderer wrote:
> >
> > [...]
> >
> >> The most important one for my purposes, and therefore the one that
> >> I remember, is the ability to have multiple desktop-like things
> >> which are actually all just viewports on one much-larger single
> >> area [...]
> >
> > There seems to be some basis to it. And some solution. But then,
> > you're perhaps bound to a specific toolkit [1] [2] or perhaps
> > compositor.
>
> > [1] https://www.phoronix.com/forums/forum/linux-graphics-x-org-drivers/wayland-display-server/1074550-kde-now-has-virtual-desktop-support-on-wayland
> > and the links therein.
>
> It's more complicated than that, unfortunately.
>
> There's a reason I didn't use the phrase "virtual desktops" in my
> description of this feature; the X spec defines *two* things which are
> sometimes called by that name.
>
> One of them has a single large "desktop" with multiple viewports into
> it; on that one the parts of one window that stick off the edge of one
> viewport overflow into, and can be seen through, an adjacent viewport.

Ah, I see. I dimly remember that one (I'm that old ;-)

> That's the feature I was talking about, but it is *not* the feature most
> commonly called "virtual desktops", although some WMs (including, IIRC,
> e16) do call it that; I don't know if it has any other dedicated name,
> although the X spec does refer to it in different terminology. My
> understanding is that this is the thing the Wayland developers saw as so
> odd that it couldn't possibly be used/wanted by anyone and had to just
> be a historical-curiosity wart on the spec.
>
> The other defines multiple separate "desktops", which are logically
> arranged into a grid for purposes of indexing and access, but which are
> individually independent; anything sticking off the edge of any one of
> them is not visible anywhere. That, as I understand matters, is the
> feature commonly called "virtual desktops". It's my understanding that
> this feature *is* possible via, and maybe even directly supported by,
> Wayland.

And then, there are window managers (Fvwm) which offer "big" desktops
(where the visible screen is a window into, which can be moved around
seamlessly) and then several of that "virtual desktops".

Best of two worlds :-)

Whether it uses that X functionality is an implementation detail I
don't know, alas.

> It's difficult or impossible to tell for certain from the limited
> discussion in the links provided, but it looks to me (having dug through
> as far as the Phabricator discussion) as if what KDE added support for
> is the latter.
>
> (FWIW, e16 apparently supports *both* of these features, although the
> major rewrite that was e17 and later dropped support for the first one;
> that's one of the reasons I haven't moved forward to newer versions of
> Enlightenment.)

I have the hunch Fvwm is for you. I'm using it with one virtual desktop
which is 3x3 the size of my screen ("pages" in Fvwm parlance). Of course
it's segmented as nine pages, but windows sticking out of my current
page end up sticking into the corresponding neighbour. And I can get
my screen (aka viewport) to straddle page boundaries (which I don't do
usually, but hey).

Cheers
--
t

[Nate Bargmann]

* On 2022 12 Mar 06:38 -0600, to...@tuxteam.de wrote:
> On Sat, Mar 12, 2022 at 07:22:11AM -0500, The Wanderer wrote:
> >
> > The other defines multiple separate "desktops", which are logically
> > arranged into a grid for purposes of indexing and access, but which are
> > individually independent; anything sticking off the edge of any one of
> > them is not visible anywhere. That, as I understand matters, is the
> > feature commonly called "virtual desktops". It's my understanding that
> > this feature *is* possible via, and maybe even directly supported by,
> > Wayland.
>
> And then, there are window managers (Fvwm) which offer "big" desktops
> (where the visible screen is a window into, which can be moved around
> seamlessly) and then several of that "virtual desktops".

That is what I recall from a bit over 25 years ago when I bought a 1.2
GB hard drive to have enough space to install the X disk sets in
Slackware 96. The default WM was Fvwm95 and I used it with a large
virtual desktop for several years. Then I chose to try Afterstep, then
IceWM for some time before moving into the desktop world alternating
between KDE and Xfce and now Gnome for the most part and my virtual
desktop equals the screen size.

Gnome calls them "workspaces" and I typically use four per screen. It's
default is to create them dynamically but I use a fixed number. This
way I set up my work flow the same as on systems where I used Xfce which
defaults to four desktops.

- Nate

[to...@tuxteam.de]

On Sat, Mar 12, 2022 at 07:50:33AM -0600, Nate Bargmann wrote:
> * On 2022 12 Mar 06:38 -0600, to...@tuxteam.de wrote:
> > On Sat, Mar 12, 2022 at 07:22:11AM -0500, The Wanderer wrote:
> > >
> > > The other defines multiple separate "desktops", which are logically
> > > arranged into a grid for purposes of indexing and access, but which are
> > > individually independent; anything sticking off the edge of any one of
> > > them is not visible anywhere. That, as I understand matters, is the
> > > feature commonly called "virtual desktops". It's my understanding that
> > > this feature *is* possible via, and maybe even directly supported by,
> > > Wayland.
> >
> > And then, there are window managers (Fvwm) which offer "big" desktops
> > (where the visible screen is a window into, which can be moved around
> > seamlessly) and then several of that "virtual desktops".
>
> That is what I recall from a bit over 25 years ago when I bought a 1.2
> GB hard drive to have enough space to install the X disk sets in

> Slackware 96 [...]

Ah, memories. I'm older: my first one was Twm ;-P

After an excursion which took me all the way to Gnome (I liked those
around 2-ish, actually), then to Xfce I'm back with Fvwm. Phew.

Fvwm95 I never understood: it wants to look & feel like Windows95. I
hated Windows since 3.1 :-)

> Gnome calls them "workspaces" and I typically use four per screen.

To come back on topic: can Gnome (is their WM still called Metacity?)
straddle workspaces with the viewport?

Otherwise we'll stick with our more advanced WMs ;-)

Cheers
--
t

[Greg Wooledge]

On Sat, Mar 12, 2022 at 07:29:19AM +0100, to...@tuxteam.de wrote:
> With X, the window manager is the one implementing window decorations
> (this isn't in the protocol, but it is a strong convention applications
> had to follow in practice).

Except for when Google Chrome decided to implement its own window
decorations, which were of course completely foreign compared to
the rest of the toplevel windows on my display.

Fortunately, they decided to revert that decision, and today you can
configure Google Chrome to look and act like a normal window.

> I don't look forward to the day where the browser gives some random
> javascript advertisment control over its absolute position on my

> screen [...]

Are you kidding? Javascript could do this *ages* ago.

I wrote a series of little pages that showed how insidiously evil
Javascript actually is (or was):

https://wooledge.org/~greg/jsabuse/

Some of them still work. Some do not, as current browser versions have
tightened up their settings and no longer give Javascript quite as much
freedom as they originally did.

> or over its window decorations.

I wouldn't know anything about that in particular.

[to...@tuxteam.de]

On Sat, Mar 12, 2022 at 03:05:03PM -0500, Greg Wooledge wrote:
> On Sat, Mar 12, 2022 at 07:29:19AM +0100, to...@tuxteam.de wrote:
> > With X, the window manager is the one implementing window decorations
> > (this isn't in the protocol, but it is a strong convention applications
> > had to follow in practice).
>
> Except for when Google Chrome decided to implement its own window
> decorations, which were of course completely foreign compared to
> the rest of the toplevel windows on my display.

I haven't ever tried Chrome or Chromium (and I'll try to avoid them
for as long as I can): you reinforce me on that :)

> Fortunately, they decided to revert that decision, and today you can
> configure Google Chrome to look and act like a normal window.

Phew!

> > I don't look forward to the day where the browser gives some random
> > javascript advertisment control over its absolute position on my
> > screen [...]
>
> Are you kidding? Javascript could do this *ages* ago.

In the classical setting it can only beg the window manager (through
ICCCM). The latter has the last word on it.

> I wrote a series of little pages that showed how insidiously evil
> Javascript actually is (or was):
>
> https://wooledge.org/~greg/jsabuse/

Nice :-)

(FWIW: I can click at 3.html and 4.html: I guess Mozilla begs
the WM to move/resize, but the WM says "nope".

> Some of them still work. Some do not, as current browser versions have
> tightened up their settings and no longer give Javascript quite as much
> freedom as they originally did.

I sure hope. But I'm sceptical: the browser maker's perspective
is the ad industry's perspective (I'm not assuming some evil
conspiracy, just plain boring cultural immersion).

> > or over its window decorations.
>
> I wouldn't know anything about that in particular.

I don't even want to ;-)

Cheers & thanks for the little javascript snippets. You definitely
picked your background colours with fury :-D

--
tomás

[The Wanderer]

On 2022-03-12 at 07:38, to...@tuxteam.de wrote:

> On Sat, Mar 12, 2022 at 07:22:11AM -0500, The Wanderer wrote:
>
>> On 2022-03-12 at 01:29, to...@tuxteam.de wrote:

>>> There seems to be some basis to it. And some solution. But then,
>>> you're perhaps bound to a specific toolkit [1] [2] or perhaps
>>> compositor.
>>
>>> [1] https://www.phoronix.com/forums/forum/linux-graphics-x-org-drivers/wayland-display-server/1074550-kde-now-has-virtual-desktop-support-on-wayland
>>> and the links therein.
>>
>> It's more complicated than that, unfortunately.
>>
>> There's a reason I didn't use the phrase "virtual desktops" in my
>> description of this feature; the X spec defines *two* things which
>> are sometimes called by that name.
>>
>> One of them has a single large "desktop" with multiple viewports
>> into it; on that one the parts of one window that stick off the
>> edge of one viewport overflow into, and can be seen through, an
>> adjacent viewport.
>
> Ah, I see. I dimly remember that one (I'm that old ;-)

>> The other defines multiple separate "desktops", which are
>> logically arranged into a grid for purposes of indexing and access,
>> but which are individually independent; anything sticking off the
>> edge of any one of them is not visible anywhere. That, as I
>> understand matters, is the feature commonly called "virtual
>> desktops". It's my understanding that this feature *is* possible
>> via, and maybe even directly supported by, Wayland.
>
> And then, there are window managers (Fvwm) which offer "big"
> desktops (where the visible screen is a window into, which can be
> moved around seamlessly) and then several of that "virtual
> desktops".
>
> Best of two worlds :-)

I believe e16 also does this, and if I understand matters correctly,
that's just the intersection of these two features.

If you cut the number of viewports per desktop down to 1 and the size of
the desktop to the size of the viewport, you get traditional virtual
desktops.

If you cut the number of virtual desktops down to 1, and increase the
number of viewports per desktop and (correspondingly) the size of each
desktop, you get that other virtual-desktop-like feature whose proper
other name I don't recall (but which I use routinely).

(Now that I think about it, one of these two might be properly called
"multiple desktops", and the other "virtual desktops" - but I'm no
longer positive which one is which.)

I haven't tried, because I don't want to spend the screen real estate on
the necessary pager for switching among virtual desktops, or expend
potential keybindings to be able to switch among virtual desktops
without a pager - but I'm fairly sure I could trivially configure e16 to
have a 2x2 or 3x3 or 4x4 grid of virtual desktops, each of which
consists of a 4x8 grid of viewports, each of which provides access to an
area the size of my screen resolution.

>> It's difficult or impossible to tell for certain from the limited
>> discussion in the links provided, but it looks to me (having dug
>> through as far as the Phabricator discussion) as if what KDE added
>> support for is the latter.
>>
>> (FWIW, e16 apparently supports *both* of these features, although
>> the major rewrite that was e17 and later dropped support for the
>> first one; that's one of the reasons I haven't moved forward to
>> newer versions of Enlightenment.)
>
> I have the hunch Fvwm is for you. I'm using it with one virtual
> desktop which is 3x3 the size of my screen ("pages" in Fvwm
> parlance). Of course it's segmented as nine pages, but windows
> sticking out of my current page end up sticking into the
> corresponding neighbour. And I can get my screen (aka viewport) to
> straddle page boundaries (which I don't do usually, but hey).

There are other features of e16 which I like (and I can try to run
through the list in detail if desired, although it might take me a while
to dredge everything up, since I only think about most of them when
setting up a new machine or when having to live without them for a
while), but I've heard positive-sounding things about fvwm before,
certainly.

[Anssi Saari]

Nicholas Geovanis <nickge...@gmail.com> writes:

> Isn't it all about X by design to not be able to safely protect a
> running X applications to snoop on other running X applications,
> something like the content of a window cannot safely kept private?

Well, what about something basic like allowing only specific apps to
read the clipboard? Or maybe just the app that has focus, sort of like
Android does it.

[Marco Möller]

I am not sure if I understood your answer. Is it a suggestion of what
should be of importance, or is it the confirmation that Wayland is
capable to configure clipboard access restrictive like this?

Regards, Marco!

[Anssi Saari]

Marco Möller <ta...@debianlists.mobilxpress.net> writes:

> I am not sure if I understood your answer. Is it a suggestion of what
> should be of importance, or is it the confirmation that Wayland is
> capable to configure clipboard access restrictive like this?

Um, I thought a question mark is a fairly common indication of a
question? I asked a question.

[Marco Möller]

Ah, now I understood. Well, then I try to answer to my best knowledge
assuming that my knowledge is not outdated. I am not a developer and
only repeat what I found stated by others, again not having a reference
but am citing from memory:

On 14.03.22 16:23, Anssi Saari wrote:
> Nicholas Geovanis <nickge...@gmail.com> writes:
>
>> Isn't it all about X by design to not be able to safely protect a
>> running X applications to snoop on other running X applications,
>> something like the content of a window cannot safely kept private?
>
> Well, what about something basic like allowing only specific apps to
> read the clipboard? Or maybe just the app that has focus, sort of like
> Android does it.

Wayland does not provide clipboard access restrictions out of the box.
But Wayland, other than X, makes it possible that restrictions like this
could be implemented!

The implementation would have to take place at the level of the
compositor, which is kind of the equivalent of the X Server. As there
could be developed quite different compositors for Wayland, it thus will
depend on the particular compositor in use, if and which security rules
are finally available. In some more or less popular library, making
available to developers of compositors some basic functionality, it is
implemented the restriction, that only an app in the foreground can
write to the clipboard, and only an app in the foreground can read from
it. This should help that a third party hidden in the background can not
interfere with the clipboard while the users copies something from app A
to app B by switching between exactly these two apps.

Better than nothing! But this library has not implemented further
treatment of the clipboard following further rules. For instance it
would depend on an app, if it removes the content from the clipboard
after having received it. Thus, if the user doesn't delete the clipboard
right away, then a formerly hidden app C becoming a foreground app could
read it. And alike, if the user would not switch directly from A to B,
but my mistake brings to the foreground app C before having pasted to
app B and deleted the clipboard content, then app C could have
overwritten the clipboard without the user having noticed it.

Now, which compositor is using this library with at least this
foreground-app-only access rule being implemented, and which compositor
is using a different implementation, and how do the individual apps
finally make use of their right to read/write the clipboard when in the
foreground? This are many unanswered questions.

There is certainly a need of improvement. But at least, if someone would
like to contribute more sophisticated access control functionality,
then, other than X, this, as far as I remember, would be possible in
Wayland.

Regards, Marco.

[Nicholas Geovanis]

On Mon, Mar 14, 2022, 2:21 PM Marco Möller <ta...@debianlists.mobilxpress.net> wrote:

On 14.03.22 18:28, Anssi Saari wrote:
> Marco Möller <ta...@debianlists.mobilxpress.net> writes:
>
>> I am not sure if I understood your answer. Is it a suggestion of what
>> should be of importance, or is it the confirmation that Wayland is
>> capable to configure clipboard access restrictive like this?
>
> Um, I thought a question mark is a fairly common indication of a
> question? I asked a question.

Ah, now I understood. Well, then I try to answer to my best knowledge
assuming that my knowledge is not outdated. I am not a developer and
only repeat what I found stated by others, again not having a reference
but am citing from memory:


On 14.03.22 16:23, Anssi Saari wrote:
 > Nicholas Geovanis <nickge...@gmail.com> writes:
 >
 >>   Isn't it all about X by design to not be able to safely protect a
 >>   running X applications to snoop on other running X applications,
 >>   something like the content of a window cannot safely kept private?
 >
 > Well, what about something basic like allowing only specific apps to
 > read the clipboard? Or maybe just the app that has focus, sort of like
 > Android does it.


Wayland does not provide clipboard access restrictions out of the box.
But Wayland, other than X, makes it possible that restrictions like this
could be implemented!

I'm being misquoted, it wasn't actually me :-) Not a big deal.

As Marco points out, there is no reason that actions at the window level could not be individually restricted. Modified windowing systems were doing that in secure computing in the early 1990s at least. Even restricted at the level of granularity of SElinux-style Mandatory Access Control.

My comment is that one of the strengths of X Windows was the view of the graphics workstation as the server, but each application a client somewhere on the network, maybe local to the X server also. Diskless X workstations then implemented X servers partially in firmware (sometimes), tossing away local execution. No problem, in my experience.

But has Wayland tossed out the functional  separation between the X server hardware (in your box) and the OS? So that it can be closer to the graphics card? XFree86 did that if I'm not mistaken. Is that still necessary for performance or graphics compatibility reasons?

The implementation would have to take place at the level of the
compositor, which is kind of the equivalent of the X Server.

Brilliant. Exactly my point.

As there
could be developed quite different compositors for Wayland, it thus will

....

Regards, Marco.

[황병희]

Dear Kevin,

Kevin Exton <kcex...@gmail.com> writes:

> I tried Wayland some years ago now (might have been when they first
> trialled it in Ubuntu) but decided not to stick with it.

Well i don't know my login desktop what it is. Always i use default
values. Currently i'm using Debian 11 Bullseye under Chromebook. That
seems not X11, maybe... And i am happy with the default values.

#+begin_src text
soyeomul@penguin:~$ lsb_release -d
Description: Debian GNU/Linux 11 (bullseye)
soyeomul@penguin:~$ env | grep wayland
WAYLAND_DISPLAY_LOW_DENSITY=wayland-1
WAYLAND_DISPLAY=wayland-0
#+end_src

Sincerely, Linux fan Byung-Hee

--
^고맙습니다 _和合團結_ 감사합니다_^))//

[황병희]

Dear Greg,

Greg Wooledge <gr...@wooledge.org> writes:

> On Fri, Mar 11, 2022 at 10:27:18PM +0100, Emanuel Berg wrote:
>> I switched from mplayer to mpv ...
>
> And I switched from Latin-1 to UTF-8.

Very much i like UTF-8 world! Thank you for using UTF-8, Greg ^^^

> (...thanks...)

[Emanuel Berg]

황병희 wrote:

>> I tried Wayland some years ago now (might have been when
>> they first trialled it in Ubuntu) but decided not to stick
>> with it.
>
> Well i don't know my login desktop what it is.

> WAYLAND_DISPLAY_LOW_DENSITY=wayland-1
> WAYLAND_DISPLAY=wayland-0

echo $XDG_CURRENT_DESKTOP

Never says anything for me.

[Nate Bargmann]

* On 2022 16 Mar 01:53 -0500, Emanuel Berg wrote:
> 황병희 wrote:
>
> >> I tried Wayland some years ago now (might have been when
> >> they first trialled it in Ubuntu) but decided not to stick
> >> with it.
> >
> > Well i don't know my login desktop what it is.
> > WAYLAND_DISPLAY_LOW_DENSITY=wayland-1
> > WAYLAND_DISPLAY=wayland-0
>
> echo $XDG_CURRENT_DESKTOP
>
> Never says anything for me.

It's possible that environment variable is only set by certain desktops:

$ env | grep -i wayland
XDG_SESSION_TYPE=wayland
XAUTHORITY=/run/user/1000/.mutter-Xwaylandauth.B6TFI1
WAYLAND_DISPLAY=wayland-0
MOZ_ENABLE_WAYLAND=1

$ echo $XDG_CURRENT_DESKTOP
GNOME

[Emanuel Berg]

Nate Bargmann wrote:

> It's possible that environment variable is only set by
> certain desktops:

I should set it to "pox" since what it does is just

picom &
openbsd-cwm &
xterm

And maybe do a Linux distro based on pox, Poxix ...

Not sure how much the desktop metaphor is uphold tho?

[Byung-Hee HWANG]

Hellow Emanuel ^^^

Emanuel Berg <moase...@zoho.eu> writes:

> (...)

> echo $XDG_CURRENT_DESKTOP
>
> Never says anything for me.

Also i don't have $XDG_CURRENT_DESKTOP. Somewhat chromebook's Debian 11
is different from original Debian 11. Though, under Wayland i'm using
GTK-like programs such as GNU Emacs, GIMP, etc. ;;;

[Greg Wooledge]

On Wed, Mar 16, 2022 at 07:52:19AM +0100, Emanuel Berg wrote:
> 황병희 wrote:
>
> >> I tried Wayland some years ago now (might have been when
> >> they first trialled it in Ubuntu) but decided not to stick
> >> with it.
> >
> > Well i don't know my login desktop what it is.
> > WAYLAND_DISPLAY_LOW_DENSITY=wayland-1
> > WAYLAND_DISPLAY=wayland-0
>
> echo $XDG_CURRENT_DESKTOP
>
> Never says anything for me.

unicorn:~$ env | grep XDG
XDG_SEAT=seat0
XDG_SESSION_TYPE=tty
XDG_SESSION_CLASS=user
XDG_VTNR=1
XDG_SESSION_ID=1
XDG_RUNTIME_DIR=/run/user/1000

That's after running "startx" from tty1. I don't use a Desktop Environment.

[Emanuel Berg]

Greg Wooledge wrote:

>>>> I tried Wayland some years ago now (might have been when
>>>> they first trialled it in Ubuntu) but decided not to
>>>> stick with it.
>>>
>>> Well i don't know my login desktop what it is.
>>> WAYLAND_DISPLAY_LOW_DENSITY=wayland-1
>>> WAYLAND_DISPLAY=wayland-0
>>
>> echo $XDG_CURRENT_DESKTOP
>>
>> Never says anything for me.
>
> unicorn:~$ env | grep XDG
> XDG_SEAT=seat0
> XDG_SESSION_TYPE=tty
> XDG_SESSION_CLASS=user
> XDG_VTNR=1
> XDG_SESSION_ID=1
> XDG_RUNTIME_DIR=/run/user/1000
>
> That's after running "startx" from tty1. I don't use
> a Desktop Environment.

I do the same, only I do 'startx -- -nocursor' LOL, no,
compared to your output I get exactly the same except it get

XDG_SESSION_ID=254

Maybe I restarted X 253 times ...

[Emanuel Berg]

Emanuel Berg wrote:

>> That's after running "startx" from tty1. I don't use
>> a Desktop Environment.
>
> I do the same, only I do 'startx -- -nocursor' LOL, no,
> compared to your output I get exactly the same except it get

Oh, actually I start X from /dev/tty6!

xdir=~/x
tty_number=${TTY#/dev/tty}
case $tty_number in
(1) lkeys
make -C ~/.emacs.d/emacs-init
DISPLAY=":0" nice -n -18 emacs -nw 2> emacs-erros.txt ;;
(2|3|4) tmux-new-session-split ;;
(5) clear ;;
(6) startx -- -nocursor > ${xdir}/stdout.txt 2> ${xdir}/stderr.txt ;;
esac

X then executes there as well it seems as 'chvt 6' takes me to
X (or stays if I'm there already).

But I have forgotten what problem or situation it is we are
trying to solve ...

https://dataswamp.org/~incal/conf/.zprofile

[Emanuel Berg]

> X then executes there as well it seems as 'chvt 6' takes me
> to X (or stays if I'm there already).

Only works like that if you first do:

$ sudo chmod +s /bin/chvt