Hacker News Reader

Comment by chaorace | Hacker News Reader

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.

View on HN

Shouldn't the article be called "Wine on Wayland" instead of "Wayland on Wine" then? I was really confused by the headline.

Agreed. This naming approach reminds me very much of the Windows Subsystem for Linux.

They just want their name to come first. ;) Besides, it has a nice ring to it! wink wink

I think that one's motivated by trademark rules.

It’s a typo, the original article is correct

To me that name makes sense. It is a Windows Subsystem that adds support for Linux

To myself, Windows Subsystem for Linux sounded like a Windows subsystem for Linux.

Updated :)

> 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.

Forgive my ignorance, but why is it useful to have a framerate higher than your monitor refresh rate?

Lower input latency

For benchmarks for example.

Reply on news.ycombinator.com