[HN Gopher] HW accelerated Xwayland rendering for Nvidia merged
___________________________________________________________________
HW accelerated Xwayland rendering for Nvidia merged
Author : luigifcruz
Score : 189 points
Date : 2021-04-09 14:27 UTC (8 hours ago)
(HTM) web link (gitlab.freedesktop.org)
(TXT) w3m dump (gitlab.freedesktop.org)
| oneplane wrote:
| For those who skim the headline and wonder if this is about
| nouveau or the proprietary binary driver: it's the latter (which
| might also be why it's newsworthy).
| csomar wrote:
| How convenient. I bought an 6700XT (overpriced, crappy, and not
| yet supported) a couple weeks ago as soon as they were released.
| Having used Nvidia for Linux, I thought AMD would play much
| nicer. That was far from true, but maybe because the 6700XT is
| yet to be fully supported in the kernel.
|
| That being said, I'm now enjoying wayland. Gnome apps already
| supports wayland natively. The rendering is smooth, no tearing
| and no issues. I think the transition to Wayland will be faster
| than many here are predicting.
| maddyboo wrote:
| I bought a 5700XT back when it was first released. It would
| crash my entire system randomly, it was so bad I had to shelve
| it for a while and put my old GPU back in. It took a good few
| months for the amdgpu driver to work out the kinks, but now it
| runs fine. In the future I'll definitely avoid buying GPUs less
| then 6 months old for use on Linux, and will diligently search
| for "model# crash|bugs|glitch|unstable linux|wayland" before
| pulling the trigger.
| jrm4 wrote:
| Long time Linux (and therefore X11) user here. I'm not much of a
| programmer, more of a techy end user.
|
| I have read of the supposed benefits of Wayland, but from what I
| can percieve, the cons (too numerous to mention, but mostly
| breaking a billion useful things that X has had for some time)
| seem to out weigh the pro. Yes, the pro. Fractional scaling.
|
| I don't like actively cheering for something to fail, but _I
| really don 't get it._ X11 is in no way broken enough to justify
| such a huge change, and I'm concerned that the KDEs and Gnomes of
| the world are going to ramrod the thing through regardless.
| edflsafoiewq wrote:
| It's an old story.
|
| A conservative rewrite, that amends those things experience has
| shown were mistakes but were always retained for compatibility,
| is rare, since the impulse to rewrite is revolutionary in
| nature. A rewrite is treated as an opportunity to remake the
| world in a new image (with a new set of mistakes to uncover).
| turminal wrote:
| The problem here is that a lot of stuff X does relies on
| horribly unsafe (mis)features of X. And of course wayland had
| to break compatibility with those things.
| michaelmrose wrote:
| If the user wants to do X which involves increased danger
| to the user giving users a way to tell the system that app
| X has the privilege of doing X but not allowing all
| applications to do X is potentially viable but telling
| users you don't need to do X anymore is a much harder sale.
|
| It needn't be a prompt users will quickly be prompted to
| click yes to it could easily be an option in settings or at
| communicated at install time.
| aduitsis wrote:
| The fact that XWayland's "performance should be roughly on-par
| with native X11" probably solidifies rather than weakens the
| position of X11 as the de facto display protocol.
|
| If everything that uses X11 today can be used on top of
| XWayland without any modification and without performance loss,
| this means that a lot of pressure stemming from the need to
| switch to speaking Wayland instead of X11 is lifted in a
| certain sense.
|
| Or am I missing something?
| coldtea wrote:
| First of all, nobody cared to hack on X/Xorg. The project was
| seriously understaffed.
|
| Second, it ended a pile of hacks upon hacks.
|
| Those two reasons have to be added on top of the other benefits
| of Wayland (or any other modern re-arch of X).
| DoctorNick wrote:
| X11 is a security nightmare. It is absolutely broken enough to
| justify a huge change.
| michaelmrose wrote:
| Installing random software off the internet or from a market
| that developers have direct access to poison is a security
| nightmare that isn't much fixed by wayland.
| infoseek12 wrote:
| The main thing that has me cheering Wayland on is that it seems
| like the only, really viable, path forward for the Linux
| desktop environment. The developers of X11, and more or less
| the rest of the Linux community, decided that X11 wasn't the
| best path to take into the future. So X11 is treated like a
| legacy technology. It will keep getting patched and will be
| supported for the foreseeable future but it's hard to see
| anyone wanting to invest a lot of effort innovating and moving
| the tech forward when everyone agrees there's no future in it.
| I'm not aware of any frameworks that are really competing with
| Wayland for the next generation.
|
| There will be stumbling blocks as with any new technology,
| especially one that interrelates with so many systems but
| Waylands core architecture seems to be solid.
|
| Personally, I'm still using I3 and don't see many immediate
| benefits to switching over to Sway (the Wayland fork of I3). I
| am cheering Wayland on though and making the switch is
| somewhere on my todo list. What other path forward is there for
| desktop Linux?
| inclemnet wrote:
| > Sway (the Wayland fork of I3)
|
| Minor clarification: Sway is an i3-compatible wayland
| compositor written from scratch, not a fork.
| zaxcellent wrote:
| The issue is X11 as we know it has no developers left. If
| nobody is around to maintain it, the world will move on, no
| ramrod necessary. More info:
| https://ajaxnwnk.blogspot.com/2020/10/on-abandoning-x-server...
| sprash wrote:
| There are plenty of developers left. It is just release
| management refuses to make new releases.
| zaxcellent wrote:
| I suppose that theory is possible. A proxy for developer
| availability might be to check the primary mailing list of
| xorg for the full month of march:
| https://lists.x.org/archives/xorg-
| devel/2021-March/thread.ht.... There wasn't much directly
| related to xorg-xserver itself. As a point of comparison,
| here is March for QEMU:
| https://lists.nongnu.org/archive/html/qemu-
| devel/2021-03/thr...
| sprash wrote:
| After years of misleading propaganda about how X11 is
| "deprecated" now I would expect no less. Besides maybe
| the main communication channel for development is
| somewhere else.
| taway098123 wrote:
| Most developer activity related to Linux graphics is in
| dri-devel, it's been like this for quite a while. The X
| development channels have been mostly dead outside of
| discussion of XWayland. I doubt you'll see anyone
| starting any major new features in X.
| pantalaimon wrote:
| There are still some active PRs
|
| https://gitlab.freedesktop.org/xorg/xserver/-/merge_reque
| sts...
|
| Someone is trying to get multi-touch support merged, but
| is waiting for a review.
| taway098123 wrote:
| I hope someone comes along to review those, but I don't
| see there being much interest in it.
| dkersten wrote:
| > mostly breaking a billion useful things that X has had for
| some time
|
| This is always the case when there is some widely used legacy
| tech, but it shouldn't stop us from trying to move forward, or
| we'll never get better things.
|
| I've personally switched to using wayland on my main laptop and
| am very happy with it. I was using X before and was getting
| incredibly bad screen tearing when using i3, I tried every
| recommendation I could find (double buffering, running a
| compositor, etc) and nothing helped, but Sway on wayland fixed
| it for me and its been running flawlessly for the last 9
| months. I have no plans of going back to X anytime. The only
| thing I use X for is playing Windows games with Proton (which
| this HW acceleration change might even fix, if the laptop had
| an nvidia gpu, but alas, it does not).
| sprash wrote:
| > but it shouldn't stop us from trying to move forward,
|
| Wayland means moving backwards. It has the complete wrong
| philosophy and abstractions. If "sway" runs flawlessly for
| you you are not doing much with your computer at all. I can't
| work without my fine tuned synaptics driver configuration and
| without my over the years grown and perfected scripts using
| xdotool, dmenu, xsel, xcape, xcalib and many other tiny but
| useful x-tools.
| dkersten wrote:
| So because it doesn't work for your workflow of scripts
| that rely on X, wayland is a step backwards and I must not
| be using my computer for much? Get over yourself.
|
| > fine tuned synaptics driver configuration
|
| My touchpad, touchscreen and apple magic trackpad work
| great for me, so this isn't a problem for me.
| sprash wrote:
| Wayland is power-user hostile. If all you do is watching
| cat videos all day long Wayland will be great for you.
| dkersten wrote:
| And once again you are making completely erroneous
| assumptions about my computer use.
| dijit wrote:
| Fractional scaling is kind of the most visible thing today. But
| to be clear, there's a lot of benefits to wayland.
|
| Mostly the issues could be hacked around. But let's be
| absolutely clear with this: it is hacking around the issue.
|
| Problem: tearing, solvable with double buffering, maybe.
|
| Problem: Xorg runs as root, solvable, there's ways of making
| your user have direct control of the frame buffer device.
|
| Problem: Xorg is a network system, and a porous one, meaning
| it's possible to intercept keystrokes from any running program.
| Solvable by running a mini X11 instance for each program.
|
| Problem: Xorg is a network system, meaning it is very
| inefficient. (Imagine using TCP to talk to your SSD)
|
| Problem: Xorg needs to be backwards compatible, so it can't dig
| much into hardware features. Especially as the client may not
| be on the same machine as the server.
|
| Overall, wayland is a good clean slate, it's been in
| development a long time. X11 has major warts and they are hard
| to clear out.
| espadrine wrote:
| I'd like to emphasize a major aspect that makes the switch a
| non-brainer: SECURITY.
|
| The "good old days" of unencrypted Internet, where everyone
| could see your cookies, are no longer acceptable; the same is
| true of X11.
|
| With X11, if you _copy a password_ from your manager, you
| must assume all running apps now know it and transmitted it
| to a malicious server. There's no way to tell.
|
| With Wayland, it is only transmitted upon pasting, and only
| done directly from the copier app to the paster app.
|
| With X11, _everything displayed on the screen_ is
| compromised. Also, all inputs, keyboard and otherwise.
|
| With Wayland, each app only sees their own pixels.
|
| With X11, _screen locking_ is pure hackery that doesn't
| always protect the locked pixels and... login password.
|
| Traditionally, you are meant to trust that process boundaries
| on Linux are sacredly secure, which is why Spectre was a big
| deal. But in practice, that is only true under Wayland.
| jrm4 wrote:
| So, I see and understand these arguments in theory -- but,
| and I don't think I'm alone, none of them are actually
| pressing?
|
| I'm running Openbox/Xubuntu on a 4K monitor, doing some
| awesome equivalent-of-4-monitors work, then playing all the
| steam games I want with the Proton and the decent AMD GPU,
| all under X. "Font size is a little weird sometimes" is my
| only gripe?
|
| Put differently, I understand "hacking around the issue"
| criticism in theory -- but if you applied that sort of purity
| to, say, web programming -- step one would be, okay, first
| get rid of Javascript, an idea that I really do like in
| theory, but I know it's not happening.
| josefx wrote:
| > Xorg is a network system, meaning it is very inefficient.
| (Imagine using TCP to talk to your SSD)
|
| I am quite sure that there is something wrong with your
| system if your X clients run through the IP stack by default.
| michaelmrose wrote:
| You said Xorg is a network system twice and I don't think you
| did enough research once. Wherein client and server are local
| it doesn't doesn't communicate via the network stack. The
| problem you imagine exists only in your imagination not
| reality.
|
| I don't care if xorg runs as root and I don't need to run an
| instance of xorg per application I simply install software
| from trusted sources and haven't managed to get malware
| between 2003 and now. I also didn't have issues with tearing
| in 2003 and I don't now.
|
| Generally speaking QT and GTK and other toolkits must concern
| themselves with the details of X others concern themselves
| with QT or GTK as they would under wayland. It is extremely
| likely that all players in the overall ecosystem who never
| had to specifically worry about X in many years have had more
| issues, work, and tears from wayland development than they
| would have had for the remainder of the next century with X.
|
| This is nearly entirely about presenting a saner stable base
| to improve the work for a tiny number of people actually
| developing the graphics stack in Linux to build upon and
| unfortunately they made poor design decisions at the start
| that have led to it taking 12 years and still not being ready
| for prime time in some ways.
|
| After doing the necessary research to understand the topic
| you could construct another post about the shortcomings of X
| that is actually factually correct but it would still be
| beside the point. Wayland would still be a poor work that
| squandered a lot of the opportunity of a clean slate despite
| its authors being in perhaps the best position possible to do
| so. In 20 years Linux if it exists on the desktop will be a
| weird opaque overengineered system that works when it works
| and is impossible for an end user to understand why it is
| misbehaving when it doesn't.
|
| On the bright side due to package management the windows
| solution of pave over the install and start over could
| probably be configured to automatically reinstall all your
| software for you!
| jrm4 wrote:
| After a few years of wondering about the "why," I find this
| comment very illustrating; it feels like Wayland is one of
| many Linux related efforts (like Gnome and KDE) that are
| not particularly interested in a high level of
| interoperability and/or long term durability. Instead, the
| goal is more in the direction of trying to make their
| preferred way of things more dominant in the ecosystem.
| Now, if those efforts are _actually good at it_ then more
| power to them. But most of the time, that doesn 't happen,
| and I think it harms the Linux ecosystem, one that I am a
| fan of, overall.
| _jal wrote:
| I find it personally a bit hilarious - Wayland has been Going
| To Be Great Soon for over a decade.
|
| I've never even had a reason to want to run it.
|
| But I'm sure it'll be great, any day now.
| KeyBoardG wrote:
| From what I gather its a chicken and egg issue. Wayland
| would get more attention and development if it had more
| users. It would have more users if it had more feature
| development. Although a lot of the bigger gaps are closed
| or closing now. OBS now works on Wayland as of 03/30/2021
| and Fedora plans to ship Wayland as the default.
| toun wrote:
| I find Wayland is great already for my usage, and has been
| for the last two years. If Xorg works for you and Wayland
| doesn't, that's perfectly fine too.
| _jal wrote:
| Don't get me wrong - I would love to not deal with
| certain X warts. (I see substantially fewer warts than
| other people do, but that's just me.)
|
| It just seems Wayland's combination of technical
| requirements and political entanglements make it a sort
| of Zeno's Project, doomed to asymptotically approach
| peoples' expectations and desires, but never reach them.
| coldtea wrote:
| > _I find it personally a bit hilarious - Wayland has been
| Going To Be Great Soon for over a decade._
|
| So? The same has been the case for desktop Linux in
| general, for 2 decades.
| de_Selby wrote:
| Linux desktop has been perfectly fine for at least 1.5 of
| those decades.
| throw0101a wrote:
| > _So? The same has been the case for desktop Linux in
| general, for 2 decades._
|
| Some of us have been running Linux desktops for over two
| decades. Nothing more fun than setting Modelines manually
| for your VESA card:
|
| * https://en.wikipedia.org/wiki/XFree86_Modeline
| michaelmrose wrote:
| Desktop linux actually worked pretty well in 2003 for my
| purposes. I started on Fedora Core 1. I burned a dvd hit
| the magic key to select a boot target booted it up told
| the installer what time zone I was in and what disks it
| could use and such details and rebooted after a while.
|
| Wine sucked and there was less software existed but it
| was perfectly possible to do the normal tasks one did
| with a computer.
| edoceo wrote:
| My Gentoo/Xfce multiple monitors with Nvidia has been
| great for at least 10 years.
|
| Linux Desktop is Great. Wayland is still in the process
| of becoming great (I think it's making good progress too)
| sprash wrote:
| > Fractional scaling is kind of the most visible thing today.
|
| And also perfectly possible with X11 because the pitch
| information is exposed via the Xrandr extention
|
| > Problem: tearing, solvable with double buffering, maybe.
|
| Solved since ages. Just enable Tearfree in your Xorg.conf.
| That also shows how great X11 really is. It allows you the
| _choice_ to turn it on or off. Because Tearfree comes at a
| cost of latency.
|
| > Problem: Xorg runs as root, solvable, there's ways of
| making your user have direct control of the frame buffer
| device.
|
| OpneBSD solved that two decades ago. Also it perfectly
| possible on Linux to run X11 as non-Root.
|
| > Problem: Xorg is a network system, and a porous one,
| meaning it's possible to intercept keystrokes from any
| running program.
|
| This is a feature not a bug. The security paradigm is
| blacklisting (which means sandboxing untrusted apps) instead
| of whitelising (which means locking everything up and only
| allow the compositor to do stuff). Since the vast majority of
| Software on FOSS system is trusted X11 is the far superior
| solution here.
|
| > Problem: Xorg is a network system, meaning it is very
| inefficient.
|
| X11 runs even on 386's and beats Wayland in every performance
| metric, especially latency. After 13 years of development
| only some compositors come close to X11's performance.
|
| > Problem: Xorg needs to be backwards compatible, so it can't
| dig much into hardware features.
|
| Backwards compatibility is a major feature even 40 year old
| Software runs on current Xorg which is an impressive feat. As
| for the "hardware features": DRI3 uses the exact same buffer
| sharing mechanism as the major Wayland compositors do.
| Wayland offers zero advantage in exploited Hardware features.
| On the contrary X11 is capable of using hardware layers that
| has the effect that you can smoothly move your mouse even on
| heavy load and OOM events. Wayland still completely craps out
| in that regard.
|
| > Overall, wayland is a good clean slate, it's been in
| development a long time.
|
| It is a clean slate, but a very bad one. The wrong philosophy
| ("every frame is perfect") and the wrong abstractions
| ("everything in the universe is a buffer made of RGB values")
| make it a major step backwards in computer graphics on
| Unix/Linux.
| gspr wrote:
| I very much agree with what you wrote. I'll just add a
| comment:
|
| > Overall, wayland is a good clean slate, it's been in
| development a long time. X11 has major warts and they are
| hard to clear out.
|
| This may seem like it's irrelevant for the user. It isn't.
| Lots of things us users want are much easier and more
| attractive for developers to add to the clean slate design
| that is Wayland.
|
| For example: When I switched, an unexpected bonus I
| experienced was that my touchpad's behavior got orders of
| magnitude better. So I googled around a bit, and it turns out
| that almost all touchpad improvements just happen to occur on
| Wayland because the people who are interested in that aren't
| interested in wading through the X swamp in order to
| implement their stuff. (I mean, have you looked at the X
| code? Oh dear, oh dear, it's a daunting thing!)
| mrighele wrote:
| > This may seem like it's irrelevant for the user. It
| isn't. Lots of things us users want are much easier and
| more attractive for developers to add to the clean slate
| design that is Wayland.
|
| This is something I don't understand about Wayland. How is
| it possible that something that is supposed to be much
| easier and more attractive for developers after TEN+ years
| of development still has so many issues ?
| stinkytaco wrote:
| On the other hand, a bunch of X11 issues were just
| listed, and X has existed three times as long. Some
| issues are architectural and thus probably not solvable,
| some are just persistent annoyances that must be
| difficult to fix and likely will not get fixed because
| X11 has so little active development anymore. X has
| enough issues that a good portion of the community said,
| "we've got to fix this". And frankly, I've used software
| from multi-billion dollar corporations that gives me more
| trouble in a day than Wayland does in a month.
| devwastaken wrote:
| There are reasons, many times those reasons are obvious to
| whomever is actually implimenting the changes but not to others
| outside of it. The reasons have been highlighted hundreds of
| times and unless there's actual arguments against those reasons
| the discussion of "I don't like wayland" is a distractive
| circle that ignores the content of the original post.
| harel wrote:
| Since I switch to Wayland on Ubuntu 20.04 my laptop works
| significantly better. I don't get random hickups and slowdowns.
| Screen sharing works fine (at least on zoom which is what I
| tried, and only on the .deb package, not the snap one). I am
| aware it's not as mature as X but I'm looking forward to watching
| Wayland grow.
| pmontra wrote:
| I'm definitely not in hurry to switch from X11 (it's good enough
| for my use cases) but this is an important step to enable a mass
| migration to Wayland. I'll give it a try as soon as screen
| sharing and video conferencing work out of the box for NVidia.
| Meet, Skype, Slack, etc. If a customer of mine use something that
| doesn't work on Wayland I have to keep using X11.
| CarelessExpert wrote:
| Man, I wish it was just that.
|
| Using Qt apps under Gnome on Wayland can break in weird ways
| (e.g. in one case I saw popup menus opening in weird places or
| disappearing entirely). Meanwhile, because window decorations
| under Gnome are client side, the behaviour is weird and
| inconsistent (double-click on a Gnome titlebar and it
| maximizes, but double click on a Qt app titlebar and it
| doesn't).
|
| So maybe switch to KDE? Unfortunately, the idea of a "primary"
| display simply doesn't exist in KDE on Wayland, which is a
| major regression for multi-monitor setups. And that's setting
| aside that KDE on Wayland still crashes on a very regular
| basis.
|
| Under Gnome I've also seen apps like Guake that simply don't
| work properly due to either bugs in the compositor or
| limitations in the Wayland protocol (I'm still not sure which),
| so you need to find workarounds in those cases.
|
| In general this leads to distros not enabling Wayland by
| default in clients and toolkits, even if Wayland is the default
| display server. For example, on Debian (testing), both Firefox
| and QT require special environment variables to be set
| depending on your setup. If you don't set them, those
| applications just use Xwayland and you lose things like
| fractional scaling. Force the use of Wayland and you end up
| with a lot of the issues I mention above.
|
| Wayland is _really_ coming along. When it works, it 's smooth
| as butter and works great! Heck, I'd love to use it if only for
| fractional scaling support. But a lot of things are still very
| broken and it's still gonna take a while for things to mature.
| cycomanic wrote:
| Maybe this is a Gnome issue? I've been using sway as my main
| driver for 2 (?) years now and I don't encounter any of the
| issues that you see. I'm running with firefox and most other
| apps forced to wayland and was actually surprised how easy it
| was.
|
| The main issues I encounter are about screen sharing. At the
| moment it does not work for wayland apps (i.e. wayland apps
| don't show up in the share this). Supposedly there is a way
| around it, but I've not yet needed to investigate. The other
| issue is OBS not working (I guess also because of
| screensharing). And the third issue is some weird bug in
| Zoom, where if I open the participant or chat window, it
| becomes extremely laggy. So much so that I can't really type
| in the chat window because there is such a strong lag, that I
| finished typing before the word appears. Similarly the video
| feed becomes choppy.
|
| One other issue was that Pycharm was having issue opening
| some menus/windows but that seems to have been fixed now.
| nvarsj wrote:
| I like sway a lot, but I also encountered many bugs with
| its implementation. For example, it's drag and drop and
| focus switching randomly breaks when interacting with
| Xwayland windows. It also breaks resume/suspend if you have
| multiple GPUs. I finally went back to pure X11 and
| everything just works and is snappy. I miss the Wayland
| tear-free experience though.
| CarelessExpert wrote:
| > Maybe this is a Gnome issue?
|
| I actually listed a range of issues. Some are in Gnome.
| Others are in KDE. Yet others are in the toolkits (e.g. the
| Qt popup menu problem). And still others are in the
| applications themselves (e.g. Firefox has a whole menu of
| Wayland-specific bugs).
| igneo676 wrote:
| I had a ton of issues with QT menus until the latest
| patches from KDE hit Arch's QT packages. Fixed them
| albertzeyer wrote:
| There was an update for OBS recently, which sounds like it
| fixed the Wayland issues.
|
| https://feaneron.com/2021/03/30/obs-studio-on-wayland/
| turminal wrote:
| > Maybe this is a Gnome issue?
|
| Definitely a Gnome issue.
| michaelmrose wrote:
| By primary display do you mean new app windows are created
| there? If so you can use window rules to force windows to be
| created on a particular screen.
|
| You could put different windows on particular screens or just
| punt everything to the desired primary monitor.
|
| This functionally is also available in i3wm/sway as
| for_window and as a stand alone application under x called
| devilspie2.
| CarelessExpert wrote:
| It's a pretty common feature. Windows, Gnome/X11 and
| KDE/X11 all have the concept of a "primary" monitor. I
| believe macOS does as well.
|
| The idea is that things like the status bar, top bar, dock,
| etc, appear on the primary monitor unless configured
| otherwise.
|
| Similarly, new windows preferentially open on the primary
| monitor.
|
| This is existing functionality on all of these desktop
| environments.
|
| In a multi-monitor setup, you designate a monitor as the
| primary monitor and the desktop automatically "does the
| right thing" even if you remove and reattach the primary
| display.
|
| KDE on Wayland loses this functionality. The primary
| monitor is whichever monitor is detected first with no way
| to control it through configuration. The only workaround is
| to disable your secondary screen and then re-enable it, and
| you have to do that every time the desktop launches or the
| display configuration changes, which is a deal-breaker if
| you dock/undock regularly (or when the display server
| crashes).
|
| Might there be hacky workarounds that partially fix some of
| these issues? Maybe. But it's a major functional regression
| and I'm not willing to invest that effort (especially,
| again, given the stability issues).
|
| BTW, Gnome on Wayland preserves this functionality. But
| unfortunately, as I mentioned, Qt + Gnome leads to a whole
| host of other issues.
| michaelmrose wrote:
| Logically you would just put the same dock on both
| monitors and tell it to move all new windows to DP-2 (or
| wherever), open an issue on their bug tracker asking for
| this feature to be reinstated and explaining why, and
| move on. This wouldn't so much be a hacky workaround as
| using a built in feature that achieves the same result.
|
| In my opinion primary monitor is conflating 2 settings
| that perhaps ought to both exist in an easier to use that
| windows rules.
|
| Open new windows on ____ selected from monitor with mouse
| cursor, same window as focused application, a selected
| monitor with the default being same monitor as focused
| application.
|
| Always show panel in place of any other bar yes/no.
| Unchecked by default. You can have a panel on each
| monitor and put things of your choosing in each panel or
| even have a panel on top and below on the same monitor if
| you like. So what happens if you have a panel on your
| primary monitor 1 and also on your secondary monitors 2
| and 3? Say you unplug the laptop and monitor 3 becomes
| the only monitor.
|
| The most obvious and simple thing would be to show the
| same things on all 3 including showing a taskbar for the
| windows just on that particular monitor so that when you
| undock you can still do the same things. Windows does
| this for example the only difference is which bar has the
| tray.
|
| The most theoretically correct would seem to be allowing
| you to set different bars for different configurations
| but this would be complicated and perhaps little used.
|
| What I've suggested would be to give you the ability to
| set a primary bar that is always displayed hiding any
| secondary bars that normally appear on that display.
| CarelessExpert wrote:
| > This wouldn't so much be a hacky workaround as using a
| built in feature that achieves the same result.
|
| But there's _already_ a built-in feature in KDE /X11 for
| this. It's just broken in Wayland. It's a feature
| regression, plain and simple.
| michaelmrose wrote:
| So ask them to put it back?
| CarelessExpert wrote:
| I think you're missing the entire point of my comment.
|
| I'm not saying these things can't be resolved! They
| probably will be, eventually. I have every confidence
| that some day, KDE on Wayland will restore this now-
| missing feature.
|
| I'm simply saying, through my personal laundry list of
| bugs and regressions, that Wayland is a long way off from
| ready for prime-time due to a wide range of issues that
| go well beyond the oft cited, very well-trod issue of the
| lack of screen sharing.
|
| That's it.
|
| And I genuinely look forward to the day those gaps are
| closed and I can use Wayland full time!
|
| I just have a feeling that won't be until 2023 at the
| earliest.
| michaelmrose wrote:
| I have a feeling it will be 20never as I sit in front of
| my machine running i3wm version whatever in 2029.
| craftinator wrote:
| I'm pretty sure Wayland is never the problem, it's always
| the user. If no one used Wayland, it would run exactly as
| designed!
| azinman2 wrote:
| I'd imagine this as far as things like docks are concerned?
| But the idea that I have to write specific windowing rules
| just to use my computer suggests this has a long way to go.
| It should 'just work' out of the box.
| michaelmrose wrote:
| Just work doesn't mean it just works as you personally
| desire. It means just works in a consistent predictable
| fashion that is suitable for use not desirable for your
| taste or matching behavior on windows.
|
| Personally I expect windows to show up on the same
| monitor as the currently focused window or the cursor and
| having it pop to a primary monitor would be from my
| perspective a defect. I would have to test but I think
| that outside of gnome this is actually how the majority
| of linux environments work out of the box.
|
| You don't have set a windows rule in the settings gui
| just to use your computer. You have to set a windows rule
| in the settings gui for your computer to work in the
| fashion that you prefer. That you regard this setting as
| essential doesn't mean that it actually is just that you
| strongly prefer it.
| coliveira wrote:
| > When it works, it's smooth as butter and works great
|
| Come on, Wayland was released 12 years ago! And it still has
| all kinds of problems that don't make it qualify even for
| beta software. I'm highly skeptical that Wayland will ever be
| as useful as X11 is right now.
| eikenberry wrote:
| I take it you don't remember X11 when it was 12 years old.
| Wayland looks quite good in comparison.
| craftinator wrote:
| I think, based on the responses to your comment, that
| your comment is quite wrong. It seems X11 was completely
| functional at the time, which Wayland is definitely not
| at this time.
| wnoise wrote:
| X was 1984. X11 was 1987. Twelve years later in 1999, it
| worked just fine.
| coliveira wrote:
| Even before that. I remember installing X11 on PCs in
| 1995. And it worked much earlier than that on UNIX
| workstations.
| deckard1 wrote:
| to give you an idea of 1999, I was running Quake 3 on
| Linux with official Nvidia Riva TNT support and X11.
|
| X11 also ran fine in 1995. Granted, I think fvwm2 was
| probably state of the art for window managers at the
| time. From '95 to almost '97 or '98 I stuck pretty much
| in 80x25 or 80x40 text console. Not because X11 didn't
| work, but more so because xterm really sucked and the
| only apps you would use in X11 anyway were Netscape, Gimp
| or xv (image viewer). Gtk+ also did not exist, so
| everything was ugly Motif or Tcl/Tk.
|
| Oh, and... there was always talk of replacing X11. Even
| in the '90s. People have been talking about replacing X11
| nearly as long as X11 has been around, sadly.
| donio wrote:
| 1995 the state of the art WM was probably GWM which was
| fully programmable in a Lisp dialect. You could even draw
| your window decorations in Lisp using various primitives.
| It was never widely used though.
| eikenberry wrote:
| Sorry, I meant X. Wrote X11 out of habit. But X11 is a
| version of X, so I still think the relevant date is 1984
| and in 1996 I was still writing modelines in my X conf
| file... and at least with Wayland you don't have to worry
| about a misconfiguration frying your monitor.
| forgotpwd16 wrote:
| Then again, was there even an alternative back then?
| CarelessExpert wrote:
| In all fairness, my experience is that most of the issues
| are in the broader ecosystem at this point.
|
| Wayland, itself, is just a protocol. The display servers
| are just the display servers. But then you have Gtk and
| Gnome, Qt and KDE, software like Firefox and Chrome, etc.
| All of those have to updated as well, and while Wayland the
| protocol, the display servers, and a lot of the suite of
| infrastructure around it is in pretty good shape, the
| toolkits and clients and so forth all still need a lot of
| work.
|
| And you only need to look at the Python 3 transition to see
| how hard it is to shift a whole ecosystem.
|
| So I'm willing to cut the Wayland guys some slack. But it
| does mean there's still a ways to go, yet, before things
| are ready for prime time.
| kbumsik wrote:
| > Wayland, itself, is just a protocol
|
| That is the root of the problems IMO. The thing is, this
| design decision had made the ecosystem a lot harder to
| grow than X11/xorg.
| michaelmrose wrote:
| The perspective that wayland is just a protocol and
| doesn't need to address real issues is why it has so many
| of them to start with.
| CarelessExpert wrote:
| That I completely agree with.
|
| The folks involved in designing the Wayland protocol
| seemed to have shed a lot of key features in the name of
| simplicity or security, forgetting that the solution
| actually has to meet real, human user needs. Those needs
| include things like screenshots and screensharing, global
| hotkey binding, etc, etc.
|
| To address that, we now have a range of extension
| protocols, which is creating fragmentation. The CSD-vs-
| SSD debate is a perfect example.
|
| Things are slowly coalescing--PipeWire is maturing, for
| example, filling some key gaps--but it's taking time and
| meanwhile IMO the ecosystem continues to be too immature
| for broad adoption.
| taway098123 wrote:
| Screen sharing and screenshots weren't an afterthought.
| Weston had support for those for a long time, but gnome
| and kde decided to do something different, probably
| because they saw pipewire was maturing.
|
| Allowing arbitrary clients to globally capture keys at
| will is impossible to do without opening up a hole for
| keyloggers. Maybe someone will figure out a good way to
| do this but I wouldn't hold my breath. You're better off
| writing a compositor extension to do what you want.
|
| The CSD-vs-SSD debate isn't anything new, there were apps
| that used CSD before wayland, and there were X11 window
| managers that didn't draw any window decorations. There
| is fragmentation there but it's caused by the apps, you
| won't fix that one without rewriting all of them to have
| the same policy on decorations, probably that means
| redesigning all of them to use the same widget toolkit
| and designs.
| pantalaimon wrote:
| > Maybe someone will figure out a good way to do this but
| I wouldn't hold my breath.
|
| Android and iOS and Browsers these days already have
| figured out something for those kind of things - they ask
| for permission.
| taway098123 wrote:
| The usual place those permission dialogs have gone is the
| flatpak portal, which is separate from Wayland. Someone
| would have to implement it there.
| zaat wrote:
| > Allowing arbitrary clients to globally capture keys at
| will is impossible to do without opening up a hole for
| keyloggers.
|
| Is this feature standard on every OS in use by human kind
| today? Is this feature requested by most users and not
| having it pisses off most users? Is this feature
| available on the system that Wayland aims to replace?
| taway098123 wrote:
| All of those questions are really irrelevant. The point
| with Wayland is to make something that's more secure than
| the systems it aims to replace, not to make exactly the
| same thing. If you want to help, maybe show a way this
| can be done without poking a huge security hole?
|
| Regarding pissed off users, in my experience most
| computer users are used to Microsoft Windows and get
| pissed off when things don't work exactly like that, so
| unless you work for Microsoft then it's a lost cause
| trying to please them all.
| michaelmrose wrote:
| If you don't have any users you will soon find yourself
| without developers so it is in fact quite relevant.
| taway098123 wrote:
| That seems like the reverse of the way it's always been
| on Linux, where there are only developers and no users...
| zaat wrote:
| I'm working with i3 (on X, obviously). Perhaps I'm
| diluted but my experience is that users of this setup are
| happy about their setup and love the system they use.
|
| I don't know of any way an Ethernet device can be truely
| secured, perhaps it should be disabled until a solution
| is found. I couldn't care less about a system that is
| more secure if it massively interfere with day to day
| usability.
| taway098123 wrote:
| There's plenty of ways to securely multiplex Ethernet
| devices. You don't give your web server read access to
| all TCP ports being used by other services for example.
| You only let it open the HTTP ports. There are of course
| ways for debuggers to escape this and intercept all TCP
| packets sent by the kernel, but those require elevated
| privileges.
| CarelessExpert wrote:
| I've heard all the excuses.
|
| None of it changes the fact that Wayland was either
| intentionally or unintentionally designed to exclude
| extremely common software use cases, or worse, to make
| those use cases someone else's problem (e.g. screen
| sharing), thereby creating fragmentation in the ecosystem
| due to a lack of standardization.
|
| After all, it's pretty rich to blame Gnome or KDE for
| "[deciding] to do something different" when Wayland was
| very deliberately designed to offer no standard for how
| to do the thing in the first place.
|
| I'd actually prefer it was unintentional, as that would
| imply simple oversight. If it was intentional, that
| implies deliberately bad design choices that have gotten
| us to the semi-broken place we are right now; a place
| we're only finally getting out of as other people (e.g.
| the PipeWire folks) step in to cover up the spike-filled
| holes that Wayland has left behind.
| taway098123 wrote:
| These aren't excuses, there are no other parties at play
| here. Weston was the first implementation. GNOME and KDE
| were the next implementations. They could have chosen to
| copy Weston's implementation, thus making those parts
| "standard" but they didn't. That's the way it played out.
| The way you're talking about it makes it sound like there
| was some outside force designing Wayland and convincing
| the other designers to exclude screen sharing, when it
| wasn't like that at all. You also seem to be suggesting
| that they could have designed everything in hindsight
| perfectly before the implementations even existed, I hope
| I don't need to point out why it doesn't work like that.
|
| You're also talking as if Pipewire is some outside thing
| that was developed in reaction to Wayland, when as far as
| I know, the plan with those implementations was always to
| delegate some tasks to Pipewire. The fragmentation here
| is because it's taken a lot of effort to redesign these
| core components. Ideally this would all be done already,
| but it takes time.
| CarelessExpert wrote:
| > You're also talking as if Pipewire is some outside
| thing that was developed in reaction to Wayland, when as
| far as I know, the plan with those implementations was
| always to delegate some tasks to Pipewire.
|
| Given that Wayland was first released in 2008 and the
| first commit to the PipeWire project was in 2015, I'm
| quite confident at this point that you're rewriting
| history to support your position.
| taway098123 wrote:
| You misunderstand, it was only Weston that was started in
| 2008, and it had screenshots back then. I'm talking about
| those other implementations, they didn't really stabilize
| and start aiming to have feature parity until a few years
| ago, and they decided not to copy Weston's screenshooting
| mechanism.
| CarelessExpert wrote:
| Weston being the reference implementation for the
| protocol, my point stands and you're now picking nits.
| taway098123 wrote:
| I don't see how I am, and I don't understand your point.
| The reference implementation had screenshots. The other
| implementors decided not to copy that and did their own
| thing. What more could the Weston developers have done?
| They can't force the other implementations to write code
| that they weren't interested in writing.
| CarelessExpert wrote:
| Actually standardize the protocol and make the feature
| part of the spec instead of delegating the implementation
| to compositor extensions and effectively giving everyone
| permissions to do their own thing.
|
| As they should've done with the many other features that
| are missing from the base protocol because some designer
| somewhere decided it was "beyond the scope of the
| project".
|
| We even have a pattern for this in the way HTML5 was
| developed.
|
| I swear, it's like the Wayland folks were absolutely
| hell-bent on repeating the mistakes of the browser world
| circa 2000. The only question, now, is which project will
| end up the IE5 of the Wayland compositor world...
| taway098123 wrote:
| Any implementor always has permission to do their own
| thing, that's the point of making a second
| implementation. Putting something in a spec somewhere
| doesn't make it mandatory or guarantee it will be
| implemented. They could have put the weston screenshoot
| protocol that was created in 2008 in the spec, but they
| didn't do it, probably because the other implementors
| said it wasn't good enough and they didn't want to
| implement it. So what more could they have done? The
| mailing lists around that time had a lot of suggestions
| that went nowhere. Trying to put pressure on open source
| developers to implement something they don't want to do
| doesn't work, unless you are their boss paying them a
| salary.
|
| I'm being serious here, I legitimately don't understand
| what you're pointing out. Yeah I too wish everything I
| was planning on 13 years ago turned out perfectly, things
| don't work like that though. And if you ask me, the thing
| that's most comparable to IE5 is the Xorg server.
| CarelessExpert wrote:
| > Putting something in a spec somewhere doesn't make it
| mandatory or guarantee it will be implemented. They could
| have put the weston screenshoot protocol that was created
| in 2008 in the spec, but they didn't do it, probably
| because the other implementors said it wasn't good enough
| and they didn't want to implement it.
|
| Amazing how nothing is ever the fault of the people
| leading the Wayland project.
|
| > Any implementor always has permission to do their own
| thing, that's the point of making a second
| implementation. Putting something in a spec somewhere
| doesn't make it mandatory or guarantee it will be
| implemented.
|
| Ahh, now I've got it!
|
| So what you're saying is that, in essence, since your
| claim is no one follows it, one must conclude that in
| fact there is no spec!
|
| And given that everyone I've come across who's involved
| with Wayland has said "Wayland is just a protocol", and
| given protocols are defined by specs, if the spec doesn't
| exist, then neither does Wayland!
|
| Neo would be proud.
|
| > I'm being serious here, I legitimately don't understand
| what you're pointing out.
|
| I can't think of anything that more succinctly describes
| what's wrong with how Wayland has been developed over the
| last 13 years.
|
| Well, except there is no spec, so I guess nothing was
| developed at all? I dunno...
| taway098123 wrote:
| I mean, no, it's not the fault of Weston developers that
| other implementors decided do their own thing. I asked
| this before but what could they have done? Putting tons
| and tons of things in the spec wouldn't really have fixed
| the real problem, which is that the way they wanted
| things didn't exist at that time, and the only way
| forward for them was to write their own implementation.
| The spec is only meaningful if you can get other people
| to promise to implement it in the way it's supposed to be
| implemented. It's true that Wayland is just a protocol
| but that protocol is also defined significantly by its
| implementations.
|
| >I can't think of anything that more succinctly
| illustrates what's wrong with how Wayland has been
| developed over the last 13 years.
|
| I don't understand why and I wish you wouldn't do this,
| this is leaning into flame war territory. If you can
| explain your point to me in a way I understand, then I'm
| ready to listen.
| johnday wrote:
| > It's true that Wayland is just a protocol but that
| protocol is also defined significantly by its
| implementations.
|
| A protocol should never, never, _ever_ be defined in any
| way by its implementations. The entire purpose of a
| protocol is to abstract away the common interface such
| that it is entirely implementation-agnostic.
|
| Indeed, you might say that a protocol prescribes exactly
| the intersection of all implementations.
| taway098123 wrote:
| >a protocol prescribes exactly the intersection of all
| implementations.
|
| That's a better way to put it and that's more what I was
| getting at.
| CarelessExpert wrote:
| > The spec is only meaningful if you can get other people
| to promise to implement it in the way it's supposed to be
| implemented.
|
| The _entire point_ of a spec is to help drive
| interoperable implementations. If that 's not the goal,
| then it has no purpose and it might as well not exist.
|
| The core of Wayland is supposedly a standardized protocol
| and these various projects seemed to do just fine
| implementing against that core spec. There's a reason I
| can run a Qt Wayland app on Mutter or vice versa.
|
| Evolution and development of that spec _can_ be done in a
| collaborative way that takes into account the various
| needs of those projects, such that the standard can
| evolve in a way that furthers the whole ecosystem.
|
| That the Wayland folks instead throw up their hands and
| just say "write a compositor extension" demonstrates
| their unwillingness to do the _actual_ hard work of
| building an ecosystem, which is creating consensus and
| driving adoption of common features.
|
| Is this hard?
|
| Yes.
|
| What they are doing _is_ hard, and it 's deeply naive
| bordering on irresponsible to engage in a project of
| rebuilding the entire display server ecosystem without
| recognizing the need for coordination and diplomacy
| across the open source world.
|
| I look at the history of this and all I can think is that
| this is a group of people who have failed to learn the
| lessons of the past. Groups like the X11 and HTML5
| standards bodies, the IETF, and so many more have
| demonstrated how to build a consensus-oriented
| specification that enables and encourages
| interoperability. Yet, to hear you speak of this, that
| must be a figment of my imagination because apparently
| that's impossible.
| taway098123 wrote:
| Everything you're saying is... mostly what's been
| happening? It's not impossible to have consensus. You're
| missing my point which is that people were trying this
| since 2008, and there just wasn't any consensus on this
| particular feature until a few years ago. There's no
| reason to put it in a spec if there's no consensus. It
| turned out that the consensus was to not put this in a
| Wayland protocol, and to do it somewhere else. So it
| would have probably been a mistake if someone tried to
| force this through before then.
|
| If you ask me, people only notice this one because it
| took a while to reach agreement. No one ever seems to pay
| attention to all the other areas over the years where
| there was consensus.
| craftinator wrote:
| So I can't log my own keystrokes on Wayland? Anti
| feature.
| taway098123 wrote:
| If you have root access to your own system, or read
| access to /dev/input, then it's trivial to deploy a
| keylogger. No need for Wayland to get involved there. You
| can't log keys through the Wayland socket because that
| socket is intended to be accessible to sandboxed
| programs.
| michaelmrose wrote:
| So to be clear you want such a program to be implemented
| to be running as root in a way that the user can't
| individually control its just another root daemon that
| the user may or may not be aware of.
| taway098123 wrote:
| That's one way to do it, it's probably not the best way
| but it would work if you were planning to sidestep
| Wayland security completely. You could make it user
| controllable with dbus and then make a GUI to talk to it.
| donio wrote:
| I dread the day when I will be forced to switch since there
| is nothing like EXWM for Wayland and it's hard to see how
| such a thing could be implemented.
|
| I don't care for "smooth" or "every pixel is perfect" so to
| me the trade-offs are all negative.
| eikenberry wrote:
| There are more traditional window manager type compositor,
| you might be able to find something more to your tastes in
| this list...
|
| https://github.com/swaywm/wlroots/wiki/Projects-which-use-
| wl...
|
| As a happy Openbox user, I'm planning on trying Waybox
| first I think. Waiting for the next Debian release though.
| donio wrote:
| EXWM does some special stuff though. It maps X11 windows
| in a way that they appear to be Emacs buffers and are
| managed as such. It also optionally captures certain
| input from them so that Emacs sequences (for example
| stuff prefixed by C-x) still work as usual. All this is
| done in a very granular way to maintain the illusion. So
| for example if I hit "b" after "C-x" or while the Emacs
| minibuffer is active then it goes to Emacs but otherwise
| it goes to the application. And generally it works very
| well, I've been using it for many years.
|
| To do this in Wayland I imagine we'd need to have Emacs
| act as the compositor and that sounds a bit too crazy...
| Or perhaps some kind of a proxy-compositor could be used
| that could be fully driven by Emacs using an rpc
| protocol. Is there such a thing out there?
| ubercow13 wrote:
| >Using Qt apps under Gnome on Wayland can break in weird ways
|
| Same on sway. I think the relevant bug report is this [1] but
| there is no traction and the patch doesn't really work. Qt5
| is probably not going to receive any attention now too, so
| I'm not holding my breath.
|
| [1] https://bugreports.qt.io/browse/QTBUG-87303
| soulofmischief wrote:
| I run GNOME/Wayland on my host and do 100% of my computing
| inside fully-virtualized VMs running xfce, an actually useful
| desktop environment. In this way, GNOME 3 actually excels
| because it's completely void of features and is thus mostly
| invisible.
| forgotpwd16 wrote:
| Why do that rather just run Xfce?
| jl6 wrote:
| Out of interest are you doing this using Qubes? And why?
| dijit wrote:
| I understand this position, not wanting to be a first mover is
| noble, but most of the complaints about "Linux Desktop" (hiDPI
| screens for example) are solved with wayland, so ultimately I
| prefer if we don't make the switch so painful. (python3 for
| example).
| dasb wrote:
| Tangential: some say that Wayland has inherently higher latency
| due to its design (because vsync is always on?)
|
| Is that true?
| solarkraft wrote:
| Now we just have to wait ... for the actual driver. It's quite
| interesting how this was validated and merged all without a
| sample for testing.
|
| Nvidia still have some way to go with their driver policy, but
| them contributing in an attempt to become a normal citizen of the
| Linux ecosystem is a sign that the "fuck you" days may finally be
| coming to an end which, as the owner of a laptop with an Nvidia
| chip, gives me a sense of relief.
|
| As far as I know this is all still based on their non-standard
| EGLstreams platform, but they are working on a Vulkan allocator
| that supposedly fixes the issue and some contribution activity
| indicates that they may finally support GBM, which would make
| Nvidia cards "just work" without any special treatment, which I
| would of course prefer.
| devit wrote:
| Actually EGLstream is the standard (albeit proposed by nVidia)
| while gbm is an API specific to some Linux drivers.
| solarkraft wrote:
| EGLStreams may be popular in some areas, but _all_ other
| graphics drivers support GBM.
| my123 wrote:
| On Linux.
|
| EGLStreams is the actual Khronos standard
| (https://www.khronos.org/egl) as such existing on Windows,
| QNX and others.
| kllrnohj wrote:
| Being a Khronos standard doesn't mean it exists anywhere.
|
| EGLStreams doesn't exist on Windows, as Windows doesn't
| have any EGL at all. Similarly while EGL is used on
| Android, Android doesn't support EGLStreams and probably
| won't as the functionality already exists & EGL is on the
| way out long-term as Vulkan adoption picks up.
|
| With all that said, EGLStreams is probably also not going
| to get adoption on most platforms as it's pretty terrible
| & inferior to what most platforms already have. Which is,
| on most platforms you can work directly with buffers
| instead of being forced into a specific point to point
| pipe (Android's HardwareBuffe or iOS/Mac's CVPixelBuffer)
| my123 wrote:
| At least Windows has EGL incl streams for some scenarios
| (related to WSL's graphics stack mainly).
|
| On more embedded scenarios that I've worked on (Qt w/
| EGLFS), it's quite popular too.
| igravious wrote:
| When would this filter through to distros?
| solarkraft wrote:
| The next major XWayland release will likely be in about half a
| year, but they're considering putting it into a point release.
|
| The most likely answer is next version or the one after that
| depending on how they'll do the release (Ubuntu just released
| so there are a few months available for the next version in
| their 6 months schedule, it'll definitely be in the next LTS).
|
| Source:
| https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests...
| AndrewUnmuted wrote:
| This is a very interesting development for those of us in the
| CUDA space who work on Linux!
|
| I had thought Wayland was not ever likely to be supported by
| nVidia, but something clearly has changed.
| mrweasel wrote:
| Couldn't you use the Nvidia card for CUDA and just have an AMD
| card for the display. It's a little dumb having two graphics
| cards, you need a spare PCI slot and graphics cards are
| expensive (but you could just get a cheap old and used card, if
| it's just for your desktop environment).
|
| I'm asking because it seems like no one relying on Nvidia card
| for number crushing and who want Wayland seem to have opted to
| just get a second card.
| Y_Y wrote:
| The top CUDA cards don't even do display. Anyway tons of CPUs
| have a good-enough on-die GPU that you can use for display in
| a pinch.
| michaelmrose wrote:
| In a pinch if you only want one display.
| michaelmrose wrote:
| Nvidia has a difference in how they implement their driver that
| would have required a number of players to each implement
| support for NVIDIA separately from other hardware because
| NVIDIA wants to directly use a lot of code it uses on other
| platforms on Linux.
|
| Unfortunately due to the misdesign of Wayland each graphical
| environment must write code to more directly interface with
| hardware instead of that being a layer above that. This means
| in current context it is vastly easier if NVIDIA bends on this
| issue however they also have the least incentive because most
| of their money isn't earned on the Linux Desktop.
|
| People seem to suppose that somehow hardware vendors owe Linux
| users support and support in the fashion that would be
| desirable as if somehow not supporting the standards that
| others do is somehow wronging those developers and users but a
| private company in fact doesn't owe said developers or users
| ANY support of any kind.
| nikodunk wrote:
| Is what has changed maybe that XWayland has been refactored out
| of core X, making it easier to support without dealing with the
| huge X codebase? Or maybe it's been in the works for a while
| and everything's just landing at once.
| skhameneh wrote:
| Support is inevitable, Wayland is staged to replaced X11, all
| major distros have it in their roadmap (if not already default
| on stable).
| yjftsjthsd-h wrote:
| Yep, totally inevitable; in just another 12 years it'll be
| totally prod-ready ;)
| nsajko wrote:
| > Wayland is staged to replaced X11
|
| Wayland can't possibly replace X11, it's got a fundamentally
| different (I'd even say broken or even malicious) design. If
| anything, some Wayland compositors may emerge as dominant
| desktop environments, but this would be a dark day for power
| users, if it would mean not being able to switch to an
| actually friendly design, as currently offered by Xorg.
| yokem55 wrote:
| Then I encourage you to take up leadership to get some
| development going on the bare metal xorg server. Odds are,
| within a year or two, it will need serious patches to keep
| working with up to date kernels, mesa, and nvidia drivers.
| michaelmrose wrote:
| The kernels policy is not to break userspace and RHEL 8
| which still supports X is 2 years into a 10 year support
| term.
|
| Also nvidia still provides drivers for 18 year old
| hardware for x under solaris
|
| If you want the current version built this year for Linux
| instead of the legacy version you will have to move up
| 2010 hardware though.
|
| I find it quite amusing that proponents of insert
| technology here seem to come in 2 stripes.
|
| A) Those who believe new thing is superior and think you
| ought to try it
|
| B) People smugly stating that you must move to new thing
| because the other options are going away see wayland
| systemd gnome.
|
| It reminds me of a supervisor at a telecom support center
| who gleefully explained that the new system would hang up
| on people who kept mashing zero on the automated phone
| menu that preceeded getting to a person to make you go
| through it.
|
| He didn't understand that people didn't want to use the
| new automated process because in general such systems are
| crappy and confusing.
| zaxcellent wrote:
| The kernel can choose to not support new hardware with
| old interfaces. If the X11 can't interface with new
| hardware, that's game over. No broken userspace
| necessary.
| michaelmrose wrote:
| Choosing not to support said interfaces would be the
| biggest breakage of userspace in 3 decades of Linux
| history. Such a course of action is nowhere specified by
| the people who would be responsible. As best I can see
| you have constructed it from whole cloth from
| suppositions that seem to be ill considered.
|
| Edit: To be clear breaking user space is when a change
| happens in the kernel level wherein software that used to
| work no longer works because the public interface
| presented differs. If you have evidence that this is
| actually going to happen other than your own
| misunderstandings please link it.
| zaxcellent wrote:
| There is a lot of detail about this in the kernel docs:
| https://www.kernel.org/doc/html/latest/gpu/drm-
| uapi.html#ope...
|
| The gist of it is that breakage is OK if the userspace
| isn't open-source and that new uAPIs come around every
| few years due to the rapid pace development of GPUs.
|
| I worked on Chrome OS graphics for years on and one of my
| earliest projects was to bring DRM/KMS (then a newish
| interface) to the Cirrus display card (an ancient card
| that QEMU happens to emulate).
| michaelmrose wrote:
| Does it specifically mention the kernel breaking X? One
| would think that would be the topic of discussion years
| before anyone actually did it.
| anhanhanh wrote:
| Not sure what have I missed but how is X window system a
| "friendly design"?
| nsajko wrote:
| Friendly compared to Wayland. X Windows offers _many_
| features that the designers of Wayland decided to exclude
| to keep their protocol simple, and for some security
| theatre reasons. But this simplicity is deceptive, as it
| means that implementing all the excluded features, and
| deciding on relevant interfaces, is left to the Wayland
| compositors. This is the reason "Wayland" (or, more
| correctly, Wayland compositors) still miss many important
| features that are
|
| * expected by users of X11, Windows, or Mac
|
| * expected by power users
|
| * needed by the visually impaired
|
| And it is also the reason why the Wayland ecosystem is
| destined for horrible fragmentation of interfaces,
| features and implementations.
|
| Another consequence is that the X11 model of having the
| possibility of easily making a window manager to one's
| liking is not possible with Wayland, as compositors are
| monstrous beasts compared to window managers.
|
| I also wrote about all this in some of my previous
| comments, e.g. there was a large thread here:
| https://news.ycombinator.com/item?id=24886074
|
| EDIT: there's another perspective to this that I didn't
| express very well, so here are some quotes from Arch BBS:
|
| By user neosix:
|
| > You can't send keystrokes, move mouse, move windows,
| you can't even get active window. And all that because of
| security?
|
| > But guess what it's not safe walking down the street,
| something can kill you, so let's just stay in the house
| and never go out again :)
|
| By user Trilby:
|
| > While I place a very high value on security and well
| designed software, the strategy of saying "you shouldn't
| want to do that" is not a sane policy. Yet this has been
| the approach of wayland from the start. Can you have a
| system panel? No, you should not want to have one. Can
| you have one client talk to another client? No, you
| should not want to do this. Can you turn on your computer
| and do anything even remotely productive with it? No, you
| should not want to be productive: here, _watch a cat
| video_.
|
| Emphasis mine.
| taway098123 wrote:
| That's not a Wayland problem. The features you're asking
| for are probably still there but they're implemented at a
| different spot in the stack instead of trying to stuff
| everything into the same protocol like in X11. This is
| actually done to reduce fragmentation. Make a service its
| own daemon with a dbus interface or something like that,
| and then it can run the same on X or on any Wayland
| compositor.
|
| In my experience it's actually the simplicity of building
| window managers in X11 that's misleading. It's easy to
| get something up and running that lets you move windows
| around, but to build a full desktop that does everything
| you'd expect is a giant task, and X11 only really gets in
| the way of that.
| nsajko wrote:
| > That's not a Wayland problem.
|
| Exactly, "not a Wayland problem". That's the problem with
| Wayland, nothing is a Wayland problem.
|
| > Make a service its own daemon with a dbus interface or
| something like that
|
| I don't know if I should cry or laugh at this.
| taway098123 wrote:
| Not sure why you'd laugh or cry. Dbus is just an example.
| You can use another mechanism to build another daemon, it
| doesn't have to be built on anything in particular. I'm
| just saying, if you expect that Wayland is going to solve
| every problem you had with your desktop, you're setting
| yourself up to be disappointed. It solves a few specific
| problems. You can solve the other problems in ways that
| reduce fragmentation, but you'll have to look in other
| places.
| nsajko wrote:
| > solve the other problems in ways that reduce
| fragmentation
|
| > look in other places
|
| There's a contradiction here. How do you expect to avoid
| fragmentation if adding additional protocols alongside
| Wayland is required? I mean, _obviously_ there won 't be
| just one protocol. This idea is actually a common joke,
| there's even an XKCD on the topic.
| taway098123 wrote:
| You misunderstand. In both situations, you're making a
| new protocol. The only difference is you'd be making your
| own thing instead of adding new packet types to Wayland.
| And why add new packet types to Wayland if the thing
| you're trying to do can be done outside the Wayland
| socket? Best example is Pipewire and screensharing.
| People ask for screensharing in Wayland but it makes a
| lot more sense to have it in Pipewire because it can
| handle all the other tasks related to video streaming
| like format negotiation and compression. It works
| headless and independent of any compositor, the fact that
| it can also be used to do screensharing is a benefit of
| its design.
| edflsafoiewq wrote:
| It's certainly much friendlier to write programs for.
| WesolyKubeczek wrote:
| This is all very sad.
|
| One would think that A. D. 2021 a program implementing one
| abstraction upon another abstraction wouldn't have to care about
| the actual hardware it's running on.
|
| But in the actual fact we have GUI programs containing quirks for
| graphic chips, and userland programs deeply concerned with what
| kind of filesystem they are writing to.
| boudin wrote:
| This new is actually a bigger step torward Wayland from Nvidia:
| https://www.phoronix.com/scan.php?page=news_item&px=NVIDIA-G...
|
| It seems that Nvidia finally is moving away from the GBM madness.
| d33 wrote:
| What's GBM?
| boudin wrote:
| It's the buffer management part of wayland. Nvidia never
| implemented it and pushed for egl streams instead. This means
| that compositor have to implement two paths, gbm (wayland),
| egl stream (nvidia propriatory only).
| josefx wrote:
| Apparently a Mesa driver API for buffer management.
| zaxcellent wrote:
| That link seems to imply they embracing GBM by implementing a
| backend for it.
| boudin wrote:
| You're absolutely right, got confused between egl stream and
| gbm
| 2OEH8eoCRo0 wrote:
| Already on Phoronix:
|
| https://www.phoronix.com/scan.php?page=news_item&px=Xserver-...
___________________________________________________________________
(page generated 2021-04-09 23:00 UTC)