Original note from: MuyLinux
To read Eduardo Medina’s original in Spanish, click here
Last month we reported that Wayland’s support for Wine was beginning to take shape, although there is still a long way to go before it reaches at least the staging branch of the project and also Proton, possibly the most popular re-implementation of Wine today. .
Although from Fedora, the distribution that marks the technological evolution of GNU / Linux, they are clear that Wayland is the future in terms of graphics display, there are many voices that have been shown against the protocol, especially because it totally breaks with the scheme consolidated by Xorg decades ago. Among the critical voices stands out that of Simon Peter, creator of AppImage, who even asked that Wayland be boycotted for allegedly breaking many applications.
It is important to note that most of the efforts to support Wine by Wayland do not come from the developers of the re-implementation of the Windows APIs, but from Collabora, a company that, apart from being responsible for The well-known online implementation of LibreOffice is gradually gaining prominence as a driver of technologies for the GNU / Linux desktop. This situation left in the air the position of the hard core of Wine and especially of its leader: Alexandre Julliard.
Luckily, Alexandre Julliard has given his approval to the incorporation of a Wayland driver in Wine, although he has shown his reservations regarding the possibilities of achieving this objective. In a reply that can be posted on Wine’s mailing list, Julliard has commented the following:
“In principle, I am not opposed to having a Wayland upstream controller. In fact, I started writing one many years ago, but it got stuck when I realized that there was essentially no way to do decent window management, and the best we could do would be the equivalent of X11 desktop mode, where we manage the windows ourselves. I do not have the impression that the situation has improved in all that time, nor that there is interest in improving it. "
In short, we come across a stone seen many times when talking about Wayland: the complexity of its implementation. This is in addition to the fact that the controller will have to “stick to the protocols that are standardized on all desktops, without adding composer-specific workarounds”, a policy that has always been applied with X11 to make the code easier to maintain.
Julliard’s response was not just anyone, but Alexandros Frantzis, one of the Collabora developers interested in bringing native Wayland support to Wine. Frantzis has argued that he believes “it would be best for Wine and Wayland to work to provide the best possible experience by using a direct driver, rather than forcing users to go through XWayland’s impedance mismatch layer.”
Julliard’s reservations came to light again when he said that he hopes the Collabora developer “finds a much larger impedance mismatch between Wayland and Win32, and that in the end it will end up reinventing XWayland using Windows APIs.” Despite this, he has invited him to continue with his work to see how far he is capable of going, and if the requirements of the Wine leaders are met, there should be no problem in merging the Wayland driver into the branch project staging, which performs the sandbox function upon receipt of the latest patches.
In short, Wayland’s native support for Wine is unofficial at the moment, but the project leader has not objected to its inclusion, despite having reservations about achieving that goal.