
Why don't we have Wayland on Raspberry Pi yet? (2018) - bpierre
https://joshondesign.com/2018/03/26/linux_graphics_state
======
mwfunk
I enjoyed the article but this quote jumped out at me: "What took thirty years
to build isn't going to be replaced in a day." This was in regard to replacing
X11 with Wayland. It's funny because it would be closer to the truth to say
that X11 took 5 years to build, and for the last 25 years everyone has been
trying to get off of it, but in the meantime piling more stuff on top of it
since that's easier than starting from scratch. 25 years ago there were people
saying stuff like, "I wish we had something else, but this is what we're stuck
with, and it's just too much work to make a new window system, so let's just
add another protocol extension."

So we're already 25 years into trying to replace X11, which is already far
longer than the period of time in which it was being designed and actively
developed on a foundational level. There's got to be some good lessons learned
in all of this about software lifecycles or getting it right the first time or
knowing when to move on or OS development by way of mailing list consensus. I
totally get why it's still used after all these years, it performs an
essential task- but I bet the original creators would be the ones most shocked
that it's still a thing in 2019.

~~~
0xfaded
I've been reading through the Vulkan spec, which is in way similar in that
OpenGL has been extended since its introduction in 1992 with more and more
features to support new graphics capabilities as they evolved.

I've seen Vulkan called the successor to OpenGL, but reading the spec it seems
more like the end game for raster graphics card programming. OpenGL 4.0 was
released in 2010, and since then changes have been incremental. We more or
less have figured out how to do raster graphics (ray tracing may be a
different story), so it made sense to invest tens (hundreds?) of millions of
dollars to develop the Vulkan spec, and then many millions more to implement
it.

What other technologies are there were we are more or less at the end game? I
know Qt5 widgets is considered feature complete for desktop apps.

~~~
DonHopkins
Photoshop pretty much got it right a couple decades or so ago, and they've
just been porting it, smearing on new lipstick, and figuring out how to make
more money with it ever since.

~~~
ocdtrekkie
I would argue that this is true of most of Microsoft Office as well. When did
they really add a new feature to PowerPoint that you had to have?

And it's no surprise both Adobe and Microsoft have pushed people towards a
subscription model for this software: Nobody in their right mind would pay for
upgrades otherwise. Arguably Office you need every ten years to ensure you
have security updates because of the amount of foreign content you process
with it, but Adobe? Psh.

~~~
NullPrefix
Don't know when it was added, but I recently found out that you can have
multiple synchronized Word windows of the same document.

~~~
DonHopkins
On different people's screens?

~~~
Someone
Yes (in Office 365, in your browser). See [https://support.office.com/en-
us/article/collaborate-on-word...](https://support.office.com/en-
us/article/collaborate-on-word-documents-with-real-time-co-
authoring-7dd3040c-3f30-4fdd-bab0-8586492a1f1d)

------
hyperion2010
Wayland was designed to solve a very specific set of use cases and nothing
more. The number of times I have read "wayland doesn't do that" or "that's not
wayland's job" or "wayland is just the compositor" are telling. Of course a
stack that is compositor + windowing toolkits is going to miss countless
mission critical use cases in countless workflows, not to mention that it is
an even further regression from composability in the window manager space and
no, dbus is not the answer either, you can't make literally every program
depend on dbus just to be able to do simple things like take a screenshot, or
automatically rearrange windows. Every program having to use a toolkit or
implement a message passing system themselves will never happen because few
developers have the expertise needed to do so. This is in part why things like
X11 were created in the first place, so that there could be separation of
concerns. Wayland stomps all over that and thus doesn't even offer something
that could become a defacto standard, so it seems that X11 will continue to
live on.

~~~
emersion
What are your use-cases not addressed by Wayland?

The sway compositor has been standardizing protocols for screenshots, screen
recording/streaming, composable desktop components and so on.

~~~
lone_haxx0r
Just wait until everyone else creates their own standard protocols.

~~~
p2t2p
Nah, those protocols are also implemented in wl-roots which is the foundation
of virtually every single wayland compositor, otherwise you'd have to write
50+k of lines of code yourself.

~~~
wander_homer
Only if you ignore the most widely used Wayland compositors on the desktop,
Mutter and Kwin. I doubt all compositors built upon wlroots come even close to
the user bases of those two.

