[HN Gopher] Firefox Is Going to Try and Ship with Wayland Enable...
___________________________________________________________________
Firefox Is Going to Try and Ship with Wayland Enabled by Default
Author : AdmiralAsshat
Score : 110 points
Date : 2023-11-15 19:31 UTC (3 hours ago)
(HTM) web link (www.phoronix.com)
(TXT) w3m dump (www.phoronix.com)
| anonymouskimmer wrote:
| I'm just a regular user who hardly ever touches a terminal
| window. I have a 10+ year old laptop and am running Ubuntu 20.04
| LTS and am running X11. How will this affect me?
| slowbdotro wrote:
| You are running X11. So it won't affect you.
| anonymouskimmer wrote:
| Thanks.
| SkyMarshal wrote:
| I didn't even realize desktop applications could/should implement
| the Wayland protocol. I thought it was just WM's (and some DE's?)
| that needed to do that, basically anything that directly replaces
| X, but not the apps running on it. Is this something every Linux
| desktop application will need to do?
| TacticalCoder wrote:
| I'm confused too so I upvoted you.
|
| Any information most welcome.
| tapoxi wrote:
| tl:dr an app connects to the Wayland compositor (like an X
| server) and sends it draw commands using the Wayland
| protocol. The compositor accepts these connections on a Unix
| socket, /run/user/1000/wayland-0 by default
|
| The protocol is defined in the libwayland library. Most apps
| don't use libwayland directly, but their widget toolkit like
| GTK or Qt does it for them.
| blibble wrote:
| at the risk of appearing pedantic: whereas a large chunk of
| X11 is dedicated to draw commands (circle here, line here,
| pixel here): wayland doesn't have any
|
| instead it's all shared memory buffers
| Quekid5 wrote:
| For most applications it's usually enough that the toolkit
| (GTK, Qt, whatever) supports it. However, Firefox probably does
| some stuff 'outside' what GTK provides, so it needs to
| implement those bits itself. I'm guessing stuff like <video/>
| support.
|
| (Wayland is a set of protocols and the toolkit may not support
| all the protocols or have sub-par support -- in which case the
| application can choose to do those bits itself.)
| treyd wrote:
| Accelerated video decoding is an example. It uses VA-API or
| VDPAU to decode video onto a surface that is then composited
| into the final frame entirely on the GPU.
| HansHamster wrote:
| Usually, the UI toolkit (gtk, qt, ...) should take care of the
| X11/Wayland protocol details. But if the application is doing
| its own thing or at a lower level (and I guess Firefox
| qualifies) then that has to be adapted.
| thedaly wrote:
| Firefox, pretty much all electron based apps, there are lots
| of applications that seem to interface directly with wayland.
| zahllos wrote:
| Yes this is exactly the case here. Many applications get this
| for free because the gui toolkit provides the abstraction -
| both Qt and Gtk exist to do this for cross platform purposes.
|
| However if you want things toolkits don't provide then you
| need to talk to the underlying API yourself.
|
| My distro ships both plain Firefox and firefox-wayland. I've
| been using it for... At least a year. No noticeable
| difference to normal Firefox.
| fayalalebrun wrote:
| Yes, desktop applications need to implement the Wayland
| protocol in the same way they need to implement the X protocol.
| There is a compatibility layer called XWayland which allows you
| to run Xorg programs under Wayland.
|
| However, running programs under XWayland comes with issues such
| as lack of proper fractional scaling. This means that although
| not strictly necessary, from a user's point of view it is
| desirable to have applications move to Wayland.
| pengaru wrote:
| XWayland is a compatibility interface for X apps to still work
| on Wayland compositors, so it's not mandatory to port
| everything over to Wayland.
|
| But there should be performance and rendering quality
| advantages to speaking Wayland natively.
|
| Core X for instance has zero concept of a frame or buffer
| swapping, X apps like games generally get that via GL. So your
| average X GUI application tends to be inherently flickery/tear-
| ful, since draws just get sent out to the X server and display
| whenever. XOrg drivers have implemented various hacks to try
| minimize those effects, but it's all very vendor-specific[0]
| and never perfect since it's a fundamental limitation of the X
| protocol. You can at best eliminate literal tearing[1], but
| nothing prevents displaying a partially refreshed window full
| of changing widgets, each implemented as X subwindows in the
| classic X fashion, because nothing in the core protocol says
| "Ok, this top-level window update is finished, present it (and
| its descendants)!".
|
| That's not even getting into the issues of high dpi and
| fractional scaling...
|
| [0] https://manpages.debian.org/bookworm/xserver-xorg-video-
| inte...
|
| [1] https://en.wikipedia.org/wiki/Screen_tearing
| vidarh wrote:
| Most X servers implement the Xdbe extension for double
| buffering with clients that supports it, or you can just
| render into an off screen pixmap first. In other words, if
| there is tearing or flickering, it's really entirely the
| clients fault for just blindly _choosing_ to render straight
| to the window.
| bitwize wrote:
| But with Wayland you don't actually have to do anything to
| get flicker-free, tear-free output because Wayland was
| designed with these goals in mind.
| vidarh wrote:
| Of course you do: You need to allocate a buffer, and you
| need to commit it to the visible display, exactly the
| same amount of work to do so under X. If anything, I
| suggest you look at the sheer amount of code required to
| put _anything_ on screen with Wayland vs. X - Wayland
| requires a lot of boilerplate, as the presumption is that
| everyone would use a widget library.
|
| As far as design goes, Wayland is absolutely awfully
| verbose for no good reason.
| MaxRegret wrote:
| Desktop applications can continue to use the X11 protocol, but
| then they'll be talking to the Xwayland server, which in turn
| Wayland to actually draw its clients' windows on the screen.
|
| But it's preferable to have applications directly use the
| Wayland protocol, which is what Firefox is experimenting with.
| For most applications, this is easy because they use some
| standard toolkit like GTK or Qt, which will transparently use
| Wayland without the application caring about it. But Firefox
| uses its own toolkit, so it's a bit more work.
| treyd wrote:
| > Is this something every Linux desktop application will need
| to do?
|
| The idea is that GTK+ and Qt can (and do) add support for
| Wayland and it's trivial for applications to support Wayland,
| often without even recompiling.
| bitwize wrote:
| Yes, Wayland is a display protocol that applications need to
| speak in order to display on a Wayland server.
|
| Applications built for X can still run on Wayland via Xwayland.
| But Xwayland is a bodge to allow legacy applications to
| continue running, an interim solution while toolkits,
| libraries, and applications are converted to use Wayland
| directly. To paraphrase the hit song: Once we
| have enough Wayland software At our call, hackers, at
| our call, We'll throw out those dirty X code paths,
| Ever more, hackers, ever more.
| Bu9818 wrote:
| Lots of games won't ever be converted to Wayland (maybe some
| unofficially by replacing libraries with updated ones that
| still work with the game), we'll need some nested X server
| like xwayland in rootful mode once wayland compositors remove
| their xwm.
| bryanlarsen wrote:
| Huh, I didn't realize it wasn't the default already.
| `MOZ_ENABLE_WAYLAND=1` in /etc/environment to enable. Seems to
| fix a flashing issue I'm seeing.
| kruuuder wrote:
| I didn't know what Wayland is, but was curious what this article
| is about. I read the article, and it doesn't explain what Wayland
| is. So I googled Wayland and read the start of the Wikipedia
| page. Ok, so Wayland "is a communication protocol that specifies
| the communication between a display server and its clients, as
| well as a C library implementation of that protocol." and so on.
| Huh. I now know have a very, very vague idea what Wayland is.
| What does that have to do with a browser? How can Firefox "ship
| with Wayland"? I think I have learned nothing. I feel stupid.
| Tech news is weird sometimes.
|
| Edit: Thanks for all the responses. But I'm still not
| understanding what all this has to do with Firefox. I boot up my
| linux machine that runs KDE, I launch Firefox and then what? Does
| this help with something on my local machine? Or does Firefox now
| provide a UI for remote systems that I SSH into? Whatever Firefox
| can do now, why should this be a feature of a _browser_?
|
| Edit 2: Ah, I get it now, Firefox simply renders itself using the
| Wayland protocol, correct?
| bfdm wrote:
| I only know it as the thing that broke all my screen capture
| tools because none of them had implemented the necessary
| changes the last time I tried, admittedly small N years ago.
| starttoaster wrote:
| This is how most of us casual linux users learned about
| Wayland.
| mgbmtl wrote:
| To be fair, for such a huge change to how we use Linux on
| the desktop, worst things could have happened.
| doublepg23 wrote:
| Yeah while Wayland still has some warts it seems like
| people say "I don't have proper color management on
| Wayland" with the same enthusiasm "This GNOME Wayland
| session crashes on boot" from a nearly a decade ago.
| aidenn0 wrote:
| This Plasma Wayland session crashes (in my GPU driver):
|
| - 3 years ago
|
| - 1 year ago
|
| - 6 months ago
|
| The biggest issue I have with Wayland is that it requires
| a lot more out of a GPU than a framebuffer, and my
| experience with video drivers on Linux is that they are
| very buggy and not maintained for very long.
|
| I have an older computer that I can run Xorg with
| compositing disabled and firefox with GPU rendering
| disabled. As far as I can tell I will _never_ be able to
| run Wayland on it without changing the GPU.
|
| Similar issues with some ARM based SBCs; they have
| varying levels of stability in their graphics
| acceleration capabilities, and often only on a very old
| kernel, but I can get a reliable framebuffer on mainline.
| FirmwareBurner wrote:
| Screen capture works with the built in tools. What isn't
| guaranteed to work out of the box is screen sharing apps.
| dsr_ wrote:
| Wayland is a replacement for X11 which is now ten or more years
| old and still not feature complete. It will be the future of
| all graphical interfaces, or maybe we will still be running X11
| with extensions in 2050.
| vidarh wrote:
| I remember when GGI[1] was the future of all graphical
| interfaces. Remember GGI? 1994-2007 RIP.
|
| Wayland looks a bit more likely to achieve its goal, but
| we'll see. For my part, it'll take a long time yet before
| it's worth the hassle to consider switching.
|
| [1] https://en.wikipedia.org/wiki/General_Graphics_Interface
| yobert wrote:
| Wayland is a piece of the linux desktop software stack. If
| you're on a Mac or Windows, it won't mean anything to you.
| Linux historically has used X11 for drawing the desktop.
| Wayland is a replacement for X11. It's big news because it's
| been a long time coming, and fixes a lot of longstanding
| issues. Unfortunately it also creates some new issues (screen
| sharing, hot key apps, etc), but they're being actively worked
| on and are very close to being completely solved.
| debugnik wrote:
| > it also creates some new issues (screen sharing, hot key
| apps, etc), but they're being actively worked on and are very
| close to being completely solved.
|
| I swear I've been reading this for a decade.
| aneutron wrote:
| This a Linux thing.
|
| Essentially, in an operating system you need a way to "draw"
| things on the screen. And a way to properly "move" the boxes
| "draw".
|
| Previously, the usual* way to do that was using XServer (XOrg).
| Now you would imagine that the server would take commands from
| applications, and would draw them. But it was the inverse (for
| various historical reasons)! However, the most egregious thing
| was that it ALWAYS ran as root. And while tries had been made
| to reduce the attack surface, it had to fundamentally change (I
| am skipping over other parts related to performance,
| scalability, or future proofing).
|
| And that's where Wayland comes in, and literally flips the
| whole thing on its head. Now the issue is XOrg has been around
| for maybe 40 years or more ! And that was not going to change
| easily. Distros did their absolute best to allow double use,
| but adoption grew very slowly. Eventually, supporting and
| testing for two envs will grow complicated.
|
| Anyway long story short, almost everything about Wayland is
| better IMO, actively supported and is the future. But migrating
| to it has been complicated because they were undoing 40 years
| of habits, hardcoded bugs that grew into features, and had to
| come up with new testing.
|
| This is something I typed up rather quickly so please take a
| peek at the Wiki page for Wayland you will find a much more
| complete history
| yjftsjthsd-h wrote:
| > However, the most egregious thing was that it ALWAYS ran as
| root.
|
| That hasn't really been a thing for over a decade now. As a
| decent metric, https://wiki.ubuntu.com/X/Rootless says Ubuntu
| switched to rootless by default for most drivers in
| Lucid==10.04
| dTal wrote:
| On a modern computer, programs that wish to draw on the screen
| do not interface with the hardware directly (aside from games).
| Instead, they communicate with another program that does the
| drawing on their behalf. This other program is called a
| "display server", a GUI program such as Firefox is a "client",
| and the details of the mechanism by which they communicate is
| called a "protocol".
|
| Until recently, "Xorg" was the main centralized implementation
| of a display server on unix-likes, and any program wishing to
| display graphics had to speak its native protocol, "X11". Now
| many systems run display servers which speak a new protocol,
| "Wayland"[note]. While a compatibility shim does exist
| (XWayland), ideally a program wishing to display graphics on
| such a system should do so using the new protocol directly, for
| better performance and features.
|
| Porting an application to a new graphics backend obviously
| requires some effort and testing. Until now, out of an
| abundance of caution, Firefox simply spoke the old X11 protocol
| by default, even when running on a new Wayland system, relying
| on the XWayland compatibility shim. Now Firefox is essentially
| announcing that they believe their Wayland backend is robust
| and complete enough to enable by default.
|
| I hope this helps!
|
| [note] the nature of Wayland is such that there are many
| implementations of such servers, not just one main one like
| with Xorg. This is because the semantics of the Wayland
| protocol have taken over some of the functions previously
| handled (on X11) by a separate piece of software, called a
| "window manager", which contributed heavily to the look, feel,
| and behavior of a particular desktop GUI. Thus, while Xorg was
| agnostic and could be shared by different GUIs, with Wayland
| each GUI system must implement its own display server.
| kruuuder wrote:
| Thank you!
| charcircuit wrote:
| >This is because the semantics of the Wayland protocol have
| taken over some of the functions previously handled (on X11)
| by a separate piece of software, called a "window manager",
| which contributed heavily to the look, feel, and behavior of
| a particular desktop GUI.
|
| Window managers can be separate with Wayland too. It just
| seems like the Wayland people don't want to unify under one
| implementation and have separate window managers.
| yjftsjthsd-h wrote:
| In practice, I'm not aware of _anyone_ trying to write a
| compositor for wayland that doesn 't include the window
| manager (other than xwayland, I guess).
| blindhippo wrote:
| I think this is a problem with any highly specialized or
| technical topic. I vaguely recollected what wayland was, but I
| didn't know why I would care about it and ended up doing
| similar googling before realizing this news will not matter to
| me outside of a general technical curiosity.
|
| I encounter the same thing when dealing with code reviews as
| well - people love to document the WHAT or HOW of things, but
| rarely if ever consider talking about WHY it matters, or WHO it
| matters too.
|
| To borrow from a favourite corpo speak: answer the "so what"
| for the reader to make something actually useful to more
| people.
| tapoxi wrote:
| This is about how Firefox, KDE, any app you run draws to the
| screen.
|
| In the old world, they talked to an X server that implemented
| the X protocol. It's not KDE drawing stuff to your screen, it's
| X, but KDE is a little special in that it can move windows
| around and draw title bars and borders. This is called a window
| manager.
|
| Two big issues with X, this was defined in the early 90s by a
| consortium of Unix vendors and is somewhat of an overly
| complicated nightmare.
|
| It's also a security nightmare, any app can snoop on any other
| app.
|
| Wayland is an attempt to simplify things. The server, called a
| compositor, is much simpler and is implemented as a library,
| usually by former window managers that now actually handle
| drawing stuff to the screen. Applications can no longer snoop,
| they must ask permission.
|
| If you run an older app designed for X, it uses an almost
| invisible compatibility shim called XWayland, basically a tiny
| X server that takes in X draw commands and converts them to
| Wayland ones. Firefox enabling Wayland support means that on
| most modern systems, it no longer has to use this shim.
|
| Wayland is a step forward for desktop Linux, but like any big
| change there are some annoyances. The asking for permission
| model means things like screensharing tools or apps that do
| weird shit like macros or capturing keystrokes need to be
| updated to ask permission. Nvidia didn't really support Wayland
| well until very recently because they got into some weird
| argument about driver APIs that took years to resolve.
| butz wrote:
| I'd prefer Firefox to try keeping compact view supported.
| replete wrote:
| You might like my userchrome script which is mostly about
| making the browser UI more compact and enabling multi-row tabs:
| https://github.com/replete/firefox-userchrome
| brucethemoose2 wrote:
| Firefox Wayland is still kind of iffy when I have the Nvidia
| driver enabled on either of my AMD CPU/Nvidia GPU machines.
| _Sometimes_ it doesn 't launch, among other unreproducable
| things.
|
| Of course it works perfectly if I disable the Nvidia driver. It
| also works fine in XWayland, but then rendering (to my eyes)
| looks choppier.
| whalesalad wrote:
| Firefox is one of the few apps that works flawlessly for me in
| Wayland (w/o xwayland).
|
| Slack is almost there, but not perfect. My cursor becomes like
| 1/10th the size in Slack .. but the crisp rendering is worth
| it. Dragging a PNG file into it never works though, so I always
| need to upload via the little + button.
|
| Spotify is 100% flawless, to my surprise. Even works flawlessly
| with the whole device handoff thing between iPhone, my Macbook,
| etc.
|
| vscode renders much better with wayland, like the latency
| difference is pretty significant. but... I use Toshy to get
| macos keybindings on Linux and those fail to work when vscode
| is booted in wayland mode ... so I am still suffering with
| xwayland. If I do not think about it, I don't mind lol. If I go
| back to native and see how much better rendering is, I feel
| sad.
| brucethemoose2 wrote:
| Chromium and Electron are the big kickers for me. All GPU
| acceleration is (silently) broken in true native Wayland when
| Nvidia is active.
|
| It _mostly_ looks fine until I stress the UI, and I can see
| significantly more CPU being used. In fact, I only really
| know its busted in VSCode because it spits out the same
| errors in the console as Chromium (where I can check
| about:gpu and see that everything is off).
| bootsmann wrote:
| Same here, but for me using launch options to force
| chromium apps to use wayland with ozone has fixed most of
| the issues. Pretty convinced its the combination of
| NVIDIA/XWayland/Electron that is particularly cursed.
| omnimus wrote:
| I need wayland for correct 200% scaling on one screen.
| Firefox seems to work without issues. VSCode worked for some
| time until some update. I have no idea what changed :(. Also
| its so weird that i have to launch it with some flags but
| they also show as errors... How to enable VSCode wayland is
| mystery to me.
| whalesalad wrote:
| Afaik you edit your .desktop file and pass flags to tell it
| to use ozone. --enable-
| features=UseOzonePlatform --ozone-platform=wayland
| pestatije wrote:
| every time i tried Firefox with Wayland, WebGL stops rendering
| sdfghswe wrote:
| ELI5 please?
| rstat1 wrote:
| There's 2 ways to get a window to show up on a Linux desktop,
| the old way is called X11 and the new way called Wayland. These
| protocols handle putting stuff on the screen as well as input
| from your mouse and keyboard (and touch screen if you're one of
| the 2 people that have one).
|
| Mozilla has been working toward making Firefox work with
| wayland for a while, seems they've finally gotten in to a
| shipable state.
| whalesalad wrote:
| X is the tech we have used since the dawn of time. It was
| released in _1984_ and so the architecture is not suited for
| the way modern desktops operate.
|
| Wayland is a modern replacement, but it is not a drop-in. That
| is because it has a completely different architecture and
| approach.
|
| I cannot ELI5 the differences between the two, because they are
| somewhat vast.
|
| If you are on a platform that supports Wayland, it is
| undoubtedly a smoother, prettier and overall better experience.
| This falls apart due to the lack of direct support from certain
| apps, desktop environments, etc. The migration has taken some
| time - but alas this is an open source effort in a
| massive/fragmented environment so it is obviously a very hard
| challenge. Like herding 100,000 cats.
|
| Unfortunately not everything will just work. A stopgap is
| something called xwayland which allows x apps to communicate
| with wayland - although it is not perfect.
|
| Firefox will work with Wayland. It will work with X. It will
| work with XWayland. The default though is X or XWayland. You
| normally need to explicitly tell Firefox to boot up using
| Wayland. Firefox is now considering making it enabled by
| default, which would be great for those of us who run on
| Wayland all the time. It would of course still work on X.
| scarygliders wrote:
| >> X is the tech we have used since the dawn of time. It was
| released in 1984 and so the architecture is not suited for
| the way modern desktops operate.
|
| X is a mature architecture which Just Works Fine. I don't
| know why it's considered "not suited for the way modern
| desktops operate", because as an X(org) user, all my desktops
| operate Just Fine whereas whenever I try Wayland my desktops
| do not operate Just Fine.
|
| >> Wayland is a modern replacement, but it is not a drop-in.
| That is because it has a completely different architecture
| and approach.
|
| Wayland is a newcomer and alternative to X(org) - the authors
| of Wayland want it to take over from X(org) and for X(org) to
| die off. I hope that X(org) stays.
|
| I still don't understand the hate for X/Xorg [0]. It must be
| a generational thing. Maybe I'm just being a grumpy
| greybeard? Who knows. But I do know that whenever I try, say,
| KDE Plasma (Wayland) I get problems, for example, playing
| games with WINE, and other annoying glitches and hitches
| which I don't get using MATE/Xorg.
|
| And no, I don't care if Gnome works great with Wayland - I
| have a visceral contempt for the modern iteration of the
| Gnome desktop (and had nasty experiences with the Gtk toolkit
| way back when which put me off developing with it forever.)
|
| [0] https://old.reddit.com/r/linuxmemes/comments/175chou/linu
| x_b...
| whalesalad wrote:
| Yes you're being a grumpy graybeard. Does X work? Yes. But
| so does my 32-bit Pentium III.
|
| Wasn't trying to shit on it I'm just telling it as it is.
|
| I also dislike Gnome. I run KDE on Wayland on a 5K display
| and everything is fast, low latency and gorgeous.
| aidenn0 wrote:
| Nearly all of the hate I hear for X/Xorg is from Xorg
| developers (modulo people complaining about video tearing).
| As far as I can tell they will not be contributing to Xorg
| anymore, so it's going to gradually fade away.
| reocha wrote:
| The team behind Wayland (freedesktop.org) are also the
| developers for xorg, nobody wants to work on xorg anymore
| due to architectural and codebase issues. Most of the
| commits to Xorg recently have been for XWayland, not Xorg.
| Xorg is essentially in maintaince mode.
|
| Whilst most of the newer things implemented Wayland could
| theoretically be implemented within the X architecture
| nobody wants to do it both due to the architecture of X and
| the age of the Xorg codebase.
|
| X will presumably be around for another 50 years but it
| will not receive the development needed for modern tech.
| dralley wrote:
| Fedora has had Wayland-enabled Firefox for several years at this
| point.
| christophilus wrote:
| I was about to say, I thought this was already long since
| standard, but I'm on Fedora. I didn't realize they were
| shipping a non-standard FF build.
| whalesalad wrote:
| afaik the build is not relevant - it is the configuration /
| way that ffx is started that matters (ex,
| MOZ_ENABLE_WAYLAND=1 firefox)
| scns wrote:
| Off topic, but does anyone know the status of IntelliJ on
| Wayland?
| shutty wrote:
| https://youtrack.jetbrains.com/issue/JBR-3206/Native-Wayland...
| scns wrote:
| Thanks
| slavapestov wrote:
| Wait, I'm old enough to remember when IntelliJ used Swing.
| They wrote their own GUI toolkit since then?
| hsbauauvhabzb wrote:
| I'd be interested in switching to wayland but I have good
| knowledge of x11 cli tools - xrandr, xdotool, xwininfo, etc. is
| there an easy way to migrate this knowledge and accompanying
| scripts?
| pzmarzly wrote:
| If you are scripting-heavy user, I recommend trying out one of
| WMs based on wlroots (or implementing its custom protocols).
| Core Wayland protocols are designed with security in mind,
| which doesn't necessarily let you have all the automation fun.
| wlroots protocols bring back most of X11 capabilities at the
| cost of having similar security model.
|
| https://github.com/solarkraft/awesome-wlroots is a pretty nice
| list of various CLI utils you can use. Sadly I don't think
| anyone aimed to 1:1 replicate APIs of xdotool etc, so you will
| need to change the syntax in your scripts a bit.
| hamilyon2 wrote:
| Very glad to hear that. I am guessing in December screen sharing
| on secondary, non-popular DEs and distributions will break again
| or alternatively will finally work properly?
| Toorkit wrote:
| I'm on an old GTX 1060 I got off eBay years ago. I've only tried
| Swaywm, as I'm on i3wm right now.
|
| Sway starts, but crashes within seconds. Longest I've got it to
| run was half an hour before everything froze.
|
| Do any other WM's/DE's work better for old Nvidia cards? I don't
| particularly want to start installing all the Wayland things out
| there until one works hah.
|
| I understand Nvidia isn't great for Wayland...
| joecool1029 wrote:
| I'm a sway user using a Maxwell Nvidia in an optimus config
| with an intel skylake (around your vintage, technically a
| generation older, we're both supported by current drivers).
| There's a single line patch needed for using nvidia with
| wlroots that upstream does not want to merge, if you don't have
| it screens will flicker:
| https://aur.archlinux.org/cgit/aur.git/tree/nvidia.patch?h=w...
|
| Other than that for the first time in like a decade of dealing
| with Optimus bullshit laptops off and on everything finally
| works plug and play, even running different refresh rate
| screens at the same time. Nvidia finally shipped support for
| controlling gamma in wayland on Halloween so I can use
| gammastep to shift my screens red at night.
|
| In short: Have that patch for wlroots (which sway uses), use
| newest proprietary driver, block/uninstall nouveau, and make
| sure the system isn't loading CPU rendering due to a
| misconfiguration (firefox you can check about:support,
| chromium/electron-based shit check chrome://gpu)
| jchw wrote:
| I have been using Firefox on Wayland for years now, and for the
| most part it works, well, perfectly well. It's very nice on
| computers with mixed DPI displays, I've had no issues with any of
| that. (I have run into a couple situations where dragging tabs
| has crashed, but it's too occasional to care. I just session
| restore'd and went back to work. Features like Picture-in-Picture
| work great and I even have a special setup for Picture-in-Picture
| mode so it will stick across workspaces in Sway.)
|
| I imagine there's a lot of concerns that have to be carefully
| considered, as it is a _very_ non-trivial change. Like, does
| WebGL work? Video acceleration? Will there be a performance
| regression for anything? How about accessibility, do screen
| readers still work as intended? (They should since for now that
| 's all out-of-band, but you never know.) Does it have trouble
| with any specific vendor?
|
| An interesting consequence of Wayland's design is that a lot of
| the information conveyed about X windows, like ICCCM properties,
| are basically non-existent in the Wayland world. This means that
| for a tiling window manager like SwayWM, it's actually a lot
| harder for say, pop-up windows to not accidentally get treated
| like other tiled windows. So if you use e.g. Dolphin file
| browser, the copy dialogs will try to "tile" since there's no way
| for Sway to know they're supposed to be popups. This was not an
| issue for i3wm. This is both fixable and possible to workaround,
| and in the grand scheme of things _not_ my biggest priority (I 'm
| much more concerned about issues like stability) but I think that
| issues like these are of prime concern for Wayland adoption.
| londons_explore wrote:
| > I have run into a couple situations where dragging tabs has
| crashed, but it's too occasional to care.
|
| Am I the only one to have the expectation that software I use
| should never crash?
|
| My chair holds me up every day. My fridge keeps my food cold
| every day. My windows keep out the rain every day. My washing
| machine washes my clothes every time. Why should my firefox get
| a pass to sometimes randomly crash and that be okay?
___________________________________________________________________
(page generated 2023-11-15 23:00 UTC)