96 ms·
Why don't we have Wayland on Raspberry Pi yet? (2018)
- mindcrime 8y agoMeh. 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 8y agoXorg 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.
- 0x8BADF00D 8y agoYeah, VNC is just way better. Even running a local Docker container and using X11 forwarding is extremely slow.
- jolmg 8y agoIt depends on how you define better. VNC may be faster, but it's just because X carries a lot of historical cruft, I believe. Usability-wise, X is more flexible. I can move individual windows between computers in X. I can't do that with VNC. I wouldn't mind doing the jump to Wayland if it were as flexible as X, but that doesn't seem to be the case. Correct me if I'm wrong.
- altmind 8y agowhat's the point of running program locally, to be rendered locally, sending the primitives to Xorg server to be displayed somewhere else? is it using Xorg as a network proxy?
- josteink 8y agoI think you got it kinda backwards, but due to confusing naming you wouldn’t be the first. It’s more like I’m logging into a remote server (using stuff like SSH), starting applications there and getting the GUI up on my local desktop, like any other local window/app, due to X-forwarding (back to my Xorg server). It’s not perfect, but it sure is a lot more “natural” and integrated into your desktop than VNC or RDP. I hope we can keep something similar with Wayland (using maybe XWayland or other compatibility kludges). I think it’s pretty nice.
- AnIdiotOnTheNet 8y agoRDP has had remote app for a long time now, which is essentially the same thing: run program on remote machine, forward its window to local.
- mindcrime 8y agoInteresting, I've never heard of that facility before. I guess it wasn't promoted very heavily? Or maybe it's just because RDP comes from the MS world and I try very hard to avoid Windows and anything Windows-centric unless forced to. Anyway, thanks for sharing that. I'll look into it. Here's some info on RemoteApp for anybody else who's interested. https://techcommunity.microsoft.com/t5/Enterprise-Mobility-Security/Introducing-RemoteApp-and-Desktop-Connections/ba-p/246803 https://techcommunity.microsoft.com/t5/Enterprise-Mobility-S... https://social.technet.microsoft.com/wiki/contents/articles/2345.publish-a-remoteapp-application-on-remote-desktop-service.aspx https://social.technet.microsoft.com/wiki/contents/articles/...
- magicalhippo 8y ago> Or maybe it's just because RDP comes from the MS world and I try very hard to avoid Windows and anything Windows-centric unless forced to. It'll be due to that. For the most part it works really well, though still not flawless after all these years.
- josteink 8y ago
- DonHopkins 8y agoIt's not "historical cruft" that makes it slow. It's the fundamental architecture of X-Windows that makes it slow. Computers these days are network bound, not CPU or memory bound. It's not sluggish because it's executing too much code or running out of memory or too complicated. It's sluggish because it's making the wrong decisions to do the wrong things at the wrong times in the wrong places.
- m463 8y agoI run proxmox on one system to run a few VMs. I view the vm console displays remotely in the browser using novnc. I thought it was pretty cool the first time I used it.
- renox 8y agoUh? I much preferred NX instead of VNC because I didn't have to define the resolution when starting the server, plus it felt faster
- petepete 8y agoI've not seen anyone using VNC or remote Xorg for years. Is it really that important these days?
- jolmg 8y agoThe 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 8y ago> 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 8y ago> 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.
- temac 8y agoI use ssh -X all the time.
- cat199 8y agononono, you're simply not getting it. I don't use it for reason X, therefore I can project this reasoning onto those that disagree, and dismiss them by calling them outdated. So, obviously your use case is irrelevant.
- mindcrime 8y agoI use it, so I could care less about your "it hands down lost to vnc/nx and rdp" assessment. And until Wayland has a mechanism that has the flexibility of X remoting, it is a strictly inferior technology - for my purposes. That doesn't mean that I may not be forced to adopt it due to market forces, but let's not pretend that this isn't a glaring hole in Wayland for many people.
- cat199 8y agonot to mention that 'poor adoptation' is much more likely driven by 'isolated single user on ubuntu laptop that doesn't know this exists' usecase dominating in sheer numbers over 'network of unix workstations operated by group of knowledgable users' than 'application X is slightly slow over the network, boo'
- BenjiWiebe 8y agocouldn't care less.
- mindcrime 8y agoThey mean the same thing. https://www.google.com/search?client=firefox-b-1-d&q=Dictionary#dobs=could%20care%20less https://www.google.com/search?client=firefox-b-1-d&q=Diction...
- JohnFen 8y ago> it hands down lost to vnc/nx and rdp. Those solutions don't do what X remote desktop does, though. Namely, those let you share a desktop rather than providing independent remote desktops.
- altmind 8y agoto my knowledge, to supply multiple X remote desktops, you need to SPAWN multiple X desktops. and thats no a proper way to scale its number - they all are independent and not sharing common resources(incl. incoming ports)
- JohnFen 8y agoI think how X works with this (and a lot of other stuff) can be very fairly criticized. Despite the implementation drawbacks, though, I use this ability heavily and in practice it gives me no trouble. Plus, I'm unaware of any other solution to this use case. It doesn't scale well if you're talking about dozens of simultaneous desktops, yes, but I rarely have more than three at a time. It's fine for that.
- erik_seaberg 8y agoDRI/DRM makes the assumption that your GPU is plugged in the one and only machine hosting all your apps. This wasn't that crazy in 1998, but today the GPU is under my desk while myriad app hosts are racked in datacenters (where a GPU might be an expensive addon, but probably doesn't exist) and good remoting is so neglected that the industry is using web browsers as display servers to fill the gap.
- floatboth 8y agoNo, web browsers are used as an application platform, not a display server. Especially with SPAs ("thick" clients).
- munchbunny 8y agoAfter this many years, I think the ambition to support remoting at the per-window level just isn't important. In practice I've actually found it outright confusing when I have two windows operating inside two separate environments, but they're both in the same visual container. VNC/RDP work well enough, and SSH works well enough for when you don't need a GUI.
- exelius 8y agoI tend to agree. The original promise of remote X11 (server side compute and thin clients) is provided via web apps these days.
- vetinari 8y agoBoth RDP and Citrix do support publishing just the application, without desktop. It is actually pretty neat to have application, running somewhere in the server room, to be mixed with my local applications. Going even further, the remote applications can run each on different machine in the Citrix cluster, so it is possible to load balance on per-app basis.
- politician 8y agoDon't these solutions simply crop the desktop out? You used to be able to see the desktop behind the app if you resized the window rapidly.
- vetinari 8y agoI'm able to see flashes of background color, but not desktop. Start menu and other desktop widgets are unavailable, except the keyboard widget, which has support coded into the client.
- temac 8y agossh -X works well (enough) when you need a GUI.
- 8y ago
- sp332 8y agoRemoting will be up to the compositor implementation, it's not specified in the Wayland protocol. For example, Weston has just added a "remoting" plugin last month. https://www.phoronix.com/scan.php?page=news_item&px=Weston-6.0-Released https://www.phoronix.com/scan.php?page=news_item&px=Weston-6... This also allows for some really crazy ideas like a Wayland compositor running in a browser for remote app access. https://github.com/udevbe/greenfield https://github.com/udevbe/greenfield
- ZiiS 8y agoMeh. As far as I'm concerned, Wayland is strictly superior to X, so long as it fails to support keyloggers.
- zzzcpan 8y agoWayland is developed by people who don't take security seriously at all. So security arguments are irrelevant here and do not favor wayland in any way. I'd say wayland is just a new thing that breaks everything in an attempt to break less.
- michaelmrose 8y agoExcept it does actually support keyloggers while breaking the concept of global keybindings. It's like the worst of both worlds.
- tinus_hn 8y agoIt’s a red herring anyway. All processes owned by a user can influence all other processes owned by that user, either directly or indirectly. It’s basically impossible to prevent. Don’t run code you don’t trust and don’t let things you don’t trust connect to your display server.
- floatboth 8y agoWell, you don't have to run an untrusted program as your user account, you can sandbox. If you run something in a jail and pass it a wayland socket, it will be able to display, but won't be able to modify your files.
- alexandernst 8y agoBecause 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.
- mwfunk 8y agoI 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.
- jolmg 8y ago> but I bet the original creators would be the ones most shocked that it's still a thing in 2019. Couldn't we say the same thing about bash or basically most tools in your typical Unix-based OS? Old code is solid code. If they're to be shocked it's for doing something so right that it's persisted all this time.
- DonHopkins 8y agoExcept that X11 isn't doing something so right -- it's still terrible, and it always has been, and we knew it was terrible at the time it was standardized. But it's funny that you would bring up something as terrible as a shell scripting language like bash to compare to how terrible X-Windows is. Have you ever read through a gnu configure file yourself, or do you just close your eyes and type "./configure"? Who in their right mind would ever write a shell script, when there are so many real scripting languages that don't terribly suck universally available, that don't shit themselves when they encounter a file name with a space in it? These quotes about X-Windows apply to bash as much as they do to X-Windows: "Using these toolkits is like trying to make a bookshelf out of mashed potatoes." -Jamie Zawinski "Programming X-Windows is like trying to find the square root of pi using roman numerals." -Unknown https://medium.com/@donhopkins/the-x-windows-disaster-128d398ebd47 https://medium.com/@donhopkins/the-x-windows-disaster-128d39...
- all2 8y agoI 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
- e12e 8y agoSo is x11? There used to be a couple of commercial x servers available for Microsoft windows, for example.
- DonHopkins 8y agoEven before Microsoft Windows: Quarterdeck DESQview/X, for example. And of course X-Windows ran on Lisp Machines. https://en.wikipedia.org/wiki/DESQview https://en.wikipedia.org/wiki/DESQview >DESQview/X >Quarterdeck eventually also released a product named DESQview/X (DVX), which was an X Window System server running under DOS and DESQview and thus provided a GUI to which X software (mostly Unix) could be ported. >DESQview/X had three window managers that it launched with, X/Motif, OPEN LOOK, and twm. The default package contained only twm, the others were costly optional extras, as was the ability to interact on TCP/IP networks. Mosaic was ported to DVX. >DVX itself could serve DOS programs and the 16-bit Windows environment across the network as X programs, which made it useful for those who wished to run DOS and Windows programs from their Unix workstations. The same functionality was once available with NCD Wincenter.
- dyhtf 8y agoSo is everything else in the world of software. You begin with a specification and then you start writing code.
- all2 8y agoWell, 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).
- pantalaimon 8y agoI 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 8y agoThere'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.
- rhn_mk1 8y agoPerhaps the author meant Smithay, which, while it still depends on some C, is almost entirely Rust: https://github.com/Smithay/smithay https://github.com/Smithay/smithay
- miloignis 8y agoDo 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)
- josteink 8y ago> the article seems to say that wlroots is a Rust project, but it seems to very much be a pure C project? Yeah. It uses meson/ninja to build. No Rust.
- mattcoles 8y agoWhat 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 8y agoThat'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 8y agoAfter 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.
- miloignis 8y agoIt's definitely possible depending on your use case - I can run Firefox and a terminal without XWayland running, which is all I need. (There was a weird bug where Firefox under Wayland would open an X window first and then discard it, not sure if that's been fixed yet)
- michaelmrose 8y agoWayland 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 8y agoThat 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 8y agoIt'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.
- impostir 8y agoI 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 8y agoI'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-plugins/mod2key.cpp https://github.com/myfreeweb/numbernine/blob/master/wf-plugi... 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
- newnewpdro 8y agoThis 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.
- Const-me 8y agoSome clones are better than others. This kernel https://github.com/TinkerBoard/debian_kernel https://github.com/TinkerBoard/debian_kernel supports DRM/KMS quite well. Don’t know about Linux desktop, but for my embedded use case where I build stuff directly on top of drm, kms and gles, it works fine driving 2 displays, one of them is 4k.
- rjsw 8y agoAt least the Raspberry PI has documentation for its GPU. The rant should be directed at ARM itself for not providing documentation for Mali.
- floatboth 8y agoThere is a mainline driver for the RPi with full Mesa support. On e.g. Arch Linux ARM, you can just install a wayland compositor and run it. It's just the conservatism of distros like Raspbian. 32-bit, old kernel, proprietary blobs, old packages (stable debian).
- voltagex_ 8y agoThe 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.
- DonHopkins 8y ago>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-128d398ebd47 https://medium.com/@donhopkins/the-x-windows-disaster-128d39...
- wmf 8y agoDidn't NeXTSTEP use DPS without X?
- DonHopkins 8y agoNeXTSTEP for the NeXT workstation, started in 1987 and released in 1989, used a DPS server with its own protocol without X (the DPS code was licensed from Adobe, the same code that ran in laser printers like Apple's LaserWriter). https://en.wikipedia.org/wiki/Display_PostScript https://en.wikipedia.org/wiki/Display_PostScript In 1985, two years before DPS was started and four years before NeXTSTEP was released, James Gosling and David Rosenthal at Sun developed their own PostScript interpreter for NeWS, originally called SunDew, which was distinct from and quite different than DPS, and wasn't licensed from Adobe. http://www.chilton-computing.org.uk/inf/literature/books/wm/p005.htm http://www.chilton-computing.org.uk/inf/literature/books/wm/... https://en.wikipedia.org/wiki/NeWS https://en.wikipedia.org/wiki/NeWS Then in 1993, NeXT and Sun developed OpenStep for X-Windows/DPS. https://en.wikipedia.org/wiki/OpenStep https://en.wikipedia.org/wiki/OpenStep One of the biggest architectural difference between NeXTSTEP/DPS and NeWS is that NeXTSTEP didn't take advantage of the technique we now call "AJAX," by implementing the user interface toolkit itself in PostScript running in the window server, to increase interactive response and reduce network messages and round trips. https://news.ycombinator.com/item?id=13783967 https://news.ycombinator.com/item?id=13783967 NeXTSTEP wasn't trying to solve the remote desktop problem: the toolkit implemented in Objective C code just happened to be using local networking to talk to the DPS server, but in no way was optimized for slow network connections like NeWS was (and AJAX is). You couldn't run NeXTSTEP applications over a 9600 baud Telebit TrailBlazer modem, but NeWS was great for that. I worked on the UniPress Emacs display driver for NeWS, which was quite usable over a modem, because you do stuff like text selection feedback, switching and dragging multiple tabbed windows around, and popping up and navigating pie menus, all implemented in PostScript running locally in the window server, without any network traffic! https://www.donhopkins.com/home/code/emacs.ps.txt https://www.donhopkins.com/home/code/emacs.ps.txt https://www.youtube.com/watch?v=hhmU2B79EDU https://www.youtube.com/watch?v=hhmU2B79EDU NeWS was architecturally similar to what is now called AJAX, except that NeWS coherently: used PostScript code instead of JavaScript for programming. used PostScript graphics instead of DHTML and CSS for rendering. used PostScript data instead of XML and JSON for data representation.
- Sir_Cmpwn 8y agoThis 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.
- floatboth 8y ago> wayland-rs does not wrap libwayland, but instead offers a pure Rust implementation of the Wayland protocol Originally it only wrapped libwayland. Now it offers both libwayland and a pure Rust implementation, togglable with the Cargo features client_native and server_native.
- stefan_ 8y agoThe 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.
- Sylos 8y agoHalf-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.
- hyperion2010 8y agoWayland 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.
- sam_lowry_ 8y agoRight, X11 made it possible to have literally hundreds of window managers written to fit all possible tastes. With Wayland, the ecosystem of window managers will never be as rich, because a window manager has to implement too many things to be usable.
- floatboth 8y agoYou can always take a compositor and fork it to implement your window management features… or, much better, use a compositor with a plugin system, so window managers can become plugins! :) https://github.com/WayfireWM/wayfire https://github.com/WayfireWM/wayfire
- m463 8y ago> Right, X11 made it possible to have literally hundreds of window managers written to fit all possible tastes. I've used it since its inception, however it has always kind of sucked. I think it goes to it's basic philosophy: it did not enforce policy. This let it survive a long time. It was whatever people wanted it to be. But because of this flexibility, it never became great. It's like the old Lilly Tomlin skit - "I always wanted to be somebody, but now I realize I should have been more specific."
- temac 8y agoWayland, 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)
- cbdumas 8y agoI'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!
- hollerith 8y agoThat is encouraging. What distro are your swaywm and Firefox running on?
- cbdumas 8y agoI'm running Arch, which I find to be the most frictionless when you're trying to do sort of "bleeding edge" stuff like this.
- hollerith 8y agoIt is time for me to give desktop Linux another try (which will be my first serious try in 10 years).
- cbdumas 8y agoYes definitely! Things have come a long way in 10 years, in my opinion. If you are looking for something more "set up and forget about it" though I would definitely recommend Ubuntu over Arch. I use Arch because I (usually) enjoy tinkering and customizing and setting things up exactly how I want. Edit for a little more detail: I used Ubuntu for a long time on my desktop and actually did quite a bit of gaming on it. Mostly stuck to games that have native Linux support but from what I hear the compatibility layer that Valve has released is actually really good. If gaming is your thing. All this is to say, things that were once supposed to be impossible on Linux are now very much possible.
- amiga-workbench 8y agoI'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 8y agoDid beos and haiku use X? I think not, then how do their graphics systems work?
- rcarmo 8y agoDirect 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.
- smallstepforman 8y agoHaiku AppServer is home grown, using AntiGrainGeometry libs for rendering to Framebuffer.
- JohnFen 8y agoI 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.
- ChuckMcM 8y agoI 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 8y agoFunny 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-million-instructions-per-second-3a8c92165cfe https://medium.com/@donhopkins/bill-joys-law-2-year-1984-mil... On Nov 8, 2018, I sent Bill Joy a birthday greeting: "Happy 17,179,869,184 MIPS Birthday, Bill"! (2 to the (year - 1984))
- xiii1408 8y agoThanks 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.
- jolmg 8y agoCan 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.
- gpderetta 8y agoExactly, I mean, there was one thing that all the various slightly incompatible Linux distros agreed on. Finally we have fixed that.
- DonHopkins 8y agoWhy 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 8y ago> 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.
- keldaris 8y agoLast 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 8y ago> 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)
- jimbo1qaz 8y ago"Apple-style" fractional scaling makes horizontal and vertical lines and hinted (vertically grid-fitted) text blurry.
- ComputerGuru 8y ago> (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?
- c-smile 8y agoThe 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_ 8y agoI 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.
- dimman 8y agoUbununtu, hilarious typo
- m463 8y ago"I can spell banana but sometimes I forget when to stop"
- MagicPropmaker 8y ago> 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
- mrlambchop 8y agoWoah - 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 8y agoIf you connected with Eric Anhold and worked on this, you would help millions of Pi students and users. It is an opportunity.
- mrlambchop 8y agoI 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.
- craftyguy 8y agotl;dr: shitty graphics hardware vendors who don't care about Linux support.
- yndoendo 8y agoLast 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.
- Vogtinator 8y agoI 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.
- stuaxo 8y agoI wish I'd seen it when it came out he sort of stopped at the first hurdle when it came to trying to compile.