[HN Gopher] Guide: Full Wayland Setup for Linux
___________________________________________________________________
Guide: Full Wayland Setup for Linux
Author : colingw
Score : 95 points
Date : 2021-03-10 16:53 UTC (6 hours ago)
(HTM) web link (www.fosskers.ca)
(TXT) w3m dump (www.fosskers.ca)
| clircle wrote:
| I have Ubuntu 20 and sometimes switch between "Ubuntu" and
| "Ubuntu on Wayland" and can't tell any speed difference.
| mappu wrote:
| This is an opinionated guide, hopefully nobody gets the wrong
| idea like it's actually hard to start using Wayland - for me,
| switching to Wayland was one drop-down menu option that
| automatically appeared on my login screen.
| MuffinFlavored wrote:
| > switching to Wayland was one drop-down menu option that
| automatically appeared on my login screen.
|
| On what distro?
| OtomotO wrote:
| I assumed they meant they used gnome 3+ or kde plasma (or
| another de) where it's just another option on the login
| screen.
|
| For i3 -> sway it's not as easy but also not very
| complicated, nor time-consuming
| MuffinFlavored wrote:
| when you install GNOME 3 these days, does it install both
| Xorg + Wayland packages, and then at runtime you pick which
| you want?
|
| I would have guessed the GDM/login manager is X11/xorg?
| colingw wrote:
| Totally - the guide is a reflection of the steps that I
| personally went through to get it all set up. I use tiling
| window managers, so had to configure everything (the topbar,
| etc) myself.
| babypuncher wrote:
| It is highly dependent on the user's hardware and software
| combination.
|
| For example, getting Wayland to work with Plasma on Nvidia
| graphics cards is still a nightmare, despite it being
| officially supported. Out of the box, starting a Wayland
| session just knocks the user into a frozen TTY. Once you get it
| to work, you quickly learn that hardware acceleration for X11
| apps is nonexistent, rendering most video games unplayable.
| zamadatix wrote:
| If you go this "build it piecewise" route instead of a full
| package DE you'll probably also want notifications, screenshot, a
| GUI tool for external monitor management (I go as far as using
| nmtui instead of a widget for networking but absolute detest
| dealing with sway commands to present on an external screen),
| battery monitor, and a screen lock/screensaver. Plenty of good
| options for all the above but sway is not a batteries included DE
| to choose so you have to find them yourself.
|
| Mostly to learn new things I didn't do any xwayland at all. It's
| definitely been interesting but certainly not what most would
| want at the moment IMO.
| colingw wrote:
| Luckily tools are available for all of that, many of them
| through Sway directly. Interested folks can check out the Sway
| Wiki.
| Spivak wrote:
| For screenshots there are currently two competing approaches.
| GNOME and KDE have opted for dbus interfaces (e.g
| org.gnome.Shell.Screenshot) and Sway has opted for Wayland
| protocol extensions (zwlr_screencopy_manager_v1). I think the
| former is more maintainable because dbus interfaces are
| accessible by pure cli tools where grim and wl-clipboard have
| to create dummy wayland surfaces just to talk to the
| compositor.
|
| At least everyone agrees on the notification dbus interface and
| the tooling is super mature.
| vz8 wrote:
| I suppose trying this on VirtualBox (Win10 system) could be an
| exercise in frustration, but I'm tempted...
| dtx1 wrote:
| live boot from a usb stick might be better.
| solarkraft wrote:
| Yay for wlroots based Wayland compositors!
|
| Besides the tiling Sway there's also the stacking Wayfire[0] that
| is from the same family, but modeled after Compiz (blur, desktop
| cube and good old wobbly windows are all there) and highly
| configurable.
|
| I use it with Waybar[1], wf-dock[2], Sirula[3] as a launcher and
| a bunch of other small tools like Gammastep[4] (fork of Redshift)
| for white balance adjustment, grim & slurp [5] for screenshots
| and mako[6] for notifications. [7]
|
| It's a very DIY-y experience, but it's meant to be (if you want
| something pre-configured you can barely change try Gnome). The
| combination of getting it just right and the Ikea effect makes
| for a pretty rewarding result (I also maintain a list of the
| available desktop tools you can use when on a wlroots based
| compositor for your DIY needs [8]). The vision for the future is
| pre-configured DEs being offered on this base and it possibly
| even offering a lot of Sway's tiling features. [9]
|
| It still feels like the early days (for non-Gnome), but with
| Nvidia driver 470 & accelerated XWayland coming up, the Vulkan
| efforts, Electron (finally) and Wine making the switch I feel
| fairly confident saying that 2021 is shaping up to be the year of
| the Wayland desktop.
|
| Free of screen tearing and X-related worries since 2020 :-)
|
| [0]: https://wayfire.org/
|
| [1]: https://github.com/Alexays/Waybar
|
| [2]: https://github.com/WayfireWM/wf-shell
|
| [3]: https://github.com/DorianRudolph/sirula
|
| [4]: https://gitlab.com/chinstrap/gammastep
|
| [5]: https://github.com/emersion/grim
|
| [6]: https://github.com/emersion/mako
|
| [7]: My not-completely-but-fairly Wayfire config
| https://gist.github.com/solarkraft/f46421295b8c211b2eb56b3ac...
|
| [8]: https://github.com/solarkraft/awesome-wlroots
|
| [9]: https://github.com/Javyre/swayfire
| OtomotO wrote:
| Funny thing: I was on sway full time for over a year, nearly 2
| actually. I went so far as to uninstall i3 (not XWayland, nor X
| for obvious reasons)
|
| Since a few months I noticed weird (complete) freezes/crashes on
| my pc, while gaming... it's not the youngest so I thought it may
| come to end of life.
|
| Out of curiosity I reinstalled i3 a couple of days ago and used
| it (only) for gaming. No crash since.
|
| I assume it's either a bug in Mesa (AMDGpu) or somewhere in the
| wayland stack... sway hasn't had an update since November, so...
| I dunno, I haven't taken the time to investigate.
|
| While working I still use sway, because I've customized it to my
| needs, but for Gaming/Streaming I now switch to i3 again.
|
| Nice sideeffect: I can finally play some games again that
| wouldn't even launch on Sway or were unplayable, like e.g.
| Natural Selection 2 which turned to a black screen when I
| switched workspaces (e.g. from one monitor to another) to e.g.
| tune down the music or scroll down a page while being dead.
|
| Feels funny, but more annoying :/
| _bin_ wrote:
| While I respect Drew's right to keep Nvidia hardware
| unsupported, doing so cuts out a huge chunk of Linux video game
| players users. I therefore find it unsurprising that video
| games have a number of issues that day-to-day use cases don't.
| Even though this is AMD, lack of Nvidia support keeps Xorg as
| the default for video games, and this means worse AMD support
| too.
| OtomotO wrote:
| Personally I don't see how supporting the proprietary nvidia
| drivers would help my situation as I am using Mesa (and
| Noveau is supported afaik (?!)) but I assume there is a
| kernel of truth in there that a lot of people cannot/won't
| even consider sway because they are on proprietary nvidia
| stacks.
|
| - I wrote before the edit -
| ubercow13 wrote:
| The main thing up to now keeping Xorg the default for video
| games was nVidia's lack of Xwayland acceleration support,
| which made gaming on Wayland largely impossible regardless of
| wlroots.
| toggleton wrote:
| And if i uunderstand it right is xwayland acceleration in
| work for the 470 Driver Release https://gitlab.freedesktop.
| org/xorg/xserver/-/merge_requests...
| MayeulC wrote:
| Eeh, I did play NS2 some time ago without a black screen. Some
| games seem to have a focus issue when launched trough proton,
| though.
|
| I do have lockups on Risk of Rain 2, Deep Rock Galactic and a
| few others:
| https://gitlab.freedesktop.org/mesa/mesa/-/issues/864
|
| I thought of using another installation, with and without
| flatpak, but hadn't thought of launching outside of sway, since
| the crash issue after a while. I'll try lxqt, which I'm
| currently falling back to for VR (waiting for
| https://gitlab.freedesktop.org/wayland/wayland-protocols/-/m...
| ).
|
| Symptoms are: a black screen, and nothing responds. No SysRq,
| no network. Nothings gets written to the logs. I tried
| leveraging pstore without success. My GPU is an AMD R9 Fury,
| which I thought was defective (bought refurbished).
| OtomotO wrote:
| Another frustrating experience was OBS. It would crash quite
| often due to a bug in qtwayland that someone from the community
| fixed (can't find the ticket right now) - had to do with too
| many events queuing up if it was in background and re-focused.
|
| If you read this kind stranger: Thank you so much for this fix!
|
| One thing that doesn't work to this date for me is custom
| browser docks, which means if you stream and want to interact
| with your viewers, you need to have a browser open as well :/
| boudin wrote:
| I have similar issues, those seems to be related to the
| xwayland implementation of wlroots/sway. I do not have those
| issues with Gnome on wayland. Looking at the master branch of
| the project, it seems that it should get better with the next
| version.
| OtomotO wrote:
| That's great to hear. I wish they would release more often.
|
| I tried to build sway-git twice during the last 2 weeks. Just
| from the AUR, because I was feeling lazy after work. It
| failed twice and I just reverted back to sway 1.5.x because I
| couldn't bother to learn yet another build-tool and dive into
| C again. (Yes, I am one of those developers)
| vetinari wrote:
| Wrt SDL2: You can actually replace SDL2 with your own, even if it
| is statically linked with the game. First, do `export
| SDL_DYNAMIC_API=/my/actual/libSDL-2.0.so.0` and then launch your
| game.
|
| All the gory details:
| https://www.reddit.com/r/linux_gaming/comments/1upn39/sdl2_a...
| ciupicri wrote:
| > Sway is a tiling window manager [...] written in C, and thus is
| very fast and has little resource overhead.
|
| So is GNOME as far as I know.
| dralley wrote:
| GNOME has enough Javascript scattered throughout that I
| wouldn't call it a C program, even if large chunks like Mutter
| mostly are.
| xfalcox wrote:
| Gnome is not a tiling window manager.
| londons_explore wrote:
| Isn't gnome a big pile of JavaScript these days anyway?
| hc-taway wrote:
| Yes, as is Pop Shell implemented on top of Gnome (mentioned
| in another comment).
|
| You can tell they've made some questionable decisions when
| you try to use Gnome on very weak hardware.
|
| On an old dual-core Celeron w/ 2GB memory I found it
| unusable. KDE--which, when I first started using Linux
| desktops on machines less than 1/4 that powerful, was
| noticeably heavier than Gnome--was a little slow but
| basically fine.
|
| To my eyes gnome also drops frames like crazy (like, even
| for Linux, which is a pretty jittery environment to begin
| with) even on excellent hardware--not sure, but I think
| it's a reasonable guess that's also a symptom of sprinkling
| a scripting language all over the system without
| _incredible_ levels of discipline to make sure it 's never
| in the way of anything important.
|
| Webtech strikes again.
| emptysongglass wrote:
| But it _can_ be with a touch of Pop Shell! It comes out of
| the box in Pop!_OS, which is Ubuntu plus GNOME plus extra
| features.
| vcxy wrote:
| I never use GNOME but I decided to try it to test pop shell
| awhile back. This was shortly before 1.0 of pop shell so it
| could have changed. Not trying to disparage it, just
| sharing my experience as an i3 user. It feels so so slow
| because of animations.
|
| I googled how to get rid of animations because it wasn't in
| the GUI settings. Animations were removed, but a delay
| remained with any tiling movements where an animation would
| have been. Not sure if this is a limitation of GNOME or a
| bug in pop shell, but it wasn't going to work for me. It
| would be really hard to give up the snappiness.
| xfalcox wrote:
| I went full wayland a few months ago, at first on Ubuntu.
|
| Now, I'm using the early days of the Manjaro Sway Community
| edition, and it's basically everything that is described in this
| post packaged and pre-configured out of the box.
|
| https://github.com/Manjaro-Sway/manjaro-sway/
| whalesalad wrote:
| At the end of the day what is the benefit to the layman of being
| 100% pure wayland?
| colingw wrote:
| The benefit most noticeable to me is the faster user interface.
| sprash wrote:
| In my experince X11 is faster (as in latency) when run
| without any compositor.
| silon42 wrote:
| This seems critical.
|
| Could be fixed by turning off vsync?
| sprash wrote:
| Not entirely. Despite the fact that no available Wayland
| compositor allows you to disable vsync at this point
| Wayland also throws away all the work done by ddx drivers
| on X11 implementing 2D acceleration. This allows X11
| clients to de-facto render to directly to the frontbuffer
| when no compositor is in use. It is the lowest possible
| latency you can get.
| cycloptic wrote:
| In theory there could be a Wayland implementation that
| loads Xfree86 drivers, but why? Going forward, the
| implementations that want high performance and low
| latency (i.e. VR/XR interfaces) are likely going to
| target Vulkan, and you will likely never want to disable
| vsync there.
| bitwize wrote:
| DDX is deprecated in favor of GLAMOR for acceleration.
| Which roughly matches the story on Wayland: use OpenGL on
| the GPU for acceleration.
|
| Then again, Xorg is effectively deprecated in favor of
| Wayland...
| husam212 wrote:
| I noticed some weird bugs with clipboard sharing, a pure
| wayland setup avoids such quirks.
| dtx1 wrote:
| * Security Benefits, maybe!
|
| * No more screen tearing
|
| * Multiple Displays with multiple different refresh rates, on
| some compositors (sway can do it!)
|
| * HWVideo Acceleration for firefox (on some setups)
|
| * it can be faster in some situations
|
| * In the future: More likely support for HDR, VRR etc.
| gspr wrote:
| Nice bonus I didn't expect when moving to Wayland: my
| touchpad magically started behaving waaaay more nicely.
| babypuncher wrote:
| > Multiple Displays with multiple different refresh rates, on
| some compositors (sway can do it!)
|
| Does this mean we can get VRR on our primary display without
| having to completely disable other monitors when playing
| games?
| vially wrote:
| Yes, I've been doing this on sway for a couple of months
| now without any issues.
| dtx1 wrote:
| Try it, it could potentially work in Sway, i don't have a
| VRR card but multiple refresh rates on different displays
| works there
| [deleted]
| nitsky wrote:
| Wayland fixes a number of long standing issues with X,
| including:
|
| * No screen tearing.
|
| * Better hidpi support including different scale factors on
| different monitors.
|
| * Improved security, because clients do not have access to all
| state on the server and servers do not run as root.
|
| Separately, I like how with Wayland the compositor is also the
| server, so from a TTY you can enter a desktop environment by
| running a single executable with a single configuration file.
| jude- wrote:
| What happens to your graphical programs when your compositor
| crashes? At least with X11, if your window manager crashes,
| your programs keep running (you'd just fire up the WM again).
| colingw wrote:
| Sway (the window manager) _is_ the compositor. There is no
| need for a separate program like compiz or picom.
| sprash wrote:
| Which is a mistake. On X11 the server, window manager and
| compositor are three separate programs. Both window
| manager and compositor can individually crash, started,
| stopped and replaced at runtime without any of the other
| running X11 client instances affected.
| ubercow13 wrote:
| On the other hand on X11, Xorg cannot crash without the
| X11 client instances being affected - a much larger chunk
| of code. It's only because Xorg is older that that
| doesn't happen much.
| sprash wrote:
| A chunk of code that is running in production for more
| than 30 years and should be considered battle tested. In
| my experience Wayland compositors crash much more often
| than X11 despite the supposed reduced complexity. The
| last time X11 server crashed on me was in 2004 if I
| remember correctly.
| ubercow13 wrote:
| Exactly, that reliability of Xorg is a function of its
| age and doesn't imply anything about the correct design
| of a Wayland compositor. What's the chance those Wayland
| crashes were in the window management code rather than
| the rendering, protocol, clipboard, and drag/drop
| handling code? dwm is 2000 SLOC to Xorg's 1 million or
| so. I don't think splitting out the WM code would have
| gained much.
| sprash wrote:
| You underestimate the inherent complexity of Wayland. As
| exercise I recommend to implement a "Hello World" native
| Wayland client. Watch and see the complexity explode when
| you simply want to add the functionality to take
| screenshots to that client.
| cycloptic wrote:
| I'm not sure what kind of "Hello World" clients you're
| comparing, but if you check the Wayland backends in
| Gtk/Qt, you will actually find them to be smaller than
| the respective X11/XCB backends there, for various
| reasons.
| jude- wrote:
| Yes. That's the problem. Not only is the resulting stack
| less resilient to crashes, but also it takes away
| flexibility by needlessly welding together two orthogonal
| design concerns (window management vs rendering). Sway is
| like putting X11, the window manager, the global hotkey
| daemon, screenshot grabber, and so on, all into the same
| address space. What could possibly go wrong? /s
|
| Regarding security, I'm honestly surprised no one has
| just tried to make it so you can "firewall" X11 programs
| from one another. Like, aren't keystrokes propagated as
| packets sent through an X11-owned UNIX domain socket in
| /tmp? Can't we just attach a policy to that socket to
| decide which PIDs (or process groups, session groups,
| containers, etc.) get to see which messages?
| sprash wrote:
| > I'm honestly surprised no one has just tried to make it
| so you can "firewall" X11 programs
|
| This can be done via firejail[1] + xpra/xephyr but is a
| rather cumbersome endeavor. The X11 standard also
| contains access control hooks that allow you to
| "firewall" any aspect of your application. However it is
| used by no application I personally know of and is
| rendered useless by how the xinput mechanism is
| implemented at this point.
|
| The reason nobody bothered to deal with this so far is
| that people almost never run untrusted software on FOSS
| systems which is what X11 primarily targets. There was no
| demand.
|
| 1.:
| https://firejail.wordpress.com/documentation-2/x11-guide/
| cycloptic wrote:
| The demand there would be with products like Qubes and
| Subgraph, which are currently using Xephyr and Xpra.
| Eventually Wayland should be able to improve performance
| there, and bring some of the security benefits of those
| setups to other distributions.
| jude- wrote:
| Seems to me that firewalling X11 programs from one
| another would take a lot less work and be a lot less
| disruptive than requiring users to run multiple VMs with
| multiple X11 servers and/or replace the whole graphics
| stack.
| cycloptic wrote:
| Maybe that's true if that's your only concern, but there
| are other reasons to replace X11 than just this.
|
| Also, X11 is arguably not the whole graphics stack, at
| this point the DRM/Mesa piece is much larger and more
| significant, and Wayland doesn't replace it outright
| anyway -- it makes it optional if needed for backwards
| compatibility, in the same way that macOS has XQuartz.
| jude- wrote:
| The other two concerns in GP are no screen tearing, and
| better hidpi / multi-monitor support. Is it truly less
| work and less disruptive to address these to concerns
| within X11 than it is to throw X11 out (and also leave
| all nvidia users high and dry)? Also, keep in mind that
| throwing X11 out and replacing it will take more than
| just technical legwork -- it will also take ecosystem
| buy-in and standardization, and if we're being honest
| with ourselves, this is the _harder_ problem. Recall that
| the X11 ecosystem has a 30-year head start on this, and
| there 's a crap-ton of 3rd party software that assumes an
| X11 environment that Wayland is going to need to emulate.
| If X11 does indeed go the way of the dodo, I think we can
| reasonably expect another 30 years of bug reports in the
| form of "Fuck Wayland! I upgraded to Wayland and my
| $IMPORTANT_THING broke!". I very much doubt that at the
| end of the day the switch to Wayland is going to be
| overall easier than just fixing X11, but would love to be
| convinced otherwise.
| cycloptic wrote:
| The usual way to fix other concerns like that has been to
| add more WM atoms or add more X extensions, which is a
| similarly uphill battle requiring buy-in and
| standardization, and typically old X clients just won't
| be updated to support those new things. The way to get
| the most value out of such things would be to add support
| to the major toolkits, but those have already been ported
| to Wayland for some years now.
|
| The backwards compatibility is done through XWayland
| which functions similarly to XQuartz, in that it is just
| the Xorg server running using Wayland as a backend
| driver.
| tux1968 wrote:
| Trying to shoehorn proper security into X11 would be a
| formidable effort and still be quite disruptive to client
| software.
|
| Back when Wayland was just being proposed there were not
| a lot of developers working on X. They almost-unanimously
| agreed that it was time to break with backward
| compatibility and eject a lot of cruft that had built up
| over the years, such as the horrible font handling.
| Modern toolkits had already started moving away from
| using many of these X11 facilities and were doing much
| more client side anyway. So the argument was that a
| relatively clean slate design was called for which should
| dispense with the cruft and better handle client-side
| rendering.
|
| It's not perfect and I know it is disruptive for some
| people, but at least here it has led to a much better
| experience for some years now.
| jude- wrote:
| Would addressing the "firewalling" issue be _more_
| disruptive than throwing out X11? Because, Wayland
| definitely firewalls programs (among many other things)
| -- surely just implementing firewalling in X11 is not
| nearly as difficult or disruptive? Implementing
| firewalling could even be done in an incremental way that
| 's easily reverted or tailored to individual apps and
| users.
| tux1968 wrote:
| I'm no expert in the X11 codebase, but I have lots of
| respect for the guys who were working on it at the time
| the Wayland direction was undertaken. So I don't feel in
| a position to second guess their opinion or tremendous
| contributions, especially since it has led to a much
| better experience than I ever had with X.
| kelnos wrote:
| > _Regarding security, I 'm honestly surprised no one has
| just tried to make it so you can "firewall" X11 programs
| from one another._
|
| The response I've heard to this question is entirely
| nonsensical: it could be done with an X extension, but
| getting adoption from various parties to make this work
| would be difficult. As if building an entirely new
| display system doesn't require orders of magnitude more
| work and buy-in.
| chousuke wrote:
| It's a theoretical problem. The window-management parts
| of sway are tiny and having them in the same process
| means you don't have to do IPC every time your windows do
| something. That simplicity means it's easier to write
| code that doesn't crash.
|
| Most of the heavy-lifting is done in wlroots anyway.
| wlroots based compositors really do implement just their
| own flavour of _compositing_ what you see on the screen
| on top.
|
| That said, you still can use IPC, if you really want to;
| I have an external window manager that augments Sway's
| tiling system via its i3-compatible IPC mechanism to
| arrange my windows in a way that Sway doesn't do
| natively. If you really wanted to, there's nothing
| stopping you from writing a wayland compositor that uses
| an external window manager.
|
| At any rate, I don't buy the reliability argument at all.
| I've used sway since 0.10 or something, and I only ever
| remember crashing it _once_ , and I fixed that bug
| myself. :P
| jude- wrote:
| I'd say it's a very practical problem. Why put N
| different things that used to run in separate protection
| domains into the same protection domain? Have we gotten N
| times better at writing code that doesn't crash? Do we
| believe that we can put N different things into the same
| address space but somehow ensure that a security hole in
| one of them won't compromise all of them? Have computers
| gotten so slow in the last 30 years that doing IPC is no
| longer an option?
|
| I'm glad that you have personally not encountered a crash
| in Sway -- I really, truly am. But let's not pretend that
| a data point of 1 indicates a trend.
| cycloptic wrote:
| In practice, placing everything in one process seems to
| reduce the total attack surface. There is quite a lot of
| code required to synchronize state between the X server,
| window manager and compositor. When you combine them, you
| can throw out most of those bits that are largely
| serialization/deserialization.
| jude- wrote:
| > In practice, placing everything in one process seems to
| reduce the total attack surface.
|
| Surely you're joking. Privilege separation [1] is a thing
| for a reason.
|
| If we believed that putting different things into the
| same address space made them more secure, then why stop
| there? Why not just put the kernel, the shell, X11, your
| HTTP server, and everything else into the same address
| space? Let's just do away with processes -- let all
| schedulable units be threads that can all read and write
| to each other's memory, because what could possibly go
| wrong? /s
|
| [1] https://en.wikipedia.org/wiki/Privilege_separation
| cycloptic wrote:
| There is no real security boundary or privilege
| separation in that case, the window manager and
| compositor are getting full access to the screen and the
| input devices and all the client windows. That's part of
| the reason why it doesn't make much sense to keep them
| separated, I know you were joking but it's true: they
| might as well be threads, it saves you the
| serialization/deserialization step.
| jude- wrote:
| In Wayland, a fail-stop bug in the window management
| logic will now bring down your compositor and every
| program that was connected to it. In X11, a fail-stop bug
| in the window management logic only crashes your window
| manager -- everything else keeps running. This is a
| really nice property to have -- in general, why make the
| "blast radius" of a fail-stop bug bigger when we don't
| need to?
|
| Like, what's the upside of making it so a bug in the
| window management logic can crash the entire GUI? You
| claim latency due to no need for
| serialization/deserialization across process boundaries,
| and you claim potentially less-complex code. I'm very
| skeptical about the complexity reduction -- you're
| replacing the IPC with global state guarded by critical
| sections which your threads all need to respect I agree
| that there is measurable latency, but if it's a
| difference of only a few extra microseconds -- i.e.
| something the user won't notice because computers are
| insanely fast these days compared to when X11 and window
| managers were first written -- then I'm disinclined to
| give up my crash resilience. Do you have data to show
| that there is noticeable, irreducible performance lag in
| having a separate window manager process from a
| compositor?
| hawski wrote:
| I hear you, but a compositor could be multi-process - it
| was not yet done, but in time it will be.
| MayeulC wrote:
| Well, the same as when X11 crashes, which happens... Apps
| lose their connection to X11 and kill themselves promptly,
| usually.
| yes_but_no wrote:
| Also better gesture support for touchpads
| hawski wrote:
| How?
| gens wrote:
| Screen tearing under X11 is more or less not a problem
| anymore. HIDPI, yes, but only for multiple monitors (maybe
| even just programs that don't support it properly ?).
| Security... eh, yes and no (Xorg can be ran as a normal
| user).
|
| The actual good thing about Wayland is that it simplifies
| things. While the bad thing is that it needs some kind of
| extensions for even the basic things a desktop needs, and
| that (AFAIK) freeGNOMEdesktop is in charge now.
| pengaru wrote:
| > Screen tearing under X11 is more or less not a problem
| anymore.
|
| For GLX/DRI clients where there's an actual concept of
| swapping buffers w/vsync, sure, but for classical X clients
| this is not true.
|
| X got extensions for double buffering at one point, but
| practically nobody uses them.
|
| There is no concept of a "completed frame ready for
| presentation" in core X, there's no way to really fix this
| without ceasing to be X (hello, Wayland). X compositors
| literally just drain event queues of X requests and throw
| shit on-screen when the event loop gets around to it. If
| that presents a partially updated window, so be it.
| GTK+/GNOME folks added "frame clocks" to try work around
| it, but not everything is a modern-ish GTK+ app, nor do all
| compositors implement it.
|
| If there's anything Wayland fixes that really required such
| an upheaval to fix, it's flicker/tear-free compositing.
| gens wrote:
| Well, it seems to work fine (xorg.conf tearfree option,
| that is). AFAIK wayland compositing also has the problem
| that clients don't know when they should be done with
| rendering, as in when the flip is going to happen. I
| don't know much about how it (wayland, DRI) actually
| works (as in, can the "client" just render where the
| compositor told DRI it should without involving the
| compositor, or does it have to tell the compositor when
| it rendered).
|
| GNOME3 had(has?) many a timing problems.
| pengaru wrote:
| If Wayland is throwing partially constructed buffers on-
| screen, it's the client's fault for submitting them
| unfinished.
|
| In X, there isn't really a concept of what a completion
| boundary is. The client asks stuff to be drawn, the
| display server gets around to it when it gets around to
| it, and makes the changes visible willy-nilly,
| _eventually_ becoming consistent with the client state.
|
| If you look at the source for xcompmgr, the event loop is
| pretty simple and clearly schedules repainting the root
| window with all newly received damage updates whenever
| its X socket is drained of new events [0]. This is a
| pretty arbitrary boundary to perform redrawing on;
| process scheduling, socket buffer sizes/limits, it's not
| well controlled at all. The way this is done it will make
| visible whatever damage events managed to get into this
| timeslice. If that results in only part of a window being
| updated, with the rest of the damage part of that "frame"
| arriving in the next timeslice, POOF, there's a tear.
|
| [0] https://gitlab.freedesktop.org/xorg/app/xcompmgr/-/bl
| ob/mast...
| cycloptic wrote:
| There is a wayland protocol called presentation-time
| that's supposed to provide precise timing information to
| clients, GNOME just merged support for it two days ago: h
| ttps://gitlab.gnome.org/GNOME/mutter/-/merge_requests/148
| 4
|
| (AFAIK random clients should not really be using this
| though, the intent is for it to get used internally by
| the GL/Vulkan implementation)
| stevepike wrote:
| Can you explain the screen tearing thing? I'm running kwin on
| X and I don't notice any screen tearing (including doing
| things like moving windows around rapidly with the "wobbly
| windows" effect on).
| MayeulC wrote:
| That is because you use a compositor, which composites the
| screen in a separate buffer before presenting it. But in my
| experience, there were some edge cases where something like
| videos would tear.
| levesque wrote:
| One huge drawback for me is no support for proprietary NVidia
| drivers.
| Rovanion wrote:
| News just came out they will support it in the next release.
| TobyBrull wrote:
| Care to share a link? I could only find this: https://www.p
| horonix.com/scan.php?page=news_item&px=NVIDIA-D... ? That's
| already a couple month's old, though.
| wmf wrote:
| https://www.phoronix.com/scan.php?page=news_item&px=NVIDI
| A-4...
| justaguy88 wrote:
| Thats not wayland though, that the choice of the
| implementation.
| hawski wrote:
| To a layman none or almost none direct benefits. But there are
| non-direct benefits like those listed by sibling comments.
| However it will, in longer term, simplify work for developers,
| while in short term it will be or rather it is a complication
| in the transitional phase.
|
| It is an evolutionary step for end users, there is no
| revolution really. What is the benefit to a layman of a program
| to change bogies in all trains? He doesn't care about
| regenerative breaking, so smoother ride? But until almost all
| of his rides are on this newer platform he would not see a real
| benefit. Then when it is finally there he will only see its
| absence. Same with Wayland.
| pimeys wrote:
| I've been using sway a few years already: first in the office
| workstation with AMD card with Arch, then on my home ThinkPad T25
| on NixOS and again on my hobby/travel ThinkPad X230 on FreeBSD
| that works so smooth and fast now. What's left on xorg/i3 is the
| workstation with an nvidia GPU, that'll be replaced to an AMD
| card when the prices come down a bit.
|
| I'm super happy with sway. It's adding all i3 patches into one
| coherent setup. The community is friendly and helpful and the
| desktop super snappy and pleasure to use from old laptops to
| extremely fast workstations.
|
| Thank you for the developers and community.
|
| Edit: dotfiles here https://github.com/pimeys/nixos
| MayeulC wrote:
| Very thoughtful guide. Don't forget to launch dbus and policykit
| is all I can add.
|
| I've been using sway daily for about two years now. Here are my
| current gripes:
|
| - Sometimes, client applications do not receive input anymore
| (mouse/keyboard). This has been a known issue for a while, but I
| still experience it.
|
| - `dpms off` started to crash my AMD-powered PC some time ago,
| annoying when I configured it to happen with `swayidle`
|
| - Sharing screen in browsers worked extremely well... last month
| or so, when it finally got turned on in Firefox. I didn't change
| my config, but it isn't working anymore. The handshakes happen,
| but Firefox or OBS display nothing with xdg-desktop-portal
|
| Minor gripes:
|
| - Some Wine (proton) games have trouble getting focused (Sins of
| a solar empire launcher, Evochron mercenary, IIRC). Other play
| funny, with screen resolution and mouse coordinates (ashes of the
| singularity, I think).
|
| - I launch it with `sway`. After Sysrq+R, I often terminate sway
| by mistake by pressing Ctrl+C
|
| - Very occasional (once every 200 hours or so) crashes. Probably
| because C.
| ubercow13 wrote:
| >Some Wine (proton) games have trouble getting focused
|
| This is fixed on master for me, but not released yet.
| josteink wrote:
| Off topic, but still...
|
| > Alacritty, a modern terminal that "just works"
|
| I find alacritty's slogan funny, because it's literally the only
| terminal emulator I've used which has been so full of bugs that I
| found it _didn 't_ work for me and I stopped using it.
| Koshkin wrote:
| Marketing 101. (I once saw a brand whose product tiers started
| with "Premium" at the low end.)
___________________________________________________________________
(page generated 2021-03-10 23:02 UTC)