From Wikipedia, the free encyclopedia
Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).
Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.
Community icon by Alpár-Etele Méder, licensed under CC BY 3.0
The application needs to speak a protocol to be able to use it. If you use a X wm your apps need to be able to talk X's protocol to work, if you use a Wayland compositor your apps need to be able to talk Wayland's protocol (or run on Xwayland, which is basically an X server that runs inside Wayland).
The wm/compositor abstractions only work if your apps know how to use them via the correct protocol
I thought that wms worked as full abstraction layers. It helped to reduce my confusion, thanks.
Typically the abstraction to draw elemnts inside a app window is in the application framework, like GTK, Qt, Electron (chromium), etc.
This is also why apps built with the same framework typically have the same problem on wayland (looking at you, electron).
The abstractions you are thinking of is not in the window manager, which only controls things outside of the main app window, like tiling, border, window top bar, etc.
Yes, part of my confusion was simply mixing up the job of the app frameworks/gui toolkits for the wm. It was weird to me that some apps like firefox had to provide wayland support by themselves and couldn't simply rely on abstraction layers from whathever they're coded in. However, I looked for some info, and found out that firefox renders some widgets on its own, and now it makes sense that they need to provide wayland support.
That is how portals work in Wayland.
For X there was only one protocol, so they all wrote for x.
This also allowed some hacky things to be done that are questionable from a security standpoint afaik.
If you've ever had your WM crash, then you may lose the decorations on your windows, the ability to minimize/maximize them or move them around, but the windows themselves still stick around. Restarting the WM brings that all back as well
X11 and Wayland are just protocols. These protocols are used to abstract the window drawing from the actual hardware and runtime environment as much as reasonably possible - because nobody wants to maintain 3215 versions of their app for different runtime environments. So in order to be shown on the screen an app needs to implement either the X11 or the Wayland protocol (or both!).
The piece of software that is on the other side depends on whether the app is using X11 or Wayland. For the sake of simplicity let's assume that the app does only support one of those. If the app supports Wayland then it will try to connect to a Wayland compositor. The compositor implements every part of the protocol and makes sure that the window is rendered on the screen and that user input is forwarded to the app. If the app supports X11 then it will try to connect to a X server and take the role of an X client. This is (on Linux, essentially) always X.org*. X.org also implements every part of the protocol and makes sure that the window is rendered on the screen and that user input is forwarded to the app.
* Unless you're running a Wayland compositor, then it will connect to XWayland which passes through the window to your compositor.
Wayland compositors have full control over the apps while the abilities of apps are purposefully restricted.
A window manager is just another regular, boring, old X client connecting to the X server. It doesn't actually abstract anything. It can move windows because the X11 protocol allows it to, but any other X client could just as well move all other windows around, read all user input to all other windows and even move the mouse around as it pleases.
So, to be specific, there is no mouse pointer bug in Virtualbox while using Wayland. There is a mouse pointer bug affecting specific Wayland compositors, likely because they enforce GPU hardware acceleration that is lacking in either your VM or the Linux kernel because of missing drivers. Try using a different compositor, (re)installing Virtualbox Guest Additions with the correct version on the guest system and/or check whether hardware acceleration is enabled for the VM and has enough video memory.
Thank you. It's all a bit confusing, but I'm starting to get it.
As an addition to other responses, think that most apps (specially smaller ones) are developed using some framework or set of libraries that might or might not support those protocols.
So let's pretend that I have an app buit using Electron and that framework does not support Wayland. There's nothing I can do on the app side until Electron supports Wayland in this fake example.
So it actually takes time for the libraries to support the new protocol and then app developers to update their apps to support it aswell.
That's why you see that the Wayland migration is incremental and not all at once.
Imagine the whole thing like a graphics card that is in a different PC. Your app wants to draw it's content on the remote screen. Only it's own content inside it's own window. This is not screen sharing. Your app cannot touch any other apps.
X11 is the connection between your app and the remote graphics card. It may be the local card as well, it is the same.
Technically, a wm is not needed. The app and X11 would work anyway.
Shouldn't window managers abstract all that for the software
The wm does not interrupt or change any communication between the app and the screen. It amends it with decoration and control buttons etc. for example it draws the window borders around the app's own window area.
In the case of Waydroid, it depends on features only available in Wayland; simple as that.
There are some applications (like autoclickers) that depend on features only available in X, as well (mainly because they directly ask X to do something)