------
ChuckMcM
I totally feel this guy's pain. When I started at Sun there was a 'direct to
framebuffer' window system which we called "Suntools" It was fast and pretty
much all in the kernel and pretty awesome, except this new thing "X11" allowed
you to have a big beefy machine (sort of a Raspi 3 equivalent today :-)) with
its fans and noise in some machine room while the display and input was on
your desk. There were even people who made things they called "X terminals"
which were instant on devices that provided the display, mouse, Etc. Sun
switched over to X11 and the UNIX windows wars began.

When the SparcStation I came out, I backported Suntools to its frame buffer on
a lark and it was _screaming_ fast. That was pretty fun.

Oddly enough, I still use X11 a lot. I have probably half a dozen ARM systems
around my office/lab doing various things, and it is simpler to run an X11
client locally and just kick off an xterm to these machines than it is to try
to do some sort of KVM nonsense. It is also more capable than running a web
server on the Pi and trying to interact with it via web "application" pages.

Oddly enough, I recently (like about 6 months ago) became aware of "KVM over
IP" which, believe it or not, you hook this piece of hardware to the display
port (or HDMI) and the USB port, and it sends the video (and HDMI audio), out
over the network to a purpose built application on a remote system. Wow,
sounds just like X11 but without the willing participation of the OS vendor
:-).

The point I'm trying to make is there absolutely is a need for both. A direct
to the metal way of cutting out layers and layers of abstraction so that you
can just render to the screen in a timely way, _with support for UI features._
(otherwise we'd just program to Unity or Vulkan and be done). But their _also_
needs to be a standardized way of letting "well behaved" programs export their
graphics and I/O across the network to a place more convenient for the user.

Arguing passionately for one use case at the expense of the other doesn't move
the ball down the road. Instead it just pits one chunk of the user base
against the other half.

~~~
DonHopkins
Funny you'd mention that: I was just comparing a Raspberry Pi 3 with a 1990
SS2, which totally skunks it 86:1!

[https://news.ycombinator.com/item?id=19717416](https://news.ycombinator.com/item?id=19717416)

>How many more times faster is a typical smartphone today (Raspberry Pi 3:
2,451 MIPS, ARM Cortex A73: 71,120 MIPS) that a 1990 SparcStation 2 pizzabox
(28.5 MIPS, $15,000-$27,000)?

Remember "2^(year-1984)"?

[https://medium.com/@donhopkins/bill-joys-
law-2-year-1984-mil...](https://medium.com/@donhopkins/bill-joys-
law-2-year-1984-million-instructions-per-second-3a8c92165cfe)

On Nov 8, 2018, I sent Bill Joy a birthday greeting: "Happy 17,179,869,184
MIPS Birthday, Bill"! (2 to the (year - 1984))

------
mrlambchop
Woah - a huge flash to the past when I read this.

I ported Wayland to VideoCore4 (the multimedia engine in first Pi chip) back
in 2011 - it was part of the Meltemi Nokia project that got cancelled the
follow year - shame as it was pretty cool and had half a chance IMO. We worked
with the team in Oslo on QT acceleration over GL ES and used EGL below Wayland
(coupled with some magic APIs to get the VideoCore HVS to work well). Ported
this to an ARM combo chip that had just the VideoCore GPU in it as well (no
HVS) - it worked pretty well.

Prior to this however, I made a VideoCore demo that used a PCI bridge chip
(from Broadcom) and you could plug it into a Dell laptop running Ubuntu and
get accelerated video decode and also X11 window scaling working at 60fps. We
nearly sold this into Apple for accelerating their macbook's but IIRC, getting
the macbook into low power mode whilst the video was playing on the external
chip was going to be soo much work that they gave up.

A even further back, I remember validating the HVS hardware block and writing
the initial scaler driver for it (IIRC, scaler.c...) and made a dispman2 port
for the driver. Circa 2006!

Great team - one of the most enjoyable set of people to work with I've ever
come across.

~~~
mycall
If you connected with Eric Anhold and worked on this, you would help millions
of Pi students and users. It is an opportunity.

~~~
mrlambchop
I checked out Eric's work just - he's doing an amazing job! Much more thought
put into the subject (security for GLSL being a huge topic on its own). The
lack of MMU in the VC4 architecture is a huge pain point that probably sucks
up most engineering cycles when it comes to arbitrary application environments
using GPU resources like X11 or Wayland - when memory runs out, what to do?
You can throw engineering resources at it, but engineering talent really needs
access to VMCS on the VideoCore side todo any worth while work.

When we ported Android to the VC4 architecture the first time (~2010), the low
memory killer in Linux was subverted to understand to kill Android
applications based on their use of the VideoCore GPU memory and it worked
pretty well, yet it would still close the primary running app once in a while.
Run monkey over Android and all hell broke loose - really tough situations to
defensively code fore. For example, for CX reasons, you had to ignore some
GLES errors in the primary client due to low memory, then the system had to
kill another application that was using the memory, then it would kill the EGL
context for the primary application so it would refresh the entire app
lifecycle using an almost suspect code path inside Android. Good times!
Imagine Wayload has very similar challenges for normal desktop use.

~~~
stefan_
The open source driver doesn't use VMCS, it instead puts aside a fixed block
of memory (typically 256 MiB, which I think is also a limit due to some
hardware bugs) for use through the Linux Contiguous Memory Allocator (CMA)
that it then draws from.

VMCS only comes into the picture if you use video decode, but I think Dave
Stevenson from the foundation hacked the firmware side to support importing
Linux allocated memory blocks into VMCS so that you can do zero-copy decode
and import into EGL (or more likely HVS, the EGL support for the formats is
pretty limited).

(I really liked the design of the HVS - having pretty much scripted planes is
a fresh approach over similar hardware blocks that have a fixed number of
planes each with own idiosyncracies and limitations)

~~~
mrlambchop
The HVS was a cool design - the only real issue if I recall was its limited
line buffers meaning it was hard to determine what could be composited in real
time, so we ended up always rendering to a triple buffer. It also did some
amazing scaling in realtime, but this came with some crazy artifacts that were
super painful to triage. The occasional "flash of bad pixels" in a live
composition screen was really painful. I just remember I wrote the DPI and CPI
peripherals that we brought up the HVS with - on a 4MHz FPGA complex, we had
YUV camera input scaling up to a WVGA DPI screen running at 60fps on a
distributed FPGA platform through the HVS. Fun times.

------
pantalaimon
I think the author is confusing something here

> The reference implementation of the protocol (Weston and it's associated
> libraries) is written in C. That means you could wrap the C code with Rust,
> which several people have done already [1] However, I get the impression
> that the results are not very 'rustic', meaning it's like you are coding C
> from Rust, instead of writing real Rust code.

> To address the problems of dealing with the existing native Wayland
> implementations, a couple of the Rust Wayland developers have joined
> together to build a new Wayland implementation in pure Rust called wlroots
> [2]

[1] [https://github.com/Smithay/wayland-
rs](https://github.com/Smithay/wayland-rs) [2]
[https://github.com/swaywm/wlroots](https://github.com/swaywm/wlroots)

wlroots is written in C whereas wayland-rs - a Rust implementation of the
wayland protocol (client and server) is written in - Rust.

I'm not familiar with either project, but this just stood out immediately when
looking at the Github pages.

~~~
Sylos
There's also wlroots-rs, which provides safe Rust bindings for wlroots:
[https://github.com/swaywm/wlroots-rs](https://github.com/swaywm/wlroots-rs)

But yeah, you would still need the C toolchain with this.

------
cbdumas
I've been using swaywm on my laptop (XPS 13) with XWayland disabled for a few
months now and have had very few problems with it. As far as I can tell
Firefox works perfectly, except for some very strange behavior if I try to
enable hardware acceleration.

I love how easy it is to configure via config files, external monitors work
great, scaling on HiDPI displays has been totally painless. My days off
fiddling with xorg config and xrandr are behind me.

I know the creator of sway hangs out here, so if you're reading this, thank
you!

~~~
michaelmrose
Without hardware acceleration doesn't watching video in the browser pretty
much destroy your battery life and use most of your cpu time?

~~~
cbdumas
So I'm no expert but I believe there are actually two different notions of
hardware acceleration at play here:

1) HW accelerated rendering in Firefox, which despite being unfortunately
disabled by default on linux can in my experience be enabled (on about:config)
without issues. This makes the experience of scrolling much smoother, so I
usually do that. I don't think this has any observable effect on battery life
for me. However, enabling this in Sway results in some very odd behavior that
breaks certain things so I've had to disable it. I can go into more detail on
that if you like.

2) Hardware accelerated video decoding. In contrast to the fist one, this
makes a HUGE difference in CPU usage and battery life. However this
unfortunately cannot be used in any browser AT ALL in Linux, regardless of
setup or configuration. The way I watch youtube videos on my laptop is usually
with mpv, which does use hw decoding if it is configured to do so.

~~~
aeroevan
I've used chromium-vaapi on Linux with some success. I don't think those
patches have been accepted in upstream chromium though.

~~~
cbdumas
I may give that a shot, although I think chromium still requires XWayland,
right?

------
Sir_Cmpwn
This article seems to be mixing up languages, which others have pointed out
but not in full.

wayland-rs does not wrap libwayland, but instead offers a pure Rust
implementation of the Wayland protocol.

Sway and wlroots are both written in C, but wlroots-rs is a project which
wraps the wlroots C library in a Rust wrapper.

There are currently no mature Wayland compositors written in Rust.

Also, this article mainly focuses on the problems with Wayland on the
Raspberry Pi, which stem mainly from the old proprietary drivers and the slow
pace at which Raspbian gets up-to-date software. For most users, the
experience is much better.

~~~
stefan_
The irony of the Raspberry Pi in particular is that while the ARM side has
seen multiple order of magnitude jumps in performance, the GPU and compositor
hardware have of course remained at its original 2009 atrocious level.

The result is that the CPU drawing on a screen-sized framebuffer is fast
enough that Raspbian will probably never, ever make the jump to full bells-
and-whistles mainline VC4 drawing and atomic DRM composition. It would just
end up using a lot more memory and break a bunch of hacks in the proprietary
drivers that people have come to rely on for essentially still garbage tier
performance and a system that randomly freezes because you ran out of graphics
memory (which is forever limited to 256 MiB, memory that you surrender on boot
to the horrendous CMA system).

I like the Pi a lot as a PoC platform given the availability and the fully
open-source supported driver we have for it. But the HW specifications of all
the parts that Wayland cares about make it very clear that the thing was only
ever meant to do 1080P when you are piping frames from the video decode engine
straight to the compositor and out the pixel valves.

------
temac
Wayland, _in practice_ , couple too much the "compositor" with the driver
stack, and the desktop/wm with the "compositor", and THEN the
desktop/compositor/wm with applications (e.g. Firefox menus working or not
depending on the desktop env in use)

Then end result is that it explodes your test matrix. I won't use it while it
stays the case, because I don't have time to fight with basic graphic stuff
being broken all the time, and it is ridiculous to expect things to be _not
broken_ if the test matrix stays like that.

Plus it is starting to be old yet still missing half of the features, be it
existing X features (ex: ssh -X), basic desktop GUI needs (ex: whatever is
needed to implement Wine), or modern must-have (ex: colorimetry) (at least if
was the situation a few months ago, hopefully there have been some progress
since)

------
DonHopkins
>X is the graphical interface for essentially all Unix derived desktops (all
other competitors [link to Display PostScript wikipedia page] died decades
ago).

Since when was an X-Windows extension a "competitor" to X? Display PostScript
was simply a proprietary X-Windows extension that fell out of fashion, not a
competitor to X-Windows.

NeWS was a competitor to X-Windows that died decades ago, but Display
PostScript was never a "competitor" to X-Windows, just like the X Rendering
Extension and PEX were never competitors, just extensions.

But at least the article gets credit for calling it X-Windows instead of X11,
to annoy X fanatics. ;)

[https://medium.com/@donhopkins/the-x-windows-
disaster-128d39...](https://medium.com/@donhopkins/the-x-windows-
disaster-128d398ebd47)

~~~
erik_seaberg
I'm not sure what protocol they used for remoting NeXTSTEP's native
WindowServer, but I don't think it was X11. Some people did tunnel Display
PostScript over X11, but that wasn't the only option and it was pretty kludgy.

~~~
DonHopkins
That's right. DPS wasn't used for handling input events, or implementing the
user interfaces widgets, which instead were implemented in Objective C running
in another client process (usually running on the same machine), instead of
PostScript running in the window server. DPS didn't handle events with
PostScript in the DPS window server. Instead, it would ping-pong events over
the network from the window server, to the Objective C client, then send
PostScript drawing commands back to the window server. (Typically generic low
level drawing commands, not a high level application specific protocol.)

So NeXTSTEP suffered from the same problems of X, with an inefficient low
level non-extensible network protocol, slicing the client and server apart at
the wrong level, because it didn't leverage its Turing-complete extensibility
(now called "AJAX"), and just squandered PostScript for drawing (now called
"canvas").

So for example, you couldn't use DPS to implement a visual PostScript debugger
the way you could with NeWS, in the same way the Chrome JavaScript debugger is
implemented in the same language it's debugging (which makes it easier and
higher fidelity).

[https://medium.com/@donhopkins/the-shape-of-psiber-space-
oct...](https://medium.com/@donhopkins/the-shape-of-psiber-space-
october-1989-19e2dfa4d91e)

>The Shape of PSIBER Space: PostScript Interactive Bug Eradication Routines —
October 1989

>Abstract

>The PSIBER Space Deck is an interactive visual user interface to a graphical
programming environment, the NeWS window system. It lets you display,
manipulate, and navigate the data structures, programs, and processes living
in the virtual memory space of NeWS. It is useful as a debugging tool, and as
a hands on way to learn about programming in PostScript and NeWS.

------
jolmg
Can I just say that I think it's great that we now ceased to have a
monoculture in display servers for Unix-based systems? It was the last one, I
believe.

I mean, we've had choices for text-editors, for shells, for programming
languages, for GUI toolkits, for desktop environments, for window managers,
for remote-desktop servers and viewers, for ssl/tls implementations, for web
browsers, and even for kernels.

The only thing everyone using Unix-based systems all had in common was that
they had to use X for graphics. I think we had choices for implementations for
X (Xf86?) before we ended up just using Xorg, but now we even have the choice
to not use the X protocol.

Having choices is good. Having diversity is good. I hope we stop trying to see
this one as everyone converging to using only one. We can have both, like we
do now. I think that's the best.

~~~
DonHopkins
Why not just use a full screen direct-to-hardware web browser as the window
manager, and talk to clients, servers and other screens via HTTP, WebSockets,
two-way streaming video and screen sharing via RTP, etc?

The reason X-Windows sucks is that it's not extensible, and Wayland is only
incrementally and quantitatively better than X11 (like X12 or Y), not
radically and qualitatively better (like NeWS or AJAX).

Wayland has the exact same fundamental problem that X-Windows suffers from.
It's not extensible, so it misses the mark, just like X-Windows did, for the
same reason. So there's not a good enough reason to switch, because Wayland
failed to apply the lessons of Emacs and NeWS and AJAX. It should have been
designed from the ground up around an extension language.

Web browsers are extensible in JavaScript and WebAssembly. And they have a
some nice 2D and 3D graphics libraries too. Problem solved. No need for un-
extensible Wayland.

~~~
quink
> The reason X-Windows sucks is that it's not extensible

Years of configuring modules in XF86Config and matching things up between the
server and the client and that thankfully going away quite a bit with Xorg
would make my conclusion the opposite and yet also suggests it didn’t really
matter as much.

------
all2
I think it is important to point out that _Wayland is a specification_ [0] and
not some blob of software.

[0]
[https://wayland.freedesktop.org/docs/html/apa.html](https://wayland.freedesktop.org/docs/html/apa.html)

~~~
dyhtf
So is everything else in the world of software. You begin with a specification
and then you start writing code.

~~~
all2
Well, sometimes. Paul Graham and others from the lisp-ness crowd talk about
coding without a clear idea of where to go. I'm not in a place where I 'speak'
any language clearly enough to write without a plan.

I suppose for most enterprise stuff what you say is true (how else will we
commit to coding targets we won't hit for prices we can't afford on timelines
that make dog races look slow? - I suppose I'm a little early in life to be
jaded, but I am familiar with bureaucratic nightmares that value image over
substance).

------
miloignis
Do note that the article is mainly about Wayland on the raspberry pi. Of
course Wayland isn't the default most places yet (Fedora being the big
exception, I think), though you can install it on most distros.

I've been Wayland/Sway on NixOS for a while, and I really like it.

One question though - the article seems to say that wlroots is a Rust project,
but it seems to very much be a pure C project?
([https://github.com/swaywm/wlroots](https://github.com/swaywm/wlroots))

~~~
mattcoles
What do you like about it?

For general use it seems as if it'll be something that makes no difference to
my day-to-day usage of my computer other than a warm fuzzy feeling that the
underlying protocol is "right".

~~~
miloignis
That's true - the two things I really like are no screen tearing ever (be that
scrolling Firefox or YouTube videos) and that warm fuzzy feeling.

Edit: I also like Sway quite a bit (over i3/X) - its configuration (outputs,
input devices, etc) makes a lot more sense and is a lot easier for me than
trying to change stuff in different places and in different ways with X.

------
hs86
After reading
[http://techtrickery.com/keyloggers.html](http://techtrickery.com/keyloggers.html)
I am not sure if I ever want to have Xorg installed anymore. Wayland is great
but it seems like having a fully featured *nix desktop without XWayland
installed is still hard to achieve.

~~~
michaelmrose
Wayland is insufficient in and of itself to prevent keylogging.

[https://github.com/Aishou/wayland-
keylogger](https://github.com/Aishou/wayland-keylogger)

At present Linux desktops aren't very secure against user installed malicious
software. It is however fortunate that most software is installed from curated
repos.

It's not clear that just switching to wayland is worth much at this point in
time.

~~~
jcantero
That link is a blatant lie. Redirect each wayland client's stderr to a
different term and you will see that the process (keyboard/mice input +
graphics output) isolation is still working as intended.

~~~
michaelmrose
It's not a blatant lie. There is probably no default install in which I would
not feel it absolutely necessary to change every credential stored on a system
if it ever ran a compromised binary and a new install from scratch.

At best you are hoping that the malicious binary someone tricked you into
running didn't also take advantage of an additional vulnerability to
compromise everything. Keeping in mind that your adversary has every
opportunity to test against the same environment you are running.

The only linux environment that I've aware of that takes isolation really
seriously is qubes and even that isolation could be violated in theory.

I want desktop applications to have features that right now require
substantial permissions to effect. The primary defense is and will likely
remain not to install malicious software in the first place by installing from
curated sources.

~~~
jcantero
It's a blatant lie because the author of that code snippet is trying to trick
the reader into thinking that Wayland's isolation somehow has been broken, but
that's not true at all.

In the real world, any secure desktop solution is going to require a reliable
execution environment ("security is only as good as your weakest link"). If
you don't trust the user to properly handle that, then you must ensure they
don't do anything stupid or dangerous to themselves by restricting what they
can do. For desktop applications this usually means to execute them in a
sandbox (such as Flatpak). QubeOS tries to do something similar, but stumbles
upon the inherently insecure design of the X Server, and has to work around it
running separate X server instances for each unreliable X client.

------
keldaris
Last time (which was when Fedora first shipped it by default) I looked at
Wayland, it took me less than an hour to run into several showstopper issues
and move right back. The ones I remember include being incompatible with the
proprietary Nvidia drivers (and no plan to ever fix that), huge input lag
(apparently stemming from the, um, "interesting" idea to make the compositor
responsible for all input) and lots of random stability issues. Have these
things been fixed? Apart from a general dislike of X11, what are the reasons
one should consider a switch nowadays?

~~~
floatboth
> incompatible with the proprietary Nvidia drivers (and no plan to ever fix
> that)

I've heard that Nvidia is fixing this in KDE Plasma and maybe Gnome too. (Fuck
proprietary drivers though, and fuck Nvidia.)

> huge input lag

that's odd. Gnome's compositor is not the fastest, but it generally works okay
for many many people.

> the reasons one should consider a switch nowadays

\- No screen tearing ever, every frame is perfect

\- Real HiDPI support, different scales on different monitors, many
compositors support "Apple-style" fractional scaling (render at ceil(scale)
and downscale on GPU)

\- Proper touchscreen support, without dragging the mouse pointer along

\- Touchpad gesture support (this miiiight have been bolted onto X with
XInput2 as well)

~~~
ComputerGuru
> (Fuck proprietary drivers though, and fuck Nvidia.)

I _love_ nVidia's drivers. They "just work" and I don't need to muck about
trying to understand why this version of this video driver doesn't play right
with that version of drm or this kms setting.

Don't get me wrong, there are benefits to being a proper, native component of
a modular display system. But what's the point if none of them work, only
support random subsets of the hardware, and crash left and right?

~~~
reirob
Good for you. I have the worst Linux experience in 20 years, because I was
tempted to buy a high-end laptop that happened to have a nVidia graphics card
(ThinkPad X1E). Never ever will I touch hardware with nVidia. Certainly, I
might not be the target audience for this - I don't play games and work mostly
in a terminal and browser.

Once I managed to make it work, and that I am now able to select between the
NVidia and Intel - I have to tell, that I do not see any difference, in
performance. However the performance is below what I was used on the previous
computers - it might be due to the high resolution (3840x2160).

Connecting external monitors is a nightmare. It produces a lot of heat. And it
made me lose so much time! In this case I do not even care about proprietary
or open source drivers - I just want it to work.

I never had a more sluggish linux system since 1995. Even typing in the
browser or in the terminal makes me make mistakes, so much lag is there.

------
newnewpdro
This rant would be better directed at the landscape of cheap, poorly-supported
ARM devices like the Raspberry Pi and its clones.

These manufacturers should be developing proper GPU drivers for mainline with
full KMS/DRM/mesa support before they even sell their boards to the public
claiming Linux support.

Wayland and Xorg work just fine on Intel integrated graphics, Intel has been
setting the standard here for over a decade now.

~~~
voltagex_
The Pi is running on a set top box chip that has been "graciously" thrown over
the wall by Broadcom. Broadcom are not friends of the open source community.

>These manufacturers should be developing proper GPU drivers for mainline with
full KMS/DRM/mesa support before they even sell their boards to the public
claiming Linux support.

Broadcom or the Pi Foundation? One doesn't care and one doesn't have the
resources.

------
alexandernst
Because it's just not ready yet. It doesn't cover all the needs it must cover
in order to be considered superior to X.

At least that's the only reasonable explanation I can find.

------
mindcrime
Meh. As far as I'm concerned, Wayland is strictly inferior to X, so long as it
fails to support network transparency / remoting. Talk to me when they have a
real solution for this, besides VNC or supporting RDP.

~~~
altmind
Xorg remoting was poorly designed to accomodate DRI/DRM, video card
acceleration and had adequate performance to only display primitives on
screen. Thats the reasons of poor Xorg remoting adoption. I dont remember
seeing anyone in this decade using it - it hands down lost to vnc/nx and rdp.

~~~
petepete
I've not seen anyone using VNC or remote Xorg for years. Is it really _that_
important these days?

~~~
jolmg
The bar for being important enough to not discard when it works and is the
only solution to particular problems is not very high.

I know of no other method to forward individual programs GUIs to other
machines. Abandoning X is abandoning a power we have.

You're right that it may not be used as much. Last time I used it was to debug
why selenium tests running in chrome were failing in a server with a virtual
display (Xvfb) when the tests would work in any developer's machine. I
forwarded chrome's GUI from a docker container in a server in another room via
my development machine. Its window was neatly tiled next to my other windows
in my tiled window manager. You wouldn't be able to tell it wasn't running
locally. I don't have to mess around with a desktop inside a desktop. Such
neatness in UX is a comfort I'd like to keep.

I'm all for making a new, more efficient display server, but please don't take
powers away.

~~~
bitwize
> Abandoning X is abandoning a power we have.

A power that literally no one uses.

Well, no one that matters anyway. For values of "matter" equivalent to "uses a
modern desktop".

Whatever the case, modern development heavily favors coding for the common
case, not supporting a flexible framework that can accommodate fringe cases.
And in 2019, your use case is fringe.

~~~
jolmg
> A power that literally no one uses.

I just told how I used it.

> Well, no one that matters anyway.

I don't matter? That's kind of rude.

> Whatever the case, modern development heavily favors coding for the common
> case, not supporting a flexible framework that can accommodate fringe cases.
> And in 2019, your use case is fringe.

Are you going to say that accessibility features should also be discarded?
Being deaf or blind are not the common case.

~~~
bitwize
"Modernity", "network transparency is irrelevant in $CURRENT_YEAR" and "nobody
uses those features anymore" are among the most commonly cited reasons why you
must abandon X NOW and switch to Wayland. Those and "muh security". (The very
real security issues with Xorg could be mitigated or eliminated completely
with a more sophisticated X server design.)

Like it or not, you will have to come to grips with the fact that the Linux
desktop and graphics-stack discussion is dominated by developers from the age
of GNOME, who haven't put much thought in beyond how they personally use their
own MacBooks. These are the ones calling the shots, and they've decided that X
is obsolete, that network transparency is cruft that should be eliminated, and
that Wayland is suited to task. So Wayland will be the supported solution
going forward.

> Are you going to say that accessibility features should also be discarded?
> Being deaf or blind are not the common case.

Given the shit state of accessibility under Linux, I'd say yes, it is fringe
to the people building the Linux desktop. If you're disabled, it makes much
more sense to get a Mac or Windows machine.

------
Sylos
Half-offtopic: I find it very interesting that Rasbian sticks to LXDE. I
thought that was going to slowly disappear, with LXQt having developer
attention and there being no path forward towards HiDPI and well, Wayland
(because neither GTK2 nor Openbox support these).

LXQt currently still uses Openbox, but you can replace it with KWin rather
easily. I don't know what is then still missing to create a proper LXQt
Wayland session, but it seems feasible.

I guess, one does not really need HiDPI on a Raspberry Pi, but yeah, Wayland
would be nice.

------
impostir
I recently switched back to Arch and decided to try out Wayland. So far, I
have only had some problems with Firefox, which could be solved I'm just being
lazy. My one wider complaint is no autokey support, which isn't planned on
being added. Overall, solid replacement to X11

~~~
floatboth
I'm not sure what exactly you mean by autokey, but you can implement various
keyboard tricks on various levels…

If you have a compositor that supports plugins, such as Wayfire, you can write
a plugin: [https://github.com/myfreeweb/numbernine/blob/master/wf-
plugi...](https://github.com/myfreeweb/numbernine/blob/master/wf-
plugins/mod2key.cpp)

You can also do things on the evdev level by listening to keys and emitting
new keys from a virtual device. My tool for that:
[https://github.com/myfreeweb/evscript](https://github.com/myfreeweb/evscript)

------
c-smile
The article is focused on essentially old idea of framebuffers:

> Even more ideally these memory chunks would just be textures in the GPU.

And that idea is very far from modern world of high-DPI monitors.

In high-DPI UI you cannot operate on textures anymore.

Window surface shall be represented not by bitmap (that is O(N) complex to
fill by CPU) but rather CommandLists:

    
    
       [opFillRect,0,0,100,100]
       [opFillPath,...]
       [opBlitBitmap,...]   
     

Window compositor shall pass such command lists to GPU for rendering.

This way to fill rectangle on window's surface will be O(1) complex operation
- just to send [opFillRect,0,0,100,100] command to window (and so to GPU) for
rendering.

~~~
stefan_
I believe you are at the wrong stage, mentally. This is all about the
_compositor_ that puts the final image on your screen together. The input to
this component is always a list of textures with associated meta information
(offset on screen, scaling, alpha mixing, Z position.. whatever your
compositor offers). How these textures are created is not the business of the
compositor - and the routine case is of course through GPU drawing!

There are two things to mention here that are of particular importance on
mobile systems. Lots of chips now have compositor hardware - separate silicon
from the GPU that can read textures, scale them, blend them and push the
resulting pixels directly to the screen. And second, the word "texture" is
used here to mean "any format that GPU, compositor and video decode engine can
read or produce" \- in stark contrast to the old framebuffer approach, it is
essential that things stay in their "native" format for as much of the
pipeline as possible and are never CPU read or modified, which would require
conversion.

------
xiii1408
Thanks for this great primer! Not quite through with the article, but I've
recently been using my Raspberry Pi as a workstation (I mostly use SSH
anyway), and I've had issues / confusion with hardware acceleration and X vs.
Wayland for a long time.

I never seem to be able to get hardware acceleration to work properly in Linux
on my MacBook---whenever I open up a webpage, CPU usage goes through the roof,
unlike in Mac OS. Wayland seems to help a bit, but there seem to be lots of
bugs than can only be fixed by the window manager.

------
Vogtinator
I had a full Plasma Wayland session running on AArch64 RPi in mid 2016, so
this is just wrong.

The only issue is that the Raspbian downstream kernel and broadcom's
proprietary userspace drivers are a pretty big mess and not compatible with
anything.

When not using any of them, you get a much better experience with software
compatibility.

------
JohnFen
I don't mind if it exists on the Pi, so long as X is still an option. I use
the remote desktop facilities X provides even more with Pis than with any
other platform, and to the best of my knowledge, Wayland doesn't have anything
like that.

------
yndoendo
Last time I coded for the Raspberry Pi, gen 2, I used Wayland with Sway on
Arch Linux ARM. Fast and more responsive than the standard DE provided by
Raspbian. Was running Sway on Raspbian but needed access to the latest version
of Go.

------
amiga-workbench
I've been using it ever since it became available in Fedora, no more screen
tearing out the box like X, but it does cause me issues on my ThinkPad with a
Wacom Digitizer. I could probably fix it quite easily if I stop being lazy.

------
billfruit
Did beos and haiku use X? I think not, then how do their graphics systems
work?

~~~
rcarmo
Direct to hardware. There is a framebuffer driver that IIRC uses VESA
primitives, and a few other more generic drivers with bit blitting and OpenGL
support.

~~~
billfruit
Has anybody tried porting that system over to Linux?

~~~
rcarmo
Everyone tied to that is much more focused on actually getting Haiku OS to
work everywhere.

------
MagicPropmaker
> It delegated all of that to X windows and user space drivers.

and

> Further slowing down progress is X-Windows. X is the graphical interface for
> essentially all Unix derived desktops (all other competitors died decades
> ago).

I'm confused. What's "X windows" and "X-Windows?" Is he talking about the X
Window System?

[https://en.wikipedia.org/wiki/X_Window_System](https://en.wikipedia.org/wiki/X_Window_System)

------
stuaxo
I wish I'd seen it when it came out he sort of stopped at the first hurdle
when it came to trying to compile.

------
dimman
Ubununtu, hilarious typo

~~~
m463
"I can spell banana but sometimes I forget when to stop"

------
craftyguy
tl;dr: shitty graphics hardware vendors who don't care about Linux support.

