As an aside it's interesting to note that Collabra are working with Microsoft on a Mesa 3D/Direct X bridge. With Wayland support coming to WSL 2, it's possible to speculate that this approach could also be used to bring a Wayland compositor to the Windows Remote Desktop for application window-level remote access to for WSL 2.
Reading this mailing list thread, I'm really not a fan of 'Linux' application that only work on WSL2. This feels wrong and some would qualify it as the expand part in EEE (embrace, expand, extinguish).
But ... but that's not what the email says, at least from a casual reading.
> We would like to build it such that in theory any Wayland compositor could add support for this mode of operation if they want to remote application to a Windows host (over the network, or on the same box).
I'm not really in the state of mind to fully parse the full email chain, but it sounds like they want the ability to extend Wayland to forward a wayland window/application over RDP to an RDP client. This isn't really WSL2 specific, and could be used to forward applications from a dedicated Linux machine to a Windows client, or maybe even to another Linux host running FreeRDP!
I know the idea of using RDP at all isn't very sexy on Linux, but FreeRDP is nice, and you don't need to use windows at all to benefit from it. IMO it's pretty nice for when you need a detached session, especially per user sessions or multi sessions per user. Definitely better than VNC, again IMO.
Does anyone else get the same feel from Wayland as from WebExtensions? That is, being forced into a new system with less functionality while these shortcomings are swept under the rug with "we'll fix it later" and "nobody uses that" excuses?
Yes, especially since X11 code isn't badly written. It gives me the feeling X devs were fed up with a huge codebase and wanted to write something new and shiny, albeit with 10% of features, pushing the maintenance burden downstream. The Wayland evangelists touting it as desktop-ready and no-true-scottsman'ing any critique also smells fishy. What Wayland did bring was more fragmentation.
And yes, their attitude toward missing features is the same as GNOME's: WONTFIX parade 24/7.
I'm a Wayland evangelist and super sad about the fragmentation - it's the main thing holding it back right now. KDE and GNOME are both doing their own thing, with the wlroots (Sway) community being the main driver for standardization: Wlroots protocols are slowly being integrated into Wayland proper and implemented by KDE (layer-shell is coming up).
I would hope the Freedesktop group to get active here, as they have been incredibly successful promoting standards in the past and probably could do it again - but it seems like they're closely associated with the Gnome-Project, which has apparently decided to go the "fuck everyone else" route.
I think you have a misconception of what freedesktop is, it is not much more than a hosting service for desktop-related projects. If someone wants to submit an RFC there the process is the same as it's always been, other people working on that can choose to accept or reject anyone else's proposals. I wouldn't say GNOME or KDE or wlroots or any of those are being a main driver, the point with that is that they have to come together. None of them can just say "I am working more on standardization than you are," that doesn't make any sense when the participation is voluntary.
(And just IMO, things like layer-shell are not really a solution that fits with Wayland, that just puts us back in X territory where clients can position themselves arbitrarily, steal input and take over the screen)
I have yet to experience this. Granted XWayland makes any utilities not running in Wayland work perfectly for me. The only issues that I have ran into were because of screen-sharing not being supported by Electron. OBS works perfectly though. However, keep in mind that I use sway. I've heard horror stories from KDE and Gnome running on Wayland, but, as far as I know, this is because they apparently have terrible implementations. The benefits for me are the lack of screen tearing and Wayland just feels smoother.
I'm not affiliated with any projects targeting wayland, but I must ask: who is forcing you, and what exactly are they forcing you into? I think the consensus is that X will be kept alive indefinitely (or at least for many more years to come).
Granted the number of alarmist cries from the peanut gallery could be scary, but probably you should look into it for more than just a couple of cursory google searches before starting to spread them yourself.
I only did the google searches to illustrate what I'm talking about, because I haven't been saving all the links I've come across here on HN and in other places without looking for it.
Yes and no. I get a bit of that from wayland overall, but I use sway, and wlroots is actually really good about making protocols for missing functionality (and proposing them as standards).
The display mode faking via scaling would work for resolution, but that sounds like it wouldn't support other cases, like refresh rate, and HDR, right? Also they didn't mention cases where the display has different capabilities at different resolutions (like 4k@30Hz and 1080@120Hz)
HDR is not yet supported, but is to be handled through upcoming color management protocols.
Lowering the refresh rate of the display isn't really useful. The refresh rate of the monitor only acts as an upper limit on visual updates - you can always just skip frames at no cost outside display cable bandwidth utilization if you don't want to update.
Note: VRR is unrelated to modesets, works through an entirely different mechanism, and is supported by a few compositors.
What I meant with the refresh rate is that if I plug into a TV, I'm likely being the highest available resolution - 4k. But that can only do 30Hz refresh rate. The TV can also do 1080p at 120Hz, but the actual resolution needs to change. If it gets scaled output, I'm stuck with both using loads of processing+bandwidth and not getting high refresh rate.
> Lowering the refresh rate of the display isn't really useful
woah woah woah there, what about if you have a panning camera shot in a movie at 24 FPS and try to watch that movie on a 60 hz display? You'll get tiny micro-stutters AKA "judder". They're subtle but if you can notice them, they ruin your moviewatching experience every time
Do you modeset your monitor to 24Hz when you watch a movie or a video? Do you remember to change between 24 Hz and 29.97 Hz?
The solution to this is higher refresh rate and/or VRR.
VRR would allow you to sync to any needed timing (regardless of VRR range, as multiples of fps are fine), dynamically, with no need to modeset to fixed supported refresh rates.
120Hz not only happens to be a multiple of both 24 and 30, but judder from such low framerate input becomes irrelevant at these rates, with VRR instead serving high-framerate content that is slightly out of phase.
That's one of the main reasons to use a media center. Kodi will do that. Jellyfin for AndroidTV will do that.
Others like VLC only do motion interpolation, and some work is ongoing for VRR support (notably, AMD GPUs on Linux, but they work with Low Framerate Compensation so it's conside red hacky and with a higher power draw).
Of course, higher refresh rates are better, but it's quite wasteful anyway if you only have a 24 FPS. Moreover, not evvery mode is a multiple of that.
> Low Framerate Compensation so it's considered hacky and with a higher power draw
This is not hacky or has higher power draw - the display has a minimum refresh rate, and sudden large changes in refresh rate can lead to visible flickering.
The GPU and driver is required to handle this. The alternative is much more intelligent display controllers than is currently available anywhere, so the CRTC lives in the display and just receives framebuffer content whenever.
> Of course, higher refresh rates are better, but it's quite wasteful
It is negligible. Your GPU will do nothing most frames, and the panel power consumption comes from backlight.
> Moreover, not every mode is a multiple of that
Slow framerates do not need to be a multiple of high framerates, as the error becomes irrelevant.
VRR is the solution for fine-tuning for perfectionism.
> This is not hacky or has higher power draw - the display has a minimum refresh rate, and sudden large changes in refresh rate can lead to visible flickering.
I get that[1]. It's a shame we can't specify next frame latency as well, it should be fairly predictable for video (or enable triple-buffering on the monitor side).
> It is negligible. Your GPU will do nothing most frames, and the panel power consumption comes from backlight.
I was basing this on a recent patchset with the following quote[2]:
> Enabling this feature also have the potential side effect of causing higher power consumption due to running a mode with lower resolution and base clock frequency with the highest base clock supported on the monitor as per its advertised modes
The low FPS is an unfortunate effect of our capture setup on a not very powerful system. The FPS values we get when not capturing are normal (i.e., on par with Wine on X11).
The resolution scaling is done by the scan out engine, not by the GPU. At least on capable hardware, which should be basically anything you see today (maybe not on SBCs). It is also as fast as the scan-out is.
Wish I had seen that post of yours then. In short, X11 devs no longer wanted to maintain a huge codebase and decided to restart from scratch, thus, Wayland was born. The recent push toward Wayland adoption and "X IS DEAD LOL" behavior seems to be because KDE and GNOME adopted Wayland, while GNOME was adopted as default DE on Ubuntu. GNOME has an agenda to spread Wayland everywhere and since they're now in the most popular distro, you'll hear more and more that X11 in insecure, abandonware, bloated etc.
If you do check X's codebase though, you'll notice it's very well written and completely maintainable.
As an example, people often say you can fake input on X and therefore it's insecure, but fake input on X (XTEST) sets a boolean send_event that the receiving application can check to see if the event was sent from another application. Most apps ignore that, but Wine drops any event marked as send_event. I do not like this solution. Instead, inter-process access control lists could solve this easily and would not be hard to implement. Yet, some people think throwing 30 years of solid codebase down the toilet and pushing an inferior product is a better solution. Those people have no idea about X programming or its internals and are just echoing a mantra.
Please continue hacking on X if that's your fancy, I agree that the codebase is fine as far as legacy codebases go, the real problem is that the protocol itself has issues and that can't really be changed without breaking backwards compatibility or breaking ABI in xlib. Adding yet another security policy to the X server might fix some issues people have, it unfortunately won't fix all the other problems.
It is not impossible to add a new version of the protocol while maintaining backwards compatibility. Applications are Turing machines and there is no such a thing as "impossible". Having a bc path for old connection requests while implementing a new API is entirely possible. There's no abi breakage as I understand it, since it's a client-server model.
> Still waiting for KWin to support adaptive sync in the Wayland session
I'm still horrified by the coupling with each WM or DE that need to reimplement (or use a lib, but that's as interesting as noting that you could reimplement an HTTP server in each high level app by using an HTTP server lib...) all the features of the graphics server.
Are there other examples of systems doing that for their graphic stack, particularly at this level? It feels wrong. It feels almost as wrong as it felt with BeOS depending on the G++ 2.95 ABI for its platform interfaces...
tl;dr: Right now, Wine doesn't work on Wayland compositors (this was news to me!). If you're using Wine on Wayland today, it's running through XWayland, which is essentially a X11 => Wayland shim. This article is about the new RFC to implement native Wayland in Wine, which would eliminate the need for such a shim.
> Right now, Wine doesn't work on Wayland compositors (this was news to me!)
No, it doesn't work natively on wayland. It does work using Xwayland, as do many other applications that haven't been ported to wayland. There are some cases where Xwayland doesn't work, though, and those will likely be the toughest things to deal with when adding wayland support as well. It's quite possible this will result in changes to wayland protocols.
Did... you stop reading my comment halfway through? I don't understand why you're correcting me with information that's literally in the following sentence.
This is really tangential to the topic, but does anybody know of any decent performance comparisons between Xwayland and plain X? I saw some talks made by Xorg developers (Keith Packard and others) from ~2012 or so, where they speculated that running Xwayland should be more performant than plain X due to less memory copying and less context switches, but could not find actual tests (and am too incompetent to do it myself.)
I tested The Witcher 3 in the KDE Plasma Wayland session (Wine / XWayalnd, dxvk, radv). I didn't notice any performance degradation or major difference, so I'd say it works very well for games at least.
The only gotcha was the need to use 3 backbuffers for Vulkan (in dxvk config), otherwise framerate was capped at monitor refresh rate by KWin.
The last time I checked on this situation, the Wine developers said they had indefinitely halted any plans for a Wayland port and not so much for the graphical reasons that this article suggests but the windowing a.p.i reasons. — so what changed in this regard?
Can this project actually render Windows windows on Wine or is it only for fullscreen games?
What changed is that the Wayland world keeps evolving, and things aren't always as dramatic as they first appear.
Bridging the windowing semantics is difficult indeed as the Wayland approach doesn't let clients introspect the windowing system or absolutely position themselves, but it doesn't mean you can't get quite far with the excellent relative positioning provided by the xdg-shell/xdg-popup protocols, for example.
The video in the article demonstrates Notepad and other windowed apps.
edit: my mistake, the difference is actually that this one doesn't support Vulkan, and the project I linked only supports Vulkan. So, for playing games with DXVK, the linked project is the more useful one.
It's explained a bit in the previous blog post [1]. I expect that comment you are referencing from a Wine developer was just dismissive without giving any thought to possible non-obvious solutions. Now someone has implemented an alternative solution.
I feel your language underestimates the scope of the problem. As the blog post itself implies:
> The Wayland protocol is by design more constrained compared to more traditional display systems like X11 and win32, which brings a unique sets of challenges in the integration of Wayland with Wine. Since Wayland's window model is not based on a single flat 2D co-ordinate space, as X11's was, the Wayland protocol doesn't allow apps to control their absolute position on the screen. Win32 applications heavily rely on this feature, so the Wayland driver uses a few tricks to accommodate many common cases, like transient windows (menus, tooltips etc).
It doesn't so much explain what it solved and how, but that it delivered a partial implementation of common cases based on what can be done at this point.
That is a single Wine staging developer, however., not “wine developers”.
That having been said, I share some of the concerns that Wayland is pushed, not as an alternative to X11 but as a replacement that many powerful players insist must and shall replace X11, all the while lacking many features that X11 has and that are used.
Wayland is pushed because nobody is maintaining X11, the people who used to maintain X11 are now working on wayland. In short your choice is push wayland everywhere, or fund a new group of people to maintain X11. For the later I have little confidence in one person alone making significant progress, but if you want to prove me wrong - well good luck.
I am betting on wayland long term, though I still have X11 a lot of places.
Perhaps , but that doesn't change that as of this moment, Wayland lacks many feature that users have come to rely on.
Certainly you can see the problem with the situation that developers of one project abandon it and start a new project that lacks many of the features of the old and claim that users should use the new one.
It's not an issue of what will win in the long run; it's an issue of a replacement product being pushed for adoption long ere it be ready.
- Screenshot, screenshare, or remote desktop/VNC server without having to use different protocols for different compositors
- Use a third party app to control monitor outputs(resolution, orientation, framerate, layout, etc.) generally, for example arandr or xrandr (wlroots does support this)
- Be able to do something like KeepassXC's "Autotyping", where it fills in a text field with the password from your password manager.
- Have a third party app give a selection of open windows. I think all compositors have some API for this, but they are all different. (for example rofi's window switcher mode).
Generally, I think the problem isn't so much things that can't be done in wayland at all, as the way to do them is different across different compositors, so whereas with X it was pretty straightforward to mix and match apps between different DEs and apps that worked on all of them. In wayland there are more apps that only work on gnome, only work on kde, or only work on wlroots based compositors. And some apps that duplicate parts of the code for all three.
For screenshots or screensharing, please use the xdg-desktop-portal API. That should work correctly in X11, Wayland, and within a sandbox. For generating fake inputs, a library is being worked on called libei, that also should work in X11, Wayland, and within a sandbox.
For controlling monitor outputs and open windows, those APIs are different because each compositor has a different set of features for what those mean. Generally you should not be using random applications to configure monitor outputs, only your compositor's configuration tool is going to be reliable there. Applications that need to set custom resolutions can use the viewporter or use fullscreen-shell.
Worst case scenario if you need to duplicate parts of the code for all three, I don't think that's a problem. Just put it in a library if it needs to be re-used, the only alternative there is that upstream maintains the relevant bits of that duplicate code, which I'm sure you can see why they would be reluctant to do that.
> For screenshots or screensharing, please use the xdg-desktop-portal API. That should work correctly in X11, Wayland, and within a sandbox.
This does not allow one to write a screenshot application; this has a protocol that allows Flatpak applications to requæst that the compositor take one and as far as I know it only has support to take on from the entire screen.
Most compositors also have the ability to take such screenshots outside of Flatpak; this simply moves it inside of it.
The “screenshot issue” with Wayland is not that compositors can't take one; it's the lack of an the a.p.i.'s necessary to write software that can take one.
> For generating fake inputs, a library is being worked on called libei, that also should work in X11, Wayland, and within a sandbox.
I could find nothing on this on the internet.
> For controlling monitor outputs and open windows, those APIs are different because each compositor has a different set of features for what those mean. Generally you should not be using random applications to configure monitor outputs, only your compositor's configuration tool is going to be reliable there. Applications that need to set custom resolutions can use the viewporter or use fullscreen-shell.
And that one “should not do this” yet this is supported and used by many on X11 would be one of the missing features that would lead to Wine developers not being interested in a Wayland port.
> Worst case scenario if you need to duplicate parts of the code for all three, I don't think that's a problem. Just put it in a library if it needs to be re-used, the only alternative there is that upstream maintains the relevant bits of that duplicate code, which I'm sure you can see why they would be reluctant to do that.
The problem is that these per compositor a.p.i.'s are unstable.
GNOME extensions and KWIN scripts work by allowing one to directly hack the internals of the compositor in unstable ways; they are much like kernel modules and they break from version to version.
What you are saying is not correct; the xdg-desktop-portal API is not tied to flatpak, it has support for individual windows, it's generic and can be re-used by any sandbox, and it can also be used outside a sandbox. (Snap I believe is using it and it should be not too hard to get it working in other tools like firejail either) Using it has the benefit that your application will also work inside a sandbox and doesn't need to have additional code paths for X11 and wayland and for the sandboxed case. See here for the description of libei, it's not ready yet but is being worked on, and should have a similar design that allows it to work correctly in a sandbox: https://who-t.blogspot.com/2020/08/libei-library-to-support-...
In almost all cases, Wine should viewporter or use fullscreen-shell to set custom resolutions for specific programs, the only reason you would need to allow wine to have access to an xrandr-like API is if you wanted to run your monitor configuration tool from windows, which I strongly doubt people are wanting to do that. If you are using GNOME/KDE, the GNOME/KDE control panel is always going to be the most reliable way to configure that.
Yes you would need to track upstream and keep up with their unstable APIs in order to write such a library that but that's no different than if you asked upstream to do it, they would just be doing that in their tree. (In some cases this is what they do anyway with the xdg-desktop-portal) In any case you would need to be more specific about what it is you want because just saying "implement everything from X11 exactly the way X11 does it" is not useful, that's never going to happen, so let's focus on what actually it is that is needed.
the supported options are whether it should be interactive, and whether the dialog should be modal. There is no option to indicate what kind of screenshot you want (window, monitor, full screen, rectangle). You can hope that the compositor's implementation lets the user select what they want, but the compositor is free to take the screenshot however it wants, the wlroots xdg-desktop implementation for example, currently just always takes a screenshot of the whole screen. The API is oriented more toward's Gnomes approach of considering the screenshot dialog to be the responsibility of the compositor, and doesn't work well for sway's approach of considering the screenshot dialog to be the application's responsibility.
The Screencast protocol at least allows you to specify if you want to capture a monitor or a window, although not all compositors support both (for example xdg-desktop-wlroots only supports the monitor type). Now hopefully in the not-too distant future most compositors will support it, atm, at least in my compositor of choice, it doesn't work yet.
And in both cases the the xdg-desktop-portal API doesn't really work well with apps like Flameshot or Peek, where you determine what to capture by resizing the window of the app.
> For screenshots or screensharing, please use the xdg-desktop-portal API. That should work correctly in X11, Wayland, and within a sandbox.
As Blikkentrekker said, it isn't sufficiently flexible for making a screenshotting app, it is only useful for requesting that some other (possibly compositor native) application take a screenshot and return it to you. Flameshot for example, evaluated using xdg-desktop-portal and determined it wasn't suitable (seeh ttps://github.com/flameshot-org/flameshot/issues/446#issuecomment-774372329). It is also notably missing a way to request a screenshot/screenshare of a single window or of a region of the screen rather than the whole screen.
> For generating fake inputs, a library is being worked on called libei, that also should work in X11, Wayland, and within a sandbox.
Well that's still a work in progress isn't it? My response is about what currently doesn't work, not what will work in the future.
> Generally you should not be using random applications to configure monitor outputs, only your compositor's configuration tool is going to be reliable there.
1. For minimal compositors such as sway, creating an advanced monitor configuration tool that handles hotplugging outputs, or with a GUI is out of scope for the project.
2. Being able to script changing monitor configuration, and bind those scripts to hotkeys is pretty important to me. Thankfully that is pretty trivial with sway, but isn't really possible if the only way to manage monitors is the "compositor's configuration tool". And even if it is, such a script isn't portable between compositors.
3. Maybe it is different with wayland, but my experience in X11 was that configuring monitors with xrandr or arandr was much more reliable than any of the DE's designated monitor configuration tools. And even if reliability is no longer an issue, users might prefer a different UI.
> Worst case scenario if you need to duplicate parts of the code for all three, I don't think that's a problem. Just put it in a library if it needs to be re-used, the only alternative there is that upstream maintains the relevant bits of that duplicate code, which I'm sure you can see why they would be reluctant to do that.
Maybe libraries would help, although afaik, such libraries don't currently exist. And some compositors don't have public APIs for some of this functionality at all, and don't really want third party apps to have access, although it is frequently possible to use internal APIs if you can deal with it changing in backwards incompatible ways without any notice. I don't really understand your argument about "upstream" maintaining duplicate code. If there were standardized APIs, there wouldn't be any need for duplicate code.
I did neglect to mention before that all of these are to some extent, somewhat privileged operations, and it does make sense from a security perspective to limit what applications can do these things. However, a big missing piece of wayland is a standard way to grant certain application elevated privileges. From what I can tell most compositors either take the approach of not letting third party apps do a privileged action, or letting all third party apps do a privileged action. Granted it's a difficult problem for a variety of reasons, but the "third party apps aren't allowed to do privileged operations" stance obviously breaks things that worked in X.
An example would be that X11 has protocols to allow the manipulation of currently selected text. In Wayland no such protocol exists as it's entirely agnostic of how clients handle input and render text.
The result is that on X11 I have a hotkey that automatically normalizes strings to their unicode normal form, something that is not as easily implementable in Wayland, or at all.
A far more basic example is that in order to open new card packs in Hearthstone, to buypass the chore that that involves I can in X11 quite easily send an endless string of space keypreses to an application window without having that window even open or focused. — this is not generally possible in Wayland. Looking it up, a tool ydotool exists to bypass this limitation, which requires root access and directly accesses the input devices to do so.
In Wayland, you would use the same method to manipulate the selection. Read it out from the server, do your transformation, then generate fake inputs to rewrite the text. Running ydotool requires elevated access with suid because that's a privileged operation -- if you're running X11 without a sandbox that has a similar drawback as it allows all clients to intercept inputs and send fake inputs to any window.
Independent of Wayland or X11, why should a user not be able to take inputs for their own window (as in, the owning process is run as the same user)? Why does it require a tool that needs extra privileges (that presumably works by doing it at a lower level)?
That's a genuine question — as in, I'm mostly thinking about Windows and how window message handling works with UAC windows. You can send messages to your own windows all day without needing extra permissions, but not other users' windows. I assume that's what you're referring to with the X11 sandbox; is it reasonable to set up Wayland _without_ such a sandbox?
The short reason is that if the user can do it, so can any application running as the user.
I don't know about you, but I'd prefer my applications not be able to inject and read inputs arbitrarily, though it may be that even stricter sandboxing is needed to make that a reality; Wayland being stricter than X11 is just one step along the way.
> though it may be that even stricter sandboxing is needed to make that a reality; Wayland being stricter than X11 is just one step along the way.
It is not a situation of “it may be”; it is a situation of “it is”.
Right now, it is useless as the security boundary on Unix and any other operating system is fundamentally the user and malicious software that runs as one's user can modify every file and process one owns anyway.
I read one comment a while back by a developer that illustrated the fruitlessness of Wayland by saying that it is essentially a lock on a door, that stands in the middle of room, that one can simply walk around, claiming to add security.
That would be true if someone refused to use any form of sandboxing, however there are multiple sandboxing solutions available that the "door" works in combination with. That is the only real way to make this kind of security work on an ordinary Linux distribution, the approach used by Android where a new user is created for each application is not really feasible.
There are also ways to sandbox X11, it's a bit harder to do, but you do have some options on how you'd like to do things.
Right, so that would be a place where something like ydotool would come in handy too because fake inputs coming from there wouldn't be coming from the XTEST device.
Those are not the features of the protocol that are missing; that is an application that does not support it.
The features of the protocol that are missing are what made Wine developers indefinitely shelf their attempt to port it and as I read it, this port indeed is only a partial port for certain use cases that can't map the entirety of Window's windowing a.p.i. as Wine generally can.
The reason many people aren't using Wayland is not because their favorite application does not support it yet, but because at this stage the protocol on a fundamental level does not allow them to do what they need to.
In general, the wayland protocol is not the same as the X11 protocol and is probably not going to have all the same features implemented in the same way. If it was the same, it would be called the X11 protocol. From a user perspective it doesn't matter what the protocol is or how certain things are implemented, ultimately the only thing they care about is if the application works.
Just my observation, asking for X11-style sandbox escapes to support Wine is a mistake, it's much better to work with the system so it becomes feasible to run Wine applications within a sandbox. It just doesn't make sense to break Wayland's design because of other insecure legacy designs in the Win32 API.
Wayland is kind of unique in that it is deliberately, intentionally impossible to run applications written for any other window system on top of it. All the others are pretty well cross-compatible - Win32 applications can run on X11 and vice-versa with an appropriate compatibility shim, both can run on OS X just fine too, and in theory OS X apps could probably run on other platforms if anyone cared to develop the code to do it, but none of them can run under Wayland. By design. The only reason XWayland works is because every Wayland compositor currently bypasses the limited Wayland APIs and implements a large chunk of X-specific code to enable it, and if they ever get tired of maintaining that say goodbye to compatibility with any existing pre-Wayland GUI applications regardless of original platform.
A solution there would just be to add a similar large chunk of Wine-specific code, which could be an option now if none of the other options work. There is no real other way to do it if the other window systems are going to break the security assumptions in Wayland.
Edit: AFAIK the only real reason X11 needs special support is because functionality that would normally be provided by an X window manager needs to be provided by the Wayland compositor, most of the heavy lifting translating the X11 protocol is done out-of-process in XWayland. The amount of code needed there on the Wayland server side is actually not particularly large, I don't know enough about all usages of the Win32 API to say how that compares.
> In general, the wayland protocol is not the same as the X11 protocol and is probably not going to have all the same features implemented in the same way. If it was the same, it would be called the X11 protocol. From a user perspective it doesn't matter what the protocol is or how certain things are implemented, ultimately the only thing they care about is if the application works.
I feel this is the misunderstandng.
You're reasoning from a perspective of “applications”.
Most users who are unsatisfied with Wayland's capabilities are reasoning from a perspective of “utilities” and “functionality”.
Wayland indeed repræsents a move towards the “everything is an app” philosophy. The functionality that is left behind that is needed for the workflow of many are the programs that are not applications and in no way manifest a visual user interface but nevertheless are required for many users.
I'm very confused, if you don't need a visual user interface, why bother with a windowing system? Isn't the point of that to have visual user interfaces? What functionality is missing?
>I'm very confused, if you don't need a visual user interface, why bother with a windowing system?
Hi, so let me tell you an example I use, just so you have a broader perspective of how some people use their desktop.
I have eye problems so it is hard for me to read text, so I use different built in tools but I also create my own scripts combining CLI tools using bash or python.
One such script I use to have dialog from different text heavy games read to me, if the game/engine is open I can patch it to read the text directly but if is proprietary I use this following script
1 grab a screenshot of a section of the screen use a CLI program, I do not want a visual tool to be shown when I run it
2 using same CLI tools I apply transformations to the images, like grayscale and other stuff
3 I OCR the screen, image to text
4 I have the text read to me
My script uses cross platform CLI tools, it would work the same in all Linuxes, Windows and maybe OSX (did not check if all those CLI ones work on Mac but I think they work)
It would suck if I would not be able to use this CLI tools n future and have to make a GNOME/KDE or other DE extension
2 run some other transformation
Because on X11 I can rul tools to trace and debug the windowing system as it is running, introspect it's state and make changes to it.
For instance, I run a variety of scripts that automate the placement of windows as I desire it based on hotkeys. These scripts do not have any window of their own; they simply manipulate the placement of other windows or otherwise query their status to do this. — this is not generally possible on Wayland at this moment.
Such programs are also possible under Windows and are utilized by many users to enhance the functionality of their windowing system.
I don't need any contact with Microsoft to tell you they regret making that possible under windows. It is a security escalation just waiting to happen. Yes those scripts done well are useful, but the abuses are bad.
I'm sure Microsoft wants to rewrite their api. There are a lot of issues with it that are obvious with only a little knowledge. Those who know their api better than me can probably propose a better replacement than I can. However a replacement is tricky as Wayland shows, so I can't blame them for not going forward with it (at least not so far )
That is very possible. Under GNOME and KDE, you would do that with a gnome-shell extension or a kwin script respectively. Those both give you access to the display server's internal APIs. (potentially more than what the X11 server would give you too)
Yes it's in another API and technically not in the Wayland protocol but the functionality is there. It wouldn't make sense to expose all private state of the display server over the Wayland protocol.
The functionality is there by hacking the compositor in unstable ways that might break on the next update and only work for a single compositor. — the only thing that makes this different from editing the source of the compositor is avoiding the recompilation step.
Surely we can agree that being forced to hack the internals of the compositor by way of an unstable a.p.i. is a less than satisfactory solution compared to X11's stable, universal a.p.i.'s that work everywhere?
I can't agree because the alternative would be exposing those unstable private APIs over the Wayland protocol, which would probably not please you either. Some of those X11 APIs are not actually stable and don't actually work everywhere too, they require special support from the window manager.
The issue is that the a.p.i. is not stable and not standardized.
On X11, what I described can be done in a stable, standardized way; on Wayland, it requires hacking the compositor's internals in semi-supported, unstable ways.
These are the differences in features whereof I spoke that make Wayland and unrealistic platform for many users in it's current state.
But the thing is it's not really standardized or stable in X11 either, most client-to-client communications are done through various window properties which are not technically part of the protocol and support for them varies between window managers. If your window manager doesn't support it then it's the same, you have to hack the window manager's internals. Honestly, whatever advanced feature it is that you want would be much better achieved by creating a kwin script or gnome extension and then going from there, I believe there is work underway to stabilize some APIs for both of those but as with X window managers, there is a lot of functionality there and there is no guarantee they will stabilize exactly what it is that what you want.
Do you know a single modern window manager of note that does not support E.W.M.H.?
The “if” on X11 at this stage is a theoretical obscurity with every modern window manager of note supporting it, with the user being confident that it shall remain stable; on Wayland, the reality is that every single compositor has it's own own, typically unstable ways of doing this, though Sway is the one that is committed to stabilizing it and wants it's way of doing these things to become a standard, but that is of little use when the others are not picking it up.
Plenty of older window managers don't support it correctly or use non-standard properties. Plenty of newer window managers have non-standard internal properties for unstable features too.
I would not say that Sway is doing anything special here, what they have done is exactly what I was saying earlier: placed the unstable private APIs in the Wayland protocol, with all the problems that entails. Applications should probably not be consuming those APIs directly, they will likely want to go through an abstraction layer.
