
Wayland misconceptions debunked - ddevault
https://drewdevault.com/2019/02/10/Wayland-misconceptions-debunked.html
======
DiabloD3
There are an awful lot of comments on here that are trying to protect Nvidia's
anti-Linux position.

Nvidia's position, literally, is their GPUs are _not_ Linux compatible. The
Linux ecosystem relies on the Mesa stack (Mesa, DRI, DRM, GBM, KMS, etc), and
DRM is part of the upstream kernel itself... Nvidia has openly not used _any_
of these APIs.

This is exactly equivalent to Nvidia not using WDDM and DXGI. If Nvidia chose
to do that, Microsoft would outright ban them from driver certification (thus
the platform entirely), so why is it wrong for Linux and Wayland to do the
same?

The Linux community reached out to Nvidia and help them along with Nouveau,
and at one point even threatened to sue them. Linus Torvalds has told them
that he doesn't care about them if they won't actually participate in Linux,
and will continue to break their drivers because they just don't listen.

~~~
eschaton
Nvidia’s position seems to be that Linux needs to grow up and provide a stable
driver API and ABI, and stop claiming anyone is a “bad actor” just because
they don’t want to put their drivers under the GPL, make them part of the
Linux kernel source tree, and essentially give up control of them.

I’m honestly surprised the major distros haven’t gotten together to do this,
in a shared fork if necessary. It’s outright embarrassing that this attitude
still infects the Linux project.

~~~
ddevault
This is perhaps the most important feature of Linux, and _far_ from a problem.
Nvidia needs to get over itself and put its driver in the upstream tree. AMD
did it and it's been a huge success. Linux's unstable internal API and GPL'd
nature has been a huge driving force behind the availablity of open source
drivers. Hell, many distros with stable driver APIs like *BSD have Linux to
thank for many of the drivers they have, because without Linux there never
would have been open source drivers or specs in the first place.

None of the distros are going to get behind your fork because all agree with
Linux on this matter, rightfully so. Nvidia can fuck off with their
proprietary crap, Linux has no intention of bending over for that garbage.

~~~
janoc
Sorry, that's bollocks. AMD _did not_ put their driver into the upstream tree!
What is in that tree is the open source driver developed by volunteers, based
on ATI specs.

ATI/AMD still has their own proprietary, closed blob driver that is not in the
tree - and which actually runs quite a bit faster than the open source one.

~~~
ddevault

        $ cd ~/sources/linux/drivers/gpu/
        $ git log . | grep "@amd.com" | wc -l
        42418
        $ cd ~/sources/mesa
        $ git log | grep "@amd.com" | wc -l
        4817
    

>ATI/AMD still has their own proprietary, closed blob driver that is not in
the tree - and which actually runs quite a bit faster than the open source
one.

It doesn't run faster, this is nonsense. I've personally met the AMDGPU driver
developers and if you ask them they'll even tell you that basically no one
needs AMDGPU Pro. It's not faster, _this_ is bollucks.

~~~
microcolonel
To add to this, AFAIK there are two main reasons why they still have AMDGPU-
PRO: it has the more compatible, better-performing OpenCL implementation
(which you can run alongside Mesa, actually), and until recently it supported
slightly different display features, and more compatibility profile
functionality. As Mesa becomes more compatible with bizarre certified
industrial applications and, and the upstream AMDGPU kernel driver enables
more exotic display features, I suspect AMD might choose to just maintain Mesa
for these GPUs.

------
onli
What a refreshing difference to other Linux ecosystem changes! Errors like
enforcing client side decorations get corrected, there seems to be activity to
add the features missing compared to X, and most importantly: Instead of
replacing the existing working solution with broken crap because it's modern,
Wayland slowly integrates itself into the ecosystem, and it has Xwayland,
which should minimize breakage when moving over in a few years. And if I look
at the stutter X produces with my window manager every time the compositor is
off, and given that said compositor compton is abandoned and there seems to be
no better alternative, I understand that there might be a need for a different
solution.

I got hit by strange Wayland bugs when distros like Ubuntu and Fedora
activated it too early and I'm not looking to make the switch anytime soon,
but I wish the project the best and am happy to see it seems to be on a good
way.

------
jancsika
> Wayland doesn’t support Nvidia!

There is a very high likelihood that when a user complains about Wayland
support for Nvidia they mean this:

* user already assumes Nvidia is a bad Linux actor

* user knows Nvidia only supports buggy blobs

* user may even know Nvidia is bad to people trying to unblob the blobs

* user already went through the trouble of doing what it takes to get the bad Linux Nvidia blobs to work to play games on their machines

* user notices that the bad buggy Linux Nvidia blobs fail to work _at all_ with Wayland

* user is understandably _even more frustrated_ than they were before. So they ask you-- a Wayland person-- how can it be _even worse_ for them now when they've already been generating much more complex and power-hungry graphics with their buggy blob than they'd ever do with Wayland.

If you're representing Wayland, this problem is your problem whether you want
it or not. Perhaps the answer is to make the protocol worse so the the Nvidia
user doesn't remain eternally maximally frustrated. Perhaps the answer is that
isn't possible and you're stuck in the same boat as the user. Perhaps it means
you start a hunger strike or gather thousands of devs to protest outside
Nvidia's headquarters until they improve. I have no idea.

But _please_ don't do that FLOSS thing where all the devs on a project teach
each other to sync on, "Sorry Mario, but your princess is in another castle."
That pattern becomes it's own problem and can quickly end up discouraging
development even from potential devs who don't care at all about Nvidia
support.

> Wayland doesn’t support screenshots/capture!

What is the current UX for screenshotting, screencapture, and screencapture
with audio for the most featureful DE that uses Wayland atm? Is there a
program out there that offers push-button access for these three features
(choosing the most sensible default format in each case)?

~~~
Sir_Cmpwn
>There is a very high likelihood that when a user complains about Wayland
support for Nvidia they mean this

As the actual person who receives these complaints... this isn't true. Once
it's explained, though, the users still stick around and get angry because
they made dumb, uninformed choices as a consumer and think it's our fault.

>If you're representing Wayland, this problem is your problem whether you want
it or not.

It's not. We can just choose not to solve it. Use X and buy smarter when the
next harware upgrade comes around, or wait until your hardware is supported by
nouveau if you don't want to upgrade any time soon.

>What is the current UX for screenshotting, screencapture, and screencapture
with audio for the most featureful DE that uses Wayland atm? Is there a
program out there that offers push-button access for these three features
(choosing the most sensible default format in each case)?

I don't really know what the situation is for more noob-friendly DEs like
GNOME, but on sway this tool is the i3-equivalent of push-button simplicity:

[https://wayland.emersion.fr/grim/](https://wayland.emersion.fr/grim/)

Push-button screen capture isn't there yet.

~~~
7e
"the users still stick around and get angry because they made dumb, uninformed
choices as a consumer and think it's our fault."

If this is the attitude of Wayland developers, it goes a long way towards
explaining Wayland's ten year road of non-adoption.

~~~
roenxi
You phrase that as though there is a real choice here. There is not. The open
source community has had experience with how to interact with closed source
drivers since the Linux 0.01 in 1991 and that experience screams "don't do
it". Xorg has been a technical disaster for more than a decade; I have
sympathy for the people who want to use Nvidia cards, but they are going to
have to use X.org and like it anyway because that is all Nvidia supports.

Attempting to run a project based on the opinions of a group of Nvidia devs
who (1) don't care about your project and (2) don't care about your goals is
technical madness. It took the kernel more than a decade of stubbornness
before all the other device driver writers caved and supported decent design.
As far as I recall Nvidia is literally the last major device driver who
refuses to play ball with open source. If Nvidia users can't use Wayland for
driver reasons that is because of _Nvidia 's_ choices and there isn't anything
the Wayland devs can do without repeating all the mistakes of X.org.

If it takes another decade before Nvidia caves and behaves like a good
corporate citizen then that is a decade well spent by the Wayland devs. Long
term maintainability will eventually trump short term user issues; just like
it did for wifi et al. It is unfortunate Nvidia is making their user's lives
hard, but the writing has been on the wall since AMD started open sourcing
their driver stack in the 2008 era.

~~~
pjmlp
Android and ChromeOS show it is possible to have it other way when FOSS
religion doesn't stand in the way.

~~~
xorcist
Android shows _exactly_ what that would look like: You get a blob-like
kernel/stdlib/driver package from your vendor, then build your operating
system around that and never speak about it again because it's brittle mess of
good enough.

The only reason Google and a few big players can ever ship updates is by
playing hard with those vendors, and negotiating upgrade paths in advance.
Nobody is interested in doing that for the desktop.

~~~
pjmlp
Exactly the example of the FOSS religion I was talking about.

Game devs just want to put shinny pixels on the screen, no one cares if it is
a blob or not.

AMD is open source and there is hardly any advantage, X routinely crashs,
doesn't provide support for the GPUs that were dropped from the rebooted
driver, being stuck with fewer capabilities than fxgl.

Hollywood studios are quite happy with NVidia drivers.

------
dooglius
> So in short, people asking for Nvidia proprietary driver support are asking
> the wrong people to spend hundreds of hours working for free to write and
> maintain an implementation for one driver which represents a harmful force
> on the Linux ecosystem and a headache for developers trying to work with it.
> With respect, my answer is no.

Interestingly, this is more of an indictment of Wayland than anything in the
article that's being "debunked". I don't dispute that it is difficult work,
but you'll have to choose between making a viable X replacement, and dying on
this particular hill.

~~~
Sir_Cmpwn
Wayland is flourishing - everywhere except among Nvidia proprietary driver
users. In reality it's them who are dying on their hill, left behind on crappy
old software.

~~~
gpm
No, in reality desktop Linux, including wayland, is floundering. This is
contributing to that floundering by splitting the effort, create an
environment filled with vitriol on both sides, making it harder for things
like games to say they support the set of things called "Linux", etc.

~~~
ddevault
I'm not here to make Linux succeed. I'm here to make good software. Users who
know better will use Linux and users who don't won't. Either way Linux will
keep on trucking, as it has for a very long time. It shows no sign of
stopping.

~~~
rayiner
Given that Wayland still doesn't properly support remote desktop, a feature
that has been working continuously in Windows for decades through tons of
graphics model changes, I'm not sure I'd play the "users who know better"
card.

------
shmerl
_> There are two approaches to this endorsed by different camps in Wayland:
these Wayland protocols, and a dbus protocol based on Pipewire._

Pipewire approach looks the best for screenshots and video recording. I hope
all Wayland compositors will settle on it.

 _> Secondary clipboard support <...> wp-primary-selection_

I guess the standard is very recent. Last time I tried, KWin didn't support it
yet.

 _> We fought long and hard over this and we now have a protocol for
negotiating client- vs server-side decorations, which is now fairly broadly
supported, including among some of its opponents._

A major problem with Mutter remains. Mutter developers don't want to depend on
GTK for whatever reason, but so are SDL, mpv and other non-GUI applications
and toolkits developers. The result are ugly looking windows for such cases in
Gnome.

 _> You have to step up, though: no one working on Wayland today seems to
care._

It's a problem with Wayland in general. The end user gets the short end of the
stick, since with removal of some functionality that was in X, some use cases
are cut off. But there is no one player like with X server. Tons of
compositors are developed by different people. So even raising the issue let
alone coming to some consensus takes a very long time.

I'm not saying Wayland isn't the way to go, just pointing out it's a very hard
transition.

 _> Wayland doesn’t support Nvidia!_

How is the progress of using Vulkan for Wayland compositors and avoiding the
whole EGLstreams mess?

I see this: [https://github.com/KhronosGroup/Vulkan-
Docs/issues/294](https://github.com/KhronosGroup/Vulkan-Docs/issues/294)

But it's not clear from it whether now there is a way to avoid using GBM or
EGLstreams.

~~~
Sir_Cmpwn
The problem is that it requires dbus, which not everone is on board with. Our
argument is that the Wayland compositor should speak the Wayland protocol.
That being said, the software I mentioned can be used to bridge between the
two camps.

Following your edit: yes, the new standard protocol for primary selection is
very new. But everyone supports the GTK protocol and the transition will not
be visible to users.

Dude, so many edits: "But there is no one player like with X server" -> this
player is wlroots

Oh my god man, stop editing your comment: "How is the progress of using Vulkan
for Wayland compositors and avoiding the whole EGLstreams mess?" -> hard to
say now, it's very very early.

~~~
shmerl
Thanks for answering :)

 _> this player is wlroots_

One of the players still, since for example KWin isn't using it. I.e. it
unfortunately came too late to unify the situation.

~~~
Sir_Cmpwn
A strong majority of Wayland compositors are using wlroots. Those that don't
are in the minority, but they are mostly cooperative with wlroots aside from
GNOME and E.

~~~
Twirrim
Isn't GNOME the biggest single desktop by market share?

~~~
shmerl
Only because Ubuntu users started implicitly using it. KDE looks more popular
among those who are explicitly choosing a DE.

~~~
Spivak
But how do you know if someone explicitly chooses GNOME when it's the default?

~~~
shmerl
Looking at GOL stats for example, Gnome usage grew when Ubuntu switched from
Unity to Gnome (on roughly the amount of Ubuntu users). Before that, KDE had
higher usage overall. So my conclusion is that Gnome's majority today can be
driven by implicit Ubuntu's choices.

------
microcolonel
> _Things like sending pixel buffers to the compositor are already abstracted
> on Wayland and a network-backed implementation could be easily made. The
> problem is that no one seems to really care: all of the people who want
> network transparency drank the anti-Wayland kool-aid instead of showing up
> to put the work in. If you want to implement this, though, we’re here and
> ready to support you! Drop by the wlroots IRC channel and we’re prepared to
> help you implement this._

Somebody has actually done this!

Erik De Rijcke put together Greenfield [0], which is a Wayland compositor that
relays surfaces with H.264 or JPEG over WebRTC. It is exactly as cool as it
sounds, and it seems like it actually might work pretty well. It's the sort of
thing that could be standardized, with a bit of work.

[0]:
[https://github.com/udevbe/greenfield](https://github.com/udevbe/greenfield)

------
pmoriarty
There are a number of counter arguments to the parent article in _" Why I'm
not going to switch to Wayland yet."_[1]

On the subject of leaving the responsibility of taking screenshots to the
Wayland compositor:

 _" for simple things using the compositor's screen shot tool is fine. But
what if I don't like the screenshot tool for my compositor of choice? My
experience with the GNOME screenshot tool (granted this was pre-wayland) was
that it wasn't as good as, say, shutter, which has a lot of options, let's you
easily crop and edit the screenshot from inside the screenshot tool etc. And
then swaygrab doesn't even (currently) have an option to capture a rectangular
region."_

There are some other things _" Why I'm not going to switch to Wayland yet"_
mentions which are important to me, like Wayland's lack of color picker tools
and xdotool functionality.

The parent article says:

 _" Wayland doesn't have network transparency! This is actually true! But it's
not as bad as it's made out to be. Here's why: X11 forwarding works on
Wayland. Wait, what? Yep: all mainstream desktop Wayland compositors have
support for Xwayland, which is an implementation of the X11 server which
translates X11 to Wayland, for backwards compatibility. X11 forwarding works
with it! So if you use X11 forwarding on Xorg today, your workflow will work
on Wayland unchanged."_

So why wouldn't I just use xorg to begin with?

Overall, Wayland just seems immature to me, and not a viable competitor to
Xorg, which has had all of this functionality for decades. As an Xorg user, I
really struggle to come up with compelling reasons to switch.

[1] -
[https://old.reddit.com/r/wayland/comments/85q78y/why_im_not_...](https://old.reddit.com/r/wayland/comments/85q78y/why_im_not_going_to_switch_to_wayland_yet/)

~~~
Sir_Cmpwn
> _screenshot quote_

I addressed this in my article, please read it. And you can select a
rectangular region on sway today, using tools which are portable across many
Wayland compositors.

>So why wouldn't I just use xorg to begin with?

You can, no one's stopping you.

------
jchw
Personal criticism: it's not FUD if it's correct. A lot of the things the
author concedes are actually limitations, even if not inherent (did anyone
ever claim that?) are reasons I can't use Wayland or at least would be
massively inconvenienced.

------
meditate
Hey Drew (and other contributors), thanks for all your work on this, I
switched from i3 to Sway last week and everything has been quite stable. My
only gripe has been that screenshotting/screencasting apps can only pull from
fullscreen and can't capture from a window yet. The portal APIs seems to
support this but the wlroots protocols only allows export from composited
outputs, not from un-composited wl_surfaces. Hope this gets some love soon.

~~~
Sir_Cmpwn
Sway is a do-ocracy. Get in there and do it! It's not as hard as you think.

~~~
meditate
I am aware that I may be the one who ends up implementing that :)

------
ubercow13
How would something like Easystroke [1] need to be implemented for Wayland?
Would this have to be inside the compositor as it's like a global hotkey?

[1]
[https://github.com/thjaeger/easystroke/wiki](https://github.com/thjaeger/easystroke/wiki)

~~~
Sir_Cmpwn
Yes, this would have to live in the compositor, or suitable protocol
extensions would have to be developed and implemented.

~~~
ubercow13
How would you invisage it being implemented in sway for example? It's quite
esoteric to be maintained along with a minimalistic compositor like sway, and
moreover it probably requires a GUI for configuration. Would a PR implementing
it be accepted?

~~~
Sir_Cmpwn
It's probably just not a feature we'd support at all in sway.

------
znpy
I am really unstatisfied about the status of remote desktop session on
GNU/Linux and other unices in general.

RDP on Windows works amazingly, it's really like having your remote machine at
your fingertips (as long as network holds).

On GNU/Linux on the other hand, most solutions are hacky or cumbersome or non-
standard or a linear combination of the previous adjectives.

I really wish I could have truly good remote desktop support on GNU/Linux.

~~~
bscphil
Have you ever tried X2Go? I've used it a few times and it's been incredible -
instant feedback exactly how you describe RDP.

There's also just regular old rdesktop, which seems to work pretty well if
you're mostly connecting to Windows servers.

~~~
znpy
Yes I've tried X2Go and rdesktop with xrdp. Meh.

X2Go was cool and worked well, but support for various distro was a bit
unclear (only Ubuntu? can't remember, that was like four years ago) as unclear
was on which condition you could actually resume your session and how (what if
I disconnect unexpectedly? how do I list my current sessions? Is there audio
in/out forwarding? clipboard sharing?). The website homepage failed to address
many of these questions, ultimately failing to answer the question "can I
_actually_ rely on this thing?".

------
alexandernst
IMHO hotkeys is something basic. I understand Wayland is being designed with
security in mind, but Wayland developers must understand that what they're
trying to do is to, ultimately, create an X replacement. And X is, mainly,
user-oriented.

You can't have a graphical, user-oriented, server and tell the user to "hey,
just use a shell script and a control binary, and then hook a hotkey into your
window manager and make it run that script". That's just not how user
friendliness works.

Try to find a common ground between Wayland being secure and Wayland being
practical.

~~~
ben0x539
I think the wayland devs aren't focusing on replacing absolutely everybody's
X-based workflows, but on providing a reasonably engineered component that
integrators can build a desktop environment on top of. In practice, we'll
probably get a distro shipping a self-contained DE with a centralised hotkey
setup, and I expect that will do the job for the vast majority of users. Maybe
someone else is building a phone OS and using wayland for the graphical bits
and the hotkey thing isn't even going to be on their radar.

~~~
alexandernst
But why does every single DE has to reinvent the wheel with hotkeys? Why can't
we have that provided by Wayland? (or maybe by libhotkey, if you wish). Why so
much effort in replicating the same functionality over and over must be wasted
in the entire linux ecosystem?

~~~
veqz
Not ever single DE, but the Compositor a DE uses must have it implemented.

Though Compositors may share libraries as well, and a unifying library might
very well be developed for this.

------
pmontra
My current showstopper with Wayland is that no screensharing application works
with it: Skype, Meet, TeamViewer. I need them to work with my customers so I'm
staying on Xorg until that gets implemented.

~~~
zaro
Same here. If Skype and Chrome screen sharing worked in wayland I am switching
to wayland right away, as it seems everything else works well.

------
gyger
I never understood this complains? The main use cases work, I have almost
never found a Linux user that was unhappy with Wayland. Once a while a power
user, but that one is smart enough to install X if he needs a special
functionality.

I never had a problem, and if you upgrade the next time, check the hardware
compatibility and buy what you need. Till then, just run a X stack.

------
thinkmassive
Wayland doesn’t support full-screen sharing, for example in Google Meet (aka
Hangouts). Hopefully this is fixed soon (via dmabuf-export, mentioned in the
article) but until then (and for the past couple years) it’s a major hassle
for a lot of people who had Wayland forced onto them by their desktop
environment. Even if this isn’t Wayland’s fault they would be wise to assist
with a fix soon.

------
shmerl
Regarding gaming by the way. XWayland works quite well for it already (it's
critical since Wine for example still requires X and many older games depend
on X as well), but there seems to be some issue with radv at present which
requires setting explicit number of back buffers to avoid capping that
disregards vsync settings:

[https://github.com/doitsujin/dxvk/issues/806](https://github.com/doitsujin/dxvk/issues/806)

If games are using SDL, you can also select Wayland using
SDL_VIDEODRIVER=wayland. But there are some glitches still. I tried doing it
for example with ScummVM, and it produced double cursor.

------
macintux
Related ongoing discussion:
[https://news.ycombinator.com/item?id=19127762](https://news.ycombinator.com/item?id=19127762)

------
josteink
Great write up. That said I found the section about nvidia drivers confusing.

> All three are necessary for most Wayland compositors. Only the first two are
> implemented by the Nvidia proprietary driver.

Ok. But what about nouveau? Is nvidia supported using the open-source drivers
(the only ones I will use) or are these drivers too lacking?

Are the wlroots developers _completely_ disregarding nvidia-support over
issues only found with the proprietary drivers, or are there actual unworkable
nvidia issues regardless of driver used?

~~~
hsivonen
The Ubuntu 18.04 Gnome Wayland session works well on nouveau. (I've used one
consumer card from 2010 or so and a pro card from 2013 or so. Also tried a
newer pro card that nouveau didn't support, regardless of Wayland. In that
case, the easiest solution was to remove the card and buy AMD.)

~~~
heavenlyblue
Nouveau does run under 1080gtx ti, but I’ve got a weird setup with 3x4K
screens, so the driver needs to increase the GPU clock and it fails as that is
a part of the proprietary blob.

So it should work with most of the setups until you’re trying to reach a
certain performance threshold.

------
ben0x539
What's the status for global push-to-talk for voice chat apps like Discord?
Does that also fall under hotkeys/"no one working on Wayland today seems to
care"?

------
SCdF
> Wayland can be keylogged, assuming the attacker can sneak some evil code
> into your .bashrc

I’m not sure what scenarios are being invisioned here, but isn’t that
absolutely something a nefarious app could do, because the app will be run as
you, and you have write access to your bashrc?

As an example, since it’s fresh in my memory, if the folks who put dodgy
cryptocurrency stealing code into npm packages had instead put this keylogger
in there, that would have worked right? You run npm install, npm runs as you,
the package runs as you, the package updates your bashrc.

~~~
Sir_Cmpwn
Yes, but that package could also do all sorts of other things, like encrypting
your ~ and demanding ransom. It's not Wayland's problem to solve this -
sandboxing is a separate matter. Wayland makes it easier to sandbox graphical
applications but it is not a complete sandboxing solution.

------
johnchristopher
Has wayland been released yet ? Does it still freeze the whole gnome desktop
when dragging a Firefox tab from one window to another (asking for a friend) ?

~~~
Sir_Cmpwn
Wayland the protocol was released a long time ago. Wayland implementations
like GNOME are in varying states of completion. I don't know about GNOME in
particular, but my compositor - sway - is shipping 1.0 within the next month
or two.

~~~
johnchristopher
> [https://swaywm.org/](https://swaywm.org/)

Looks good ! Do you think fancy animations and tiling could be done (wobling,
fading and swiping effects when switch from one pane to the other, etc.)?

~~~
Sir_Cmpwn
We're not interested in those for sway, but we work with a project called
wayfire via wlroots that you may be interested in:

[https://wayfire.org/](https://wayfire.org/)

~~~
victornomad
I saw wayfire last week and looks cool, a bit of compiz/beryl revival on
wayland :)

I think sway is prety nice as it is but I would love to see a few things to
make it feel "modern"

    
    
      - round borders
      - simple drop shadows
      - a way to add small effects when opening/closing/selecting windows. 
    

I was wondering how difficult would it be to allow run custom shaders on those
actions. So for example one could implement very easily fade in/outs, gray out
all the windows except the selected, and custom effects, etc... just adding
something in the config file like on_selected_glsl: 'path_to_fragment.glsl
(unixporn community would love it :)

Anyway, I'm pretty happy on the current state, so thanks for the amazing work
:)

~~~
Sir_Cmpwn
[https://github.com/swaywm/sway/issues/3652](https://github.com/swaywm/sway/issues/3652)

------
sosodev
I've been using Sway on my laptop recently and it's been a great experience.
It looks great (easily customizable) and runs smooth.

------
darkpuma
Wayland is a great demonstration that not _all_ change and deviation from
tradition in met with vitriolic anger from the linux community (as has been
asserted). Wayland meets its fair share of skepticism, but it seems cool heads
prevail and the situation stays civil. This gives me confidence in the
maturity of the community and the long term viability of Wayland.

~~~
peatmoss
I wonder if some of the ire was bled off by Mir? I mean, when Canonical
announced Mir, people mainly responded with anger that they weren’t
contributing to Wayland which was a longer-standing attempt to replace X11.

~~~
darkpuma
That's an interesting hypothesis, I hadn't considered that.

------
malvosenior
> _So in short, people asking for Nvidia proprietary driver support are asking
> the wrong people to spend hundreds of hours working for free to write and
> maintain an implementation for one driver which represents a harmful force
> on the Linux ecosystem and a headache for developers trying to work with it.
> With respect, my answer is no._

I don't see how Wayland can succeed without supporting Nvidia. Yes, they'll
have to write several thousand more lines of code, but if you're going to make
a desktop environment in 2019, you're going to have to put in that effort to
support the graphics card that most people have. It would be great if Nvidia
had better Linux support! But they don't and washing your _desktop platform
's_ hands of the issue just makes the whole project DOA.

Are there any competitors to Wayland that don't take a hard-line stance
against supporting the most popular and most powerful graphics cards in the
world?

~~~
Sir_Cmpwn
Nouveau works. Use it instead.

Also: it's possible to have a definition of success which excludes users of
the proprietary driver. We don't have the same value system.

>the [...] most powerful graphics cards in the world?

Citation needed? And the highest of the high end graphics cards are excessive
vanity most of the time, you don't need the tip-top to play any modern game at
any settings you want.

~~~
addisonj
Your work on sway and wlroots is phenomenal, but I feel like there is quite a
gap here in terms of why people are concerned about Nvidia support.

Yes, Nvidia are not great when it comes to OSS, but like it or not, for doing
real work in ML, scientific computing, or video and photo editing, Nvidia with
CUDA is simply a much better experience and much more broadly supported.

While I don't think it should be the job of wlroots/sway to fix Nvidia's less
than ideal driver chain, I think it is important to remember that a lot of
people get a lot of productive work done on with Nvidia cards and would love
to get rid of some of the pain of X while still being able to use their high
end GPUs for both work and graphics.

It seems fairly clear with with MacOS focusing less and less on high end
machines, there is a gap for high end unix workstations and hopefully desktop
Linux can fill that gap, but right now that likely means Nvidia support... I
think the best answer is just to buy amd and market forces will get Nvidia to
change, but that still doesn't mean everyone can just go that path right now
to get their day job done.

~~~
Sir_Cmpwn
>Yes, Nvidia are not great when it comes to OSS, but like it or not, for doing
real work in ML, scientific computing, or video and photo editing, Nvidia with
CUDA is simply a much better experience and much more broadly supported.

Fine. If you do these things, stay on X.

>While I don't think it should be the job of wlroots/sway to fix Nvidia's less
than ideal driver chain, I think it is important to remember that a lot of
people get a lot of productive work done on with Nvidia cards and would love
to get rid of some of the pain of X while still being able to use their high
end GPUs for both work and graphics.

I honestly just don't care. They should boycott Nvidia and find something else
to do with their time if they really want better support from Wayland. I'm not
going to bend over for Nvidia. Ever.

~~~
addisonj
Nor do I think you should, my only point is to say that people's FUD about
Wayland often has roots in FOMO about not being able to use the new and shiny
for their workflow and no clear path to when/how that will be fixed,
regardless of whose "job" it is to fix the problem.

The people who demand change are wrong too, I am super happy people like you
are doing what you do, otherwise this OSS thing really would never work.

But to be clear, while I think your stance is completely reasonable and
justified, it is just a hard pill for some people to swallow. That doesn't
mean that those who are jerks about it are justified, but it also doesn't mean
that those who raise concerns, that those concerns aren't warranted.

------
zbuf
I heard that in a world based on the Wayland protocol, applications implement
the window decorations.

If so, I'm interested in how we can expect consistency; and eg. moving the
window of an unresponsive application.

This could well be a misconception, which is why now seems a decent time to
ask.

These seem to be good qualities of X. Wayland has been a number of years in
the making, so I have somewhat lost track of my source of this information.

Edit: Apologies, I did read the fine article. It appears I must have skipped a
section.

~~~
Sir_Cmpwn
See discussion about "server-side decorations" in the article.

------
amelius
Does Wayland support ripping of DRM'ed video streams?

~~~
floatboth
Most compositors don't support DRM (that kind) at all (yet), only recently
there was a protocol extension published + a merge request for Weston + I
guess something on the driver side?

------
de9xvnh7
Most of the answers are either "well that's true, the protocol doesn't allow
it, but implementations do it in non-standard ways" or "we are working on it"
or "oh this is not a problem with Wayland, see, Wayland is just a protocol".
i.e. at least half of the criticism, as of today, is still practically true.

~~~
Sir_Cmpwn
You can't even open application windows on Wayland without a protocol
extension.

The core Wayland protocol doesn't do these things by design, but that doesn't
mean end-users can't do them on Wayland compositors which support these use
cases in the places that they're designed to be supported.

~~~
de9xvnh7
The end user doesn't care about protocols or compositors. The end user wants a
system that can replace Xorg and do the same or even a better job. And, as of
today, Wayland fails miserably at that.

~~~
ddevault
>The end user doesn't care about protocols or compositors

Which is _why they shouldn 't care that the core Wayland protocol doesn't
implement it_. These use cases WORK!

