
Are We Wayland Yet? - fourthark
https://www.swalladge.net/archives/2019/10/14/are-we-wayland-yet/
======
Svenstaro
This would be a good time to mention that sway doesn't support the nvidia
proprietary driver [0]. The author recommends nouveau but this leaves out
users that 1) have very modern GPUs 2) need vulkan 3) need CUDA 4) do heavy
gaming. The author is also quite spiteful about it and I'm not sure I like
that. There is even a flag "\--my-next-gpu-wont-be-nvidia" [1]. Whether or not
this is nvidia's fault I can't judge but there are usually two stories to
every disagreement and so far at least I haven't heard nvidia's.

For me at least, this is a dealbreaker as I don't always get to choose the
systems I get to use and I'd like to use the same config/wm everywhere if I
can help it and if I sometimes have to alternate between i3 and sway then that
won't do for me.

[0] [https://github.com/swaywm/sway/wiki#nvidia-
users](https://github.com/swaywm/sway/wiki#nvidia-users) [1]
[https://github.com/swaywm/sway/blob/3334d11adc926c0f6d86afc4...](https://github.com/swaywm/sway/blob/3334d11adc926c0f6d86afc4897117d5559036f5/sway/main.c#L101)

~~~
izacus
The thing is - nVidia uses shared source for all of their drivers. This is why
you always have the newest GPU feature support and performance on their Linux
driver - it's the same codebase as it is for Windows and was for macOS.

Linux community on other hand wants nVidia to restructure their driver just to
fit Linux model and essentially lose the source parity or publish the source
completely. It's not an invalid request, because nVidias APIs don't really fit
into Linux kernel design and userspace APIs. It's also not very likely to
happen, especially due to poisonous behaviour of kernel maintainers towards
nVidia, unwilligness to compromise and nVidias refusal to add more resources
to refactor the driver.

~~~
BiteCode_dev
Do you think Windows or MacOS make compromise on the way they code their
kernel to accomodate nVidia ?

No, it's just a matter of economics.

~~~
fwxwi
Yes, Windows has a stable driver API you can build upon.

Linux does not, because they want all drivers to be inlined (included in the
kernel) and open source. nVidia does not want to release their trade secrets,
so they don't want to open source their drivers.

(No idea about macOS)

~~~
vertex-four
Of course, AMD managed, so there’s no technical reason that nVidia cannot.

~~~
izacus
Except that AMD doesn't have feature parity with Windows driver on open source
version and has all the Nvidia driver headaches on closed source version.

I'm not sure what AMD really managed here.

~~~
nemetroid
AMD's open source driver is fully usable for normal usage (including gaming),
and in general more performant than the closed source version.

[https://www.phoronix.com/scan.php?page=article&item=rx590-li...](https://www.phoronix.com/scan.php?page=article&item=rx590-linux-
drivers)

~~~
jhasse
Still behind the proprietary Windows driver or Nvidia's proprietary Linux
driver.

~~~
MayeulC
They are not behind their windows driver on OpenGL. And neither for Vulkan, I
think. AMDVLK scores a few wins here and there, but RADV is generally more
stable, performant, and compatible. Plus being open-source, it is easily
extended, like valve is doing with their AC0 experiment [1].

Last I heard, people were installing Linux to use the AMD OpenGL drivers to
play emulators (it might have been Cemu, actually ran trough wine).

[1]: XDC2019 slide deck
[https://xdc2019.x.org/event/5/contributions/334/attachments/...](https://xdc2019.x.org/event/5/contributions/334/attachments/431/683/ACO_XDC2019.pdf)

------
young_unixer
From what I've read, it seems like Wayland's "controversial design choices"
don't stem from developers being inconsiderate of different workflows, but
rather from the intention of making a general purpose protocol.

Being general purpose means that things like screenshotting capabilities are
not the protocol's concern and should be implemented in the upper layer(s)
instead.

In that case, this general purpose approach seems to me like the right way to
tackle the problem, since we won't need a different protocol for use cases
that fall outside the traditional desktop paradigm. You can just use Wayland
and implement your own business code on top. There'll be a de-facto standard
way to do graphics on Linux, no matter your use case.

Correct me if I'm wrong about this. I'm not a Wayland expert (I have many
articles and books in my to-read list).

I'm excited about Wayland for the simple reason that I hate screen tearing.

~~~
roenxi
That means the screenshot application is, to some degree, compositor specific.
It leaves the door completely open to the outcome that if you want to stream
using a Gnome streaming application you will have to be using the Gnome
project's window manager. Or the KDE streaming application will require the
KDE window manager. Or the 'best' screenshot application will be tied to the
XMonad successor on Wayland.

Wayland is a good experiment, and the community may well go with it because
X11 is atrocious and Wayland is a viable alternative. But call a spade a
spade, they dropped the ball with that design decision. It isn't a big deal.

The practical outcome is that there is going to be a screenshot protocol and
everything that implements Wayland is going to have to implement that protocol
as well. The required negotiation for that to happen is taking/going to take
years and delay Wayland adoption. If they'd designed that at the same time as
an optional part of the Wayland protocol it would have saved time and
confusion.

~~~
ChrisSD
freedesktop have had success in standardising the Linux desktop. I fail to see
why gnome, KDE, etc wouldn't eventually standardise around a common screenshot
protocol.

~~~
AnIdiotOnTheNet
"eventually"

Windows switched to composited desktop with Vista in 2006 and didn't lose
any[0] functionality. 14 years later and we're still saying "eventually" when
discussing basic features Wayland should have.

[0] Technically it lost a few, the ability to ignore vsync for non-fullscreen
applications being the biggest one.

~~~
arghwhat
> and didn't lose any[0] functionality

Apart from stability.

Jokes aside, this has nothing to do with the protocol as much as the fact that
there are vast differences in how an open source project is developed vs. how
Microsoft develops.

A lot of Wayland development was initially funded by Samsung, which mainly
focused on usecases for their smart devices. They then shut down their entire
OSS department, so that workforce is out.

Now, finally redhat seems to be gearing up a bit, with GNOME Wayland being
default on Fedora, and sponsoring Wayland work on things like Firefox.

But, even then, things are powered by what people want and care about, rather
than just trying to tick every previous feature box available.

------
zzo38computer
I don't really like Wayland and I think X is better in many ways. There are a
few problem which is why I had some ideas about X version 12. One is to ensure
the implementation and protocol are separate. Another is proxies to implement
security features. Another is support for SCM_RIGHTS and SCM_CREDENTIALS (only
for local connections; these are obviously not supported for remote
connections, which are still possible, if implemented by the server and
enabled by the user). And then, also 64-bit numbers in many places. But a lot
of it is like the version 11 protool (without all of the extensions they have
added), but with a few differences. (I don't really like much of the
freedesktop stuff either; I work without a desktop environment, and programs
should not assume the existence of one.) Maybe there is even a possibility to
implement these different systems over each other when needed.

For example, with text rendering. Font path setting is not part of the core
protocol (although there may be a XSET extension which can do this on some
implementations), nor does the protocol specify font formats (PCF is
recommended, but the protocol doesn't actually care so you can implement
different formats if wanted). Characters are still sixteen bits, although to
allow optional support for some more modern features, there are two flags you
can specify when loading fonts: EnableLigatures and EnableAntialiasing.
Servers that don't understand these flags can ignore them, and fonts that
don't support them would also ignore them. EnableLigatures waives the
requirement that a sequence of characters is the same as each of those
characters put next to each other, and EnableAntialiasing waives the
requirement that text is painted in the specified background and foreground
colour only. (EnableLigatures is required to correctly render Unicode text
with the X core text rendering system (if the server implements support for
Unicode fonts, which is of course optional). Of course you are not required to
use the core text rendering (previewer programs should not use it, for
example), but if you do, and your program uses Unicode, then this will be
needed. In effect, a surrogate pair is treated like a ligature at the protocol
level (how it works in the actual implementation may differ, and is
independent of the protocol).)

~~~
braindeath
> But a lot of it is like the version 11 protool (without all of the
> extensions they have added),

It’s hard to tease out, but it sounds like you’re advocating for the state of
the art drawing model of 1980 in 2019. I don’t think this is going to fly
except for a very niche audience.

~~~
ColanR
I've seen this sort of comment frequently: "it's 2019, why are we still doing
n?", as if somehow it should be assumed we have grown out of it.

It's a completely unsubstantiative argument; its effect is to sweep under the
rug any justification for the 'old way' of doing things.

~~~
TylerE
No, it isn't unsubstantiative at all.

For one very big thing, hardware accelerated rendering didn't exist in 1980.

Also, no one really cares about network support anymore, because it's simpler
and better to just do a screen share.

~~~
nirvdrum
Does Wayland improve the remote desktop story at all? I sometimes drop to X11
forwarding because VNC and X2Go don't really work so well for me. If I think
I'm going to need a remote desktop for a while, I'll reboot into Windows and
load my Linux installation up as a raw disk VM in VMware Workstation and then
rely on Windows's RDP for remote desktop. I'd love to simplify all this.

~~~
burpsnard
I had good ux with realvnc, maybe novnc, ..

~~~
nirvdrum
It's been a while, so maybe I'll give that shot again. My experience with VNC
is that it's just laggy and really doesn't like it when I connect to a multi-
display desktop with a single display laptop. Windows Remote Desktop adapts
beautifully with virtually no lag, so I was hoping Wayland adopted something
similar.

------
Jeaye
Before I touch on Wayland and X, a brief detour.

Let's assume Mozilla finishes servo (their browser in Rust). Let's also
assume:

\- It's faster than Firefox.

\- It's safer than every other browser out there.

How do they get people to use it? Those two are not enough. To the user:

\- It's different.

\- Firefox feels plenty safe.

This is a real problem and Mozilla faces it now. As a result, they're focusing
on what they can do with servo which no browser has done before, like superb
VR support. In short, they need _features_ to gain users and they recognize
that. Marginal gains are not enough to encourage an entire product switch.

Back to Wayland. Aside from the lack of screen tearing, what can we all agree
are big wins for the user? I haven't tried it yet (for this reason), but
everything I've read suggests that it could be safer, it could be faster, it
could bring some more new features, but mostly it's the same shit.

The masses, and this definitely includes the GNU/Linux using masses, need more
than the same shit to change because change is tough. They are going to need
something killer from Wayland, or another competitor, before they give up on
X.

~~~
m45t3r
This is kind the objective I think. Wayland in most cases (Gnome and KDE) is
simply an implementation detail, and Gnome and KDE runs in both X11 and
Wayland.

The end result is, hopefully, less bugs, more security and more performance,
however most people wouldn't care anyway (and I think most people doesn't
care, for example Fedora uses Wayland by default).

For us using window managers like i3wm the history is different. However in
i3wm I am very close to the X11 so there is almost no abstraction, this is why
the transition is more painful.

~~~
asveikau
Nobody replying to you seems to catch on that _i3 is not the only environment
other than KDE and Gnome_.

i3 users have sway. Good for them. Now what about _every other window
manager_?

~~~
Izkata
Indeed; I've used wmii for around 10 years now, and its developers have openly
stated they will never support Wayland.

~~~
bitwize
They might want to consider revising that decision because X is going away. If
they don't, wmii will go away with it.

~~~
onlydeadheroes
X has been going away for longer that the careers of most people on this site.

~~~
asveikau
At this point maybe even longer than a substantial chunk has been alive.

------
jchw
Important to note that Sway WM is not Wayland as a whole; I am a happy Sway
user, but unfortunately it is not 100% at parity with the experience you will
get with GNOME. However, you can always contribute if you have time; it’s fun
and the codebase is very nice to work with. You don’t even have to switch to
Sway to work on it. (If you are skilled at debugging and use graphics tablets
we could use some help trying to figure out some crashing bugs with
tablets...)

Regarding screen capture: wl_roots actually supports this, but WebRTC doesn’t
support the wl_roots protocol for it. I’ve been told Pipewire should solve
this problem eventually.

Edit: accidentally wrote Waypipe instead of Pipewire. (Waypipe is cool too,
though.)

------
daurnimator
> The fact is, Wayland is the only viable X11 successor

There's at least one other option in the running, Arcan: [https://arcan-
fe.com/](https://arcan-fe.com/)

~~~
cnasc
I'm a big fan of Arcan (moreso than I am of Wayland), but it's nowhere near as
far along as Wayland and I think at this point is still the product of just
one person. I think it's fair to call Wayland viable, but I don't think I
would say that of Arcan until it's:

a) generally usable as a daily driver; and

b) maintained by enough people that there isn't a single point of failure.

Right now I'm still on X.

------
coldtea
The discussion in the post, the description of what a technical user had to do
to switch, the problems encountered, the X11 problems mentioned (tearing,
etc), and the suggestions and workarounds in the comments, should be mandatory
reading before someone calls Linux "ready for the desktop".

For some reason Linux discussions are bimodal: in some everybody chimes how
perfect everything works, and what peace they found switching to it. In
others, like this one here, it's all about all kind of problems, hacky
solutions, tinkering with system settings, and so on, and still having serious
issues.

~~~
olau
If you like tinkering, you can certainly do so, but there's a maintenance cost
to customizations, and if you're not willing to shoulder them, then you should
go with something closer to the stock install where the distribution will
generally have sorted out things for you.

Perhaps this is the explanation you're looking for?

Actually, I think, and this is perhaps somewhat surprising, that many software
developers don't pay terrible much attention to future maintenance costs.

------
nhumrich
My biggest problem Wayland, is no screensharing. (i.e. casting on Chromecast,
sharing screen on zoom). Apparently this because of security. Is this possible
to overcome? Is this something can fixed by simply having chromecast/zoom devs
implement something? Or will it never be possible?

~~~
jchw
Good news actually, it's already being worked on. As mentioned, Pipewire is
the current leading solution. Upstream WebRTC has experimental support for
Pipewire; in Chromium it can be enabled with a flag and in Firefox it can be
enabled with a patch or configuration flag (I believe it is supposedly merged,
but not sure if stable versions will compile and work with it.)

GitHub is down atm but there's also an xdg-desktop-portal implementation for
wlroots which should allow for Pipewire clients to run under Sway (I have not
tried this personally, so I have no idea if it actually all works in practice
yet.) [https://github.com/emersion/xdg-desktop-portal-
wlr](https://github.com/emersion/xdg-desktop-portal-wlr)

~~~
Boulth
It doesn't sound like it's ready (as of June):
[https://github.com/emersion/xdg-desktop-portal-
wlr/issues/4#...](https://github.com/emersion/xdg-desktop-portal-
wlr/issues/4#issuecomment-510622361)

------
frio
I've been using Wayland full-time (via Sway) since Sway went 1.0. It's been a
pretty straightforward experience. The transition took some elbow grease at
first (things like getting redshift working, as the author notes), but the
last time I fucked around with my graphical config was months ago. I use a
display manager, so the "crashes lead to an exposed terminal" thing doesn't
matter so much (I've had a total of two crashes, once when I was putsing with
XWayland, video games and multi-head -- and the other when building a since-
abandoned alternative to kanshi).

There are some quirks I need to spend a little more time investigating whether
they're caused by Sway/Wayland or just my configuration: drag-and-dropping
between windows seems to be busted, and right-click context menus that
overflow their host window's boundaries aren't clickable outside those
boundaries. But I mainly use the keyboard/terminal/TUIs, so I don't frequently
drag and drop, and it's easy enough to right click somewhere else when the
second issue occurs.

Other than that, for how I use a computer, it's been smooth sailing. I
wouldn't say we're Wayland yet for general usage either, but for the group of
users who are into tiling window managers, we're maybe Wayland enough for now.

~~~
ColanR
I use i3 (with X11), and the last time I messed around with my graphical
config was when I installed the system 18 months ago. Haven't had any issues
even close to what you're describing, much less the screen tearing that I have
never seen in my last 10 years of linux.

~~~
frio
Like I said, getting started took some elbow grease, but as a daily driver on
my personal and professional machines, Sway's never once crashed or behaved
poorly. I no longer need to tinker with it or worry about it; hence, I believe
that for the collection of people willing to hammer at something a bit when
they first pick it up, Wayland's in an OK space.

~~~
ColanR
You described several crashes and a number of bugs, above, which is what I was
responding to. Even from your generous assessment of Wayland/Sway, it seems
like my X11/i3 system is more robust and stable.

------
proverbialbunny
>One point that I totally forgot about, but is now painfully apparent now that
I'm back on X11, is screentearing. On Wayland, screentearing is a thing of the
past. Everything was so smooth, flicker-free, and tear-free. Now I need to
mess around tweaking compositors to get a nice experience on X11 (i3)… So
that's a big plus for Wayland.

This was my big hold up of using Linux as a whole. The screentearing is
horrible, and coming from OSX where everything is as smooth as butter, it is
an issue. But thankfully, Mint (which I'm on atm) allows the user to turn off
vsync, and because I have an nvidia graphics card, I can turn on full-
composition, and have my graphics card do vsync, and BAM! smooth as butter.
It's an absolutely lovely and wonderful experience.

I don't know what it's like on the AMD or Intel side, but with hardware
becoming more powerful and better supported, I don't think the future is
Wayland, but instead defaulting to a higher level of gpu acceleration than the
default Gnome settings we have today. This removes the latency, the page
tearing, and responsiveness issues that X11 has Wayland was created to fix.

~~~
swalladge
> I don't know what it's like on the AMD or Intel side

I recently switched to AMD - that, with a compositor (compton/picom), resulted
in a super smooth tear-free experience in X for me.

My experiences with Intel integrated graphics has always poor performance, and
bad screen tearing, sometimes screentearing even with compton running.

------
seminatl
A good way to think about Wayland is the screen manager brought to you by the
people who thought xrandr, Mesa, Cairo, the Linux FireWire stack, and freetype
were good things. If you come in with appropriate expectations you’ll be
amazed that any of it works at all.

Is you think it over for a bit you’ll realize that the real Linux graphics
protocol is Android SurfaceFlinger. Wayland is like five orders of magnitude
less popular.

~~~
epx
I have had this unpopular opinion since the beginning of the decade: Linux
should just adopt AOSP UI, be able to run apps, and that’s it.

~~~
imtringued
So what stops you from doing just that? (There is ChromeOS, anbox and co)

~~~
yjftsjthsd-h
And Android x86, to take it from a slightly different angle

------
pdonis
Please, please, please, people, don't impose your personal choice of font and
background color on the rest of us. Faded beige background with light colored
font makes this hard enough for me to read that I simply gave up. Yes, I have
a particular issue since I'm partly red-green colorblind--but a substantial
percentage of people have color perception issues of one sort or another.
There's a reason why black text on a white background is so common.

~~~
swalladge
I hear you. Thanks for the feedback. I'm planning on toning down the color
scheme a lot now. I'll post further updates on the issue that you or someone
else has raised on github:
[https://github.com/swalladge/swalladge.net/issues/1](https://github.com/swalladge/swalladge.net/issues/1)

The site should work nicely in reader view or through an rss reader which
could be a temporary option until I can fix it. Sorry for the inconvenience :/

~~~
swalladge
Resolution: tweaked the font colours to be higher contrast and removed custom
absolute font-weights. Please let me know if there are other accessibility
issues with the site. :)

~~~
pdonis
The font is easier to see now, but the background being as dark as it is still
makes the font harder to read than if the background were white or something
much closer to it.

------
edgyquant
Gnome/Wayland on Fedora works pretty well last time I used it. I eventually
had to switch back for a few reasons (mouse over the network had no
replacement) but that was almost a year ago I'd bet it was even smoother now.

~~~
baroffoos
My work laptop has been on wayland for years now. My desktop was on x11 due to
nvidia drivers but now I have an amd card in it so I am back to wayland.

------
sprash
The biggest hurdle for Wayland adoption is the absolutely brain dead "security
model". Commonly used features like hotkey daemons, push to talk, screen
recording/streaming/sharing, window management, clipboard history manager or
even Wallpapers need to managed by the particular implementation (of there are
many) of the Wayland server itself and have mostly no common protocols, at
least not official. And when all those protocols after a long process are
finally finished I have serious doubts that Wayland will be either less
bloated and "messy" or more secure than current X11.

The non-existent X11 security model is not really ideal but at least you could
mitigate the problem there with access control hooks and as long as you use
trusted software (which is 99.9% the case on a typical Linux system) you can
use all the above mentioned features today without having too much headaches.

~~~
snagglegaggle
The non-existent X11 security model is irrelevant considering on most systems
anything under a uid can debug something else under a uid. Wayland's security
is entirely pointless.

I suspect Wayland will just become a container for an X11 session.

~~~
paulddraper
> considering on most systems anything under a uid can debug something else
> under a uid

Right? Couldn't only security hardened distros like SELinux take advantage of
this?

Or I suppose Docker GUI apps?

~~~
michaelmrose
Docker isn't a security layer

~~~
paulddraper
Security isn't the only thing Docker offers, but yes Docker on Linux is a
security layer.

------
shmerl
Not quite overall, at least from my perspective.

1\. Adaptive sync still needs Wayland protocol support, before compositors can
pick it up. It already works on X.

2\. Some major features like common frameworks for screen capturing need to be
agreed on, in order to avoid reinventing the wheel in tons of incompatible
ways. Did everyone agree to use Pipewire, or it's still bikeshedded with
everyone trying to do their own thing? I wasn't following this recently.

3\. KWin has some major bugs to fix for the Wayland session, like subsurfaces
clipping issue.

4\. Support for Wacom drawing tablets is still missing in KWin on Wayland.

And so on.

~~~
AnIdiotOnTheNet
What I'm hearing is, by the time Wayland is actually on par with X, feature-
wise, it will by time for a whole new rewrite because something else will be
fundamentally different in the way graphics are rendered. Windows went full
compositor with Vista in 2006, with all the features and then some of its
predecessor (except you can't have windows with no v-sync). 14 years later
Wayland almost has a standardized way of taking screenshots.

~~~
shmerl
Possibly the part of the problem is, that there is no single owner and no one
directs it. Everything seems chaotic, many things are low priority for
developers, while in practice they are high priority for users and so on.

I suppose that's the natural consequence of Linux desktop stack being
developed so collaboratively. And the fact that desktop itself is so
fragmented (KDE, Gnome, etc.) doesn't help either. Resources are spread quite
thin.

The major problem with Wayland is, that unlike X which is a unified point of
collaboration, Wayland compositors need to do all the work on their own
(unless they figure out how to share the effort, which doesn't go too well so
far). So problems of fragmentation and lack of resources are only amplified in
Wayland case, causing a huge delay in overall progress.

And I'm not saying all the above is a bad thing (some argue choices are good
and etc.). But the downsides are obvious.

Personally, I'd prefer developers focusing more on KDE, but Gnome users would
likely disagree.

------
microcolonel
The thing about scaling is a bit difficult. Sway chooses to render XWayland
windows in the lower resolution and scales up, rather than the other way
around; I think this should be configurable.

~~~
pzone
I don't see what would make such a configuration option particularly
difficult. Maybe file a bug report requesting it? The scaling difficulties are
fundamentally a problem with XWayland so you're left with two problematic
options.

~~~
microcolonel
> _The scaling difficulties are fundamentally a problem with XWayland_

Well, sort of. There are fundamental issues with having per-display scaling in
X. If you plug in a HiDPI display after starting an application, it's my
understanding that there is no standard way to signal that to a window.

The toolkits, or GTK+3 at least, do handle changing the scale at runtime
internally, so it's more of a social problem than a hard engineering one.

------
bengalister
Here are the issues that I still have (other than that it seems smoother):

\- I could not make copy/paste work from a Wayland host to Wayland guest in a
Qemu/KVM VM. It seems that the guest utilities like spice vagent only work for
Xorg.

\- I noticed that chrome/firefox are still relying on X and run in XWayland
(at least on my arch setup).

\- Fractional scaling make some applications blurry but it seems that they are
the ones running in Xwayland.

------
mmerlin
VAAPI support on Wayland is painful.

I've built a kiosk system that requires videos playing in Chrome/ium (cannot
use Firefox because also need web-bluetooth support)

Our hardware is Intel NUCs and currently we are rolling these out on Windows
OS, but would vastly prefer Linux but hitting so many roadblocks.

Trying to get Intel hardware accelerated GPU video decoding working in
Chromium running on Wayland has wasted me days of time with no resolution yet
(tried ClearLinux and CentOS 8 and Ubuntu 16).

With Wayland on Intel hardware, only VLC player can make use of VAAPI but
Chromium doesn't seem possible, which results in 100% (Celeron) CPU usage
trying to view a local video in the browser using video.js player.

I'm going to ditch Wayland (Gnome) and try Xfce on my next attempt.

~~~
ubercow13
Are you sure you’re using a build of Chromium with VAAPI support patched in?
Support for hardware video decoding in Firefox on Linux does not exist at all,
and Chromium does not support it either except in a set of patches which are
not included upstream.

~~~
mmerlin
yes I am using chromium-vaapi thanks.

[edit] I am about to try Arch Linux (or Manjaro) with Xfce to get Chromium-
vaapi working

[https://wiki.archlinux.org/index.php/Chromium#Hardware_video...](https://wiki.archlinux.org/index.php/Chromium#Hardware_video_acceleration)

------
naranha
Most xorg drivers have an option to run in tearfree mode.

Another dealbreaker for me (i did the i3 sway journey this summer) is the
early stage of remote desktop. With x it is super easy to spin up a nice
vncserver. I also miss setxkbmap, xrandr, import etc.

Wayland had some nice ideas and some not so useful ones. I'm waiting for
something simple to replace xorg and wayland in the future.

~~~
trulyrandom
Tear free mode has never worked for me on multi-monitor setups. All Xorg
drivers have this issue in my experience. Nvidia, AMD, Intel and even the
modesetting driver. Wayland seems to magically fix it.

~~~
naranha
Strange, it seems to work fine for me on 2 FHD monitors at least. Maybe I just
don't see it...

~~~
trulyrandom
Hmm. Perhaps it has something to do with the fact that the refresh rates of my
two monitors are not exactly the same.

------
erik_seaberg
Any news on remoting Wayland? This article kinda ignores it, but I don't see
how it's not a complete showstopper.

~~~
pabs3
The Waypipe Summer of Code project implemented that recently:

[https://gitlab.freedesktop.org/mstoeckl/waypipe](https://gitlab.freedesktop.org/mstoeckl/waypipe)
[https://lists.freedesktop.org/archives/wayland-
devel/2019-Au...](https://lists.freedesktop.org/archives/wayland-
devel/2019-August/040819.html)

~~~
erik_seaberg
Outstanding. Are they software rendering at the client and shoving raw images?
Remote GPU from scratch strikes me as an even bigger job.

~~~
aspaceman
Since it’s SOC there was a blog post for it that got posted here. Should be
findable with some searching.

~~~
erik_seaberg
[https://news.ycombinator.com/item?id=20848334](https://news.ycombinator.com/item?id=20848334)

------
MayeulC
> NetworkManager GUI tools were strangely buggy with wayland. It wouldn't
> always crash, but sometimes the only way I could get it to connect to a wifi
> network was to quit sway, launch i3, connect with nm-applet in i3, then
> switch back to sway.

I haven't tried using something else than nmtui, TBH

> Sometimes, Sway would crash while the screen was locked, leaving my
> previously secured computer at a logged-in tty

Ah! I've had some issues running SysRq+R, then Ctrl+C. The tty intreprets this
as my wanting to quit sway :/

I was actually disappointed to find out that screensharing not working was
preventing me from using Steam's in-home streaming (or Steam Remote Play, as
it's now called). I hope sway can fix that for Xwayland apps at some point.

------
ddtaylor
For me KDE has offered the best Wayland experience. It's easy to switch
between X or Wayland.

------
some1else
I'm using the latest Ubuntu to run an art installation. So far I've been
unable to launch GUI apps or take screenshots from a remote SSH terminal under
Wayland. I had to resort to adding the commands to autostart & rebooting.

------
tbenst
Tried to use Wayland earlier today on Ubuntu 18.04 for fractional scaling
support, but sadly there is no support for nvidia drivers. This does not seem
well advertised so posting as a PSA to save others from trying to debug the
login loop!

~~~
swalladge
To clarify, it _does_ support nvidia through the open source nouveau drivers.
It's only the proprietary drivers that aren't supported.

~~~
michaelmrose
You mean it does not support the drivers that actually work?

~~~
swalladge
Yes exactly. I don't recommend nvidia.

~~~
michaelmrose
This is a good reason to select different new hardware but insufficient to get
rid of existing hardware.

If most people agree we can worry less in 5-10 years. Unless people work
around it during this time frame in which case people can continue not caring.

------
mistaken
I've tried wayland around half a year ago, but switched back. Wayland was
surprisingly usable, but a couple of features were missing that are essential
for me for example color management.

------
bsder
> Screen recording or sharing apps just don't work. Zoom with XWayland
> appeared to work, but in reality only shared a blank screen. This was kind
> of a deal breaker, because sooner or later I will need to use screen sharing
> in Zoom for work.

Isn't this one of they key points _FOR_ Wayland, though? I thought Wayland
specifically stops applications from having access to other chunks of the
screen without special permissions?

~~~
fake-name
"Doesn't give access by default" is very different from "cannot be made to
work".

I'd assume the complaint is about the latter, which is a issue. I can't
imagine anyone complaining about the first.

~~~
swalladge
Agreed. The extra security given by the latter is a huge win for Wayland, but
it needs to be possible to give access when required.

~~~
swalladge
s/latter/former

------
lasftew
Last time I tried to migrate to wayland on a hidpi device, scaling wayland 2x
would scale all xwayland windows naively by doubling pixels. In particular,
this made graphical emacs fonts blurry. Is there a way to fix that, i.e.
letting wayland apps scale natively, but scale xwayland apps using the regular
X dpi setting (Xft.dpi and the like)?

Emacs may be old and crufty, but unfortunately is my most often used graphical
application.

------
grandinj
The problem with Wayland is the extremely long tail of use-cases that it does
not cover (yet).

(For example, I use VNC extensively and it has a lot of issues there still)

~~~
majewsky
After reading through this thread, my impression is more like VNC being the
_only_ use-case that is not covered enough yet. What are the other uncovered
use-cases?

EDIT: Okay, VNC and xmodmap.

~~~
grandinj
I believe accessibility integration is still on the to-do list.

------
harry8
What happened to Mir if Wayland is the only viable x11 alternative?

A cruel friend has suggested everything touched by Ubuntu billionaire founder
Shuttleworth turns to manure but I think this isn't so helpful to understand
why Mir seemingly died completely? Even GnuHurd hasn't died so dramatically..?

~~~
gmueckl
Due to the huge PR fuckup that was the Mir announcement, they never gained
much traction in the greater community. And a display stack needs a lot of
community support across the whole ecosystem: kernel support, kernel drivers,
user space drivers, widget libraries, applications etc... none of these
parties were willing to support Mir in any way.

------
appleflaxen
> Wayland has xwayland, which somehow provides mini embedded X server(s) for
> GUI apps that don't support wayland yet. I kept this disabled when
> switching, going for the "pure" Wayland experience.

this seems like a really limiting decision in deciding how viable wayland is.

------
voldacar
Is wayland viable for gaming yet or does it still add an extra frame or two of
latency?

------
chris_wot
I just cannot get Wayland work on a VirtualBox instance of Ubuntu, with the
host being MacOS Catalina on an iMac Retina. The screen just keeps flickering.

I would love it if Wayland would work!

------
mortdeus
Ive been using wayland and sway for about 2 weeks now.

My experience is this.

If it's compiled to run for Wayland. Fan f-in tastic. No hiccups, no random
screen tears or visual glitches of any kind. My logs are surprisingly sparse
and when there is a configuration issue it's something trivial i overlooked
and easily fixed.

Now here is the issue. When it comes to X-Wayland. Well lets just say that my
opinion of X-wayland can be boiled down to two major criticisms.

1\. It's turning into another X11. I've been trying to get apps that should
just work out of the box when running on gtk like Google Chrome. And frankly
looking at the bug reports and hack ass solutions to get things like Video
Hardware Acceleration to function using X-Wayland... Nightmarish to say the
least and glad it's not my job.

2\. I think history has shown time and time again with debacles like Apple
trying to retain backwards capability for powerpc MacOS or Windows ensuring
your archaic MS-DOS application at work doesn't end up need an expensive
update.... that any time you try to not throw things away that need to be
thrown away, regardless of how sentimental they might be, you always end up a
dead hoarder buried somewhere in your house where nobody can find you but they
can sure as hell smell you; so they know you are in there somewhere... Where
ever the hell that may be.

My attitude when it come's to the critics of Wayland is to say build something
better or shut up and just not use it and keep letting X11 make the desktop
experience on Linux suck on two fronts.

The first where nobody who is working on it actually knows how the entire
thing works except maybe a handful of people. (all of whom are btw wayland
core developers).

And the second, where things just don't work like they should out of the box
on whichever desktop environment circumstance you may be in. When you have
such a complicated API you end up with 50 million different ways 50 million
different developers can write bugs into the 50 millionth reimplementation of
your system.

There is a reason why Unix was the most ripped off and successful operating
system in the world. It's not because it had X11...

------
Hello71
hooray, finally a wayland criticism article that actually put in some effort
instead of "muh unix philosophy". most of these issues are real issues for
wayland today, and the author might be right to switch back to X for now.
however, I'll try to explain some of the issues:

> I had consistent font rendering issues. There was this painful issue in sway
> relating to display scaling that caused fonts (among other things) to be
> missing, fuzzy, or just terrible in general.

yup, still a problem. hidpi doesn't work great on X in the first place, and
adding Xwayland definitely makes it worse for X applications. but, once the
majority of applications are ported to wayland, hidpi should become much, much
better.

> NetworkManager GUI tools were strangely buggy with wayland. It wouldn't
> always crash, but sometimes the only way I could get it to connect to a wifi
> network was to quit sway, launch i3, connect with nm-applet in i3, then
> switch back to sway. Bizarre.

personally, I recommend using either raw wpa_supplicant or iwd with a separate
network management daemon (dhcpcd or systemd-networkd). the wpa_supplicant GUI
is very ugly and uses weird terminology (what's a "PSK" \-- yes, I know what
it is, but if you didn't, you'd have to google it), but if you can get over
that hump as well as the initial configuration, it's been 100% reliable for
me, unlike NM, which _usually_ works but then sometimes silently fails
somewhere. I recently switched to iwd, which has been mostly fine, but, like
wayland, still lacking features important for some people.

> Sometimes, on my desktop, everything would lock up for 10 seconds or so, the
> screen would blank, and then come back on and everything would be fine. It
> appeared to be some issue with the graphics drivers - I don't have that
> issue on i3, so something deep in Wayland is interacting strangely with it.

I would assume you are using intel drivers and are experiencing a GPU reset.
check dmesg, but it's quite possible that a poorly behaved application is
causing the trouble.

> Screen recording or sharing apps just don't work. Zoom with XWayland
> appeared to work, but in reality only shared a blank screen. This was kind
> of a deal breaker, because sooner or later I will need to use screen sharing
> in Zoom for work.

yeah, this is definitely a problem. as other commenters have said, ordinary
applications aren't allowed to just record the screen, they have to ask the
compositor. unfortunately, this has not yet been standardized between
different wayland implementations. iirc, gnome has a screen recording api, kde
has one, and wlroots has another, and they're all incompatible. my current
solution for sway is to use wf-recorder + v4l2loopback, which works fairly
well but is a little bit hard to set up. install wf-recorder-git and
v4l2loopback-dkms-git, then modprobe v4l2loopback exclusive_caps=1 video_nr=7
&& wf-recorder -m v4l2 -f /dev/video7 -c rawvideo --pixel-format=yuv420p. then
you'll have a fake camera device which you can select in your streaming
application. that works for me on Firefox 70 and Chromium 78, so it should
work for Zoom too. the workflow is not as smooth as built-in screen sharing
(for one, you can't display two "cameras" at once), but it works well enough
for most purposes.

> Sometimes, Sway would crash while the screen was locked, leaving my
> previously secured computer at a logged-in tty. Not great for security!

this is actually very easy to solve.

solution 1: instead of running sway, run exec sway.

solution 2: instead of running swaylock, run physlock. if security is a high
priority for you, this is probably better anyways.

~~~
swalladge
Thanks for these comments!

I definitely need to migrate away from NetworkManager; I think you just gave
me the motivation to do so. :)

~~~
iam-TJ
You might find 'nmtui' (Network Manager Text User Interface) more helpful if
you prefer an ncurses based interface similar to the GUI nm-applet (but it
doesn't work for GUI-only configuration extensions for some VPNs, etc.)

'nmcli' is good for basics, eg:

nmcli == connection summary inc. addresses, routes, DNS

nmcli dev wifi == wifi networks found (inc. specs)

nmcli dev wifi rescan

nmcli con == list configured connections

nmcli con up Connection-Name

nmcli con down Connection-Name

most of the above support intelligent tab-completion including of (space
containing) connection names.

------
mouldysammich
on the lack of clipboard history:
[https://github.com/sentriz/cliphist](https://github.com/sentriz/cliphist)
this exists and is pretty good.

------
epx
I lost the faith, guess Joel law of not rewriting things was again upheld.

------
imode
I don't agree with the assumption that we need to ditch X11 entirely.
Implementations are different from the spec, and a common complaint I have is
that certain implementations are gathering code smells like nobody's business.

You can fix both an implementation and a spec by continued review and
revision, while making choices to either remain backwards compatible or
breaking that compatibility with newer revisions. I don't think Wayland is a
good solution to this kind of problem, despite it being touted as one in many
circles I've witnessed.

The competition is nice, though! I have yet to give Wayland a try, but it's on
my to-do list some time on a fresh machine.

~~~
paulie_a
X has long been a crufty dusty codebase. Due to a small amount of people that
obsess about networking it has stayed alive. Hopefully Wayland hits critical
mass and x can finally be old yellered as it should have been twenty years ago

Due to the down votes let me clarify. X sucks

~~~
michaelmrose
I want things that only work under x that aren't spacebar heating.

------
sjy
Summary: yes, unless you use video conferencing and screen sharing software,
which is likely to be totally broken (but see Hello71's comment). The author
needs to use Zoom, so he reverted to X11.

~~~
zamadatix
That's not at all an accurate summary. I'd cover why but really the article is
apt and to the point on doing so without summarization IMO.

