As I sit here doing supersets of donut-eating, XWayland support in Enlightenment is currently “done”. The work was started, if you want to get overly technical, almost a year ago, at which point a module stub was added to a branch by Chris “devilhorns” Michael and then promptly forgotten about by everyone of import.
I’d provide a list of things that work or don’t work, but really…there’s nothing that doesn’t work. It’s a totally flawless implementation with zero bugs of any kind. This branch merge is so good that it’s made all pre-existing bugs in our issue tracker obsolete. A really tremendous job, if you ask me–or even if you refuse to ask me.
I do recommend not leaving your XWayland-running machine alone long enough for the screensaver to take effect, since there’s currently no way to un-effect it and your screen will have a giant black rectangle over it until you restart. But I prefer to look at this as a productivity-boosting positive: now everyone will be strongly motivated to take fewer and shorter breaks while working. That’s Enlightenment for you, always striving to be the most efficient desktop environment around BY ANY MEANS NECESSARY.
Let’s talk a bit about the implementation. This was not some kind of one-day, “I tried this and it worked lol?”, trivial thing to write. Some background is definitely necessary for most readers though, so I’ve created a small infographic that should be about as clear as most of the related documentation on the topic:
Now that you’re nearly as much of an expert as I am on the subject, let’s delve into how E implements this.
As I’ve mentioned in previous posts, the current Enlightenment compositor architecture is such that each display server backend is discrete–that is, the X11 and Wayland compositors exist separately, each handling only its respective protocol functionality, and then there is a general compositing infrastructure which handles rendering based on cues from the protocol backend. This is a plus because it means that the backends can be fired up to form Voltrona composite display server compositor, or, a compositor which handles both Wayland and X11 clients.
In the early days of Wayland support in Enlightenment 19+, this was used for adding Wayland clients into an X11 session–something that literally nobody wanted, especially me. After abusing it at a conference demo in 2013, this functionality was never ever used again until I eventually disabled it last year and then scrapped it altogether a couple days ago. The main reason was that it was simply too annoying to maintain this sort of functionality. Running with X11 as the main session requires the handling of input regions for all windows and doing shape cutting into the compositor canvas and even if I had a flowchart app I probably couldn’t be motivated to diagram out the exact algorithm that I wrote to do this while in a crumpet-fueled haze in London a few years ago.
Fast forwarding to some point in the last year or so, I was told that XWayland support needed to happen. Or maybe I told someone else that. I’ll go on record stating that it was definitely said by someone, possibly to another entity which may or may not have been my cat. As soon as it was determined that XWayland support was needed, I immediately dropped everything that I was doing and started working on literally any other project. It wasn’t procrastinating, however–those compositor effects needed to be implemented. Probably.
The key point of XWayland support is creating the XWayland process. This happens in a module and is Not Difficult. The difficulty arises later, when attempting to display and interact with X11 windows in the Wayland session.
Why is this Difficult, you ask? Well, casual reader, as you’ll recall from the diagram above, XWayland involves managing an XWindow while rendering a Wayland surface. Both of these things represent the same on-screen window, and they come from separate display server protocols; what could possibly go wrong in a multi-backend compositing environment?
Indeed, the issue was exactly as you’ve guessed. Both the XWindow and the Wayland surface created canvas objects in their respective compositors, and both of these objects showed up as the same window on the screen. Helpfully, however, neither of them would receive any input events, and they also could not be closed. I’d typically provide a screenshot here, but I don’t want to post potato-cam photos on the blog so you’ll have to imagine what this looked like and how furious I was.
I then determined, thanks in part to Derek “Mower Enthusiast” Foreman, that input should be handled only on the Wayland compositor side. Also render. Definitely only rendering on the Wayland side. To summarize, the compositor should be rendering and handling input through Wayland methods, but then doing just about everything else using X11.
Take X11 infos, push them into Wayland. Thanks, Patrick.
This is accomplished by first, getting the new XWindow, reparenting as necessary for non-overrides, and then linking it to the Wayland surface using the WL_SURFACE_ID atom. The XWindow and the Wayland surface, at this point, each have their own client object, so the data from the X11 client is copied onto the Wayland client and then the X11 client is deleted. The Wayland client takes over the hash table entries for the related XWindow, and magically everything works as expected.
I guess now that this is done, the only thing left to do is release E17?
ereleaseblog.wordpress.com 