worth switching to wayland?

[heikkikk]

Hi.
I have been thinking if it is already good time to switch to Wayland or not.

How about the performance with NVIDIA graohics card, is it working worse, equal or better than with xorg?

Thanks.

[s0ulslack1]

Absolutely! Running a 1050 TI with Wayfire and I regret not checking things out sooner.

As with anything new it can be a pita to get working but glad this dinosaur jumped

[heikkikk]

Which driver should i pick for
01:00.0 VGA compatible controller: NVIDIA Corporation TU117M [GeForce GTX 1650 Mobile / Max-Q] (rev a1)

for Wayland?

And does that driver work with DaVinci Resolve (which currently works with X11 for me and nvidia closed source drivers)

[mistah_monocle]

Man I wanna try Wayland, but I'm just nervous about the stability of dwl. I am way too attached to dwm to switch lol

[tld]

Personally I couldn't have less desire to switch to anything than I do for Wayland...with the exception of systemd. I'm hoping that at some point someone picks up support for X11 if the freedesktop.org devs drop that. Why should Wayland be stable after only being around for 13 years right?
The lack of anything like X11 forwarding alone is enough to ice that one for me. On my LAN I use that all the time.

Tom

[heikkikk]

ok, i switched to Wayland (keeping the X11 also)
and now i cannot seem to get some programs or features working with wayland, like Zoom video conferencing app can't share screen.

so, i switched back to X11

Altho i would like to use waydroid, which only works on wayland...

un saludo...

[spica]

Zoom video conferencing app can't share screen.

Zoom has a browser version (however browser experience is not user friendly)
KDE and GNOME provide both X11 and Wayland sessions, and it is easy to switch between them via re-login.
Regarding performance of NVIDIA – I think performance is the same. I do not see a difference in FPS numbers when I run 3D applications on my PRIME card.

[Goverp]

Zoom video conferencing app can't share screen.

Zoom has a browser version
....

In my experience (firefox), the browser version merely runs the zoom app from inside the browser, and hence the same restriction - no screen sharing under wayland - remains.

[spica]

firefox

Try with www-client/google-chrome or something else chromium-based. zoom does not support FF. But the experience is not good: comparing to skype, zoom does not provide single page experience (or I had no luck to find it), they return the whole website instead, and therefore it is not usable when started in chrome in app mode. And no trayicon with missed messages notification.

These are examples how to run them in app mode:

Code: Select all

google-chrome-stable --disable-extensions --disable-plugins --disable-sync -–no-experiments --app=https://join.zoom.us
google-chrome-stable --disable-extensions --disable-plugins --disable-sync -–no-experiments --app=https://teams.microsoft.com
google-chrome-stable --disable-extensions --disable-plugins --disable-sync -–no-experiments --app=https://web.skype.com

Another issue, if you decided to prepare three *.desktop files with different icons, then all three windows will have the icon of the first started window. If teams was started first, then skype and zoom will have the teams icon. It is hard to find the needed messenger window on the overview screen if it has a wrong icon. This is caused by a known bug in chromium.

So, it is possible, but sometimes it is not user friendly. I prefer official clients, and when I know that I will need to share my screen then I switch to X11 beforehand.

[mv]

Personally I couldn't have less desire to switch to anything than I do for Wayland...with the exception of systemd.

That's a rather different story: While systemd is a decrease in security (due to its complexity), wayland is a gain in security. The fact that you cannot - in principle - avoid that your browser is reading the root password you type in another window alone is a reason to switch.

The lack of anything like X11 forwarding alone is enough to ice that one for me.

There are meanwhile tools which do that, AFAIK much more efficient than plain X, but I never tried. What you cannot do is share the whole screen due to mentioned security improvements.

[rab0171610]

"wayland is a gain in security. The fact that you cannot - in principle - avoid that your browser is reading the root password you type in another window alone is a reason to switch. "
Please explain to me how a browser is going to capture me typing my root password in a terminal when that password is not even visible or in clear text? I do need that much security. There are other ways to make sure you are not being snooped and spied upon. Wayland is not clearly better for everyone. Maybe that is necessary and works in your use case but that doesn't make it true for everyone.

[stefan11111]

"wayland is a gain in security. The fact that you cannot - in principle - avoid that your browser is reading the root password you type in another window alone is a reason to switch. "
Please explain to me how a browser is going to capture me typing my root password in a terminal when that password is not even visible or in clear text? I do need that much security. There are other ways to make sure you are not being snooped and spied upon. Wayland is not clearly better for everyone. Maybe that is necessary and works in your use case but that doesn't make it true for everyone.

If you are interested in giving xorg less privileges, you can do the things I describe here.
Don't be put off by the static /def stuff. It should be possible with udev rules too.

[Hu]

By default, Xorg allows processes to monitor keystroke events for windows other than their own. Therefore, if you type your root password in the xterm running /bin/su, other X11 clients can see it. Since it is a keylogger, rather than a screenscraper, the lack of echo does not impact it.

[stefan11111]

By default, Xorg allows processes to monitor keystroke events for windows other than their own. Therefore, if you type your root password in the xterm running /bin/su, other X11 clients can see it. Since it is a keylogger, rather than a screenscraper, the lack of echo does not impact it.

You say this it the default, how can it be turned off.
Then again, does it really mater that other programs can get your root password this way on a single-user system?

[rab0171610]

By default, Xorg allows processes to monitor keystroke events for windows other than their own

Thanks!

[user]

By default, Xorg allows processes to monitor keystroke events for windows other than their own. Therefore, if you type your root password in the xterm running /bin/su, other X11 clients can see it. Since it is a keylogger, rather than a screenscraper, the lack of echo does not impact it.

You say this it the default, how can it be turned off.
Then again, does it really mater that other programs can get your root password this way on a single-user system?

There is an attack vector difference between
entering sudo pass at already maniplulated xterm code
or running trusted-gentoo-source-compiled x11 application which is enabled by drive-by to sniff keystrokes (e.g. untrusted payload at browser runtime)
or running untrusted/binary x11 application and still do not know how easy this application can sniff all keystrokes because of X11 design from decades ago.

How to mitigate? Do X11 sandboxing.
For example with bubblewrap and xpra or for easy usage but less learning curve with firejail

[mv]

]You say this it the default, how can it be turned off.

Practically, it cannot be turned off for an X application.

Then again, does it really mater that other programs can get your root password this way on a single-user system?

Yes. Attack scenario: You click a bad webpage which uses some of the regular browser exploits to read the keyboard from another window. Then if you type your root password, the compromised browser gets even root access for free on your machine.

[mv]

If you are interested in giving xorg less privileges.

The main problem is not the privilege of xorg on your machine but across xorg apps.

[mv]

How to mitigate? Do X11 sandboxing.
For example with bubblewrap and xpra or for easy usage but less learning curve with firejail

X11 sandboxing is quite resource intensive and inconvenient, though of course better than nothing if you are forced to use X.
Section 5.2 of https://wiki.archlinux.org/title/Bubblewrap is worth reading: Essentially, they strongly recommend wayland for security reasons.

[Ja.KooLit]

check out hyprland if you go for wayland

[allistarM]

I'm curious about Wayland too, but I don't want to break my production rig. I have a two GPU, 6 monitor setup and KDE (in particular Plasma) doesn't work across more than one xscreen. Annoyingly it ignores the DISPLAY= variable so I can't limit it to one xscreen, and I can't run more than one instance of it. As it is I have a hand modified version of plasma-workspace to get it to ignore the monitors on the second xscreen (they used the xrandr output name as a way to identify monitors but this doesn't work as these are not unique when you have more than one GPU).

Right now I'm using X11 and Compiz and it works very well. There will come a time when compiz stops working though. I hope Wayland (and Plasma) work with a multiple GPU environment.

[enhaced]

Hi.
I have been thinking if it is already good time to switch to Wayland or not.

How about the performance with NVIDIA graohics card, is it working worse, equal or better than with xorg?

Thanks.

Big Wayland fan here, if you have the opportunity to switch to Wayland, DO IT!
I personally can't do it on my main machine since most software I use has poor compatibility with Wayland
but as I've said, if you have the opportunity, DO IT!

BUT WAIT!

try it out for a couple of days and keep X installed, if you come to the conclusion that you like it more than X and your software works, you can safely uninstall X and daily-drive Wayland!

[greyspoke]

Well I have used the Plasma Wayland session uneventfully until I switched to tty1 and then switched back to tty7. Instead of my Plasma session I got the ssdm log-in screen, greyed out and inactive. So back to the Plasma X session for now.

[asturm]

Works fine for me. Are you sure your Plasma session had been on tty7 in the first place?

[wjb]

I tried it for a weekend. Mostly nothing different, but VirtualBox VMs didn't work, which is a deal-breaker for me. Yes I know it's VirtualBox being arse, but it's still 'nope'.