[HN Gopher] Wayland on Wine: A First Update
___________________________________________________________________
Wayland on Wine: A First Update
Author : todsacerdoti
Score : 104 points
Date : 2021-02-19 15:36 UTC (7 hours ago)
(HTM) web link (www.collabora.com)
(TXT) w3m dump (www.collabora.com)
| Blikkentrekker wrote:
| 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?
| sho_hn wrote:
| 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.
| ubercow13 wrote:
| It's not for fullscreen games, it's for Windows windows. There
| is a separate effort for fullscreen games:
| https://github.com/varmd/wine-wayland
|
| 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.
| Blikkentrekker wrote:
| So what changed?
|
| It is my understanding that the _WinAPI_ requires absolute
| window positioning to function. -- has _Wayland_ since
| offered that?
| ubercow13 wrote:
| 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.
|
| [1] https://www.collabora.com/news-and-blog/news-and-
| events/a-wa...
| Blikkentrekker wrote:
| 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.
| ubercow13 wrote:
| Sure, maybe. I guess we'll see how it works out.
| pantalaimon wrote:
| Well, wine developers are still skeptical
|
| https://www.winehq.org/pipermail/wine-devel/2021-February/18...
| Blikkentrekker wrote:
| 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.
| bluGill wrote:
| 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.
| Blikkentrekker wrote:
| 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.
| cycloptic wrote:
| I think that's why TFA is working on some of the features
| that are missing, e.g. a native Wine port.
| [deleted]
| sbisson wrote:
| 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.
| ntauthority wrote:
| This has been claimed [1] to work via RAIL already - the
| 'Remote Applications Integrated Locally' layer for
| RemoteApp/RDP.
|
| [1]: https://www.mail-archive.com/dri-
| devel@lists.freedesktop.org...
| war1025 wrote:
| Does anyone know if the terrible framerates in the different
| games are typical or just an artifact of the way they recorded
| the video?
|
| Maybe they were just demoing the resolution scaling stuff?
| vetinari wrote:
| 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.
| mfilion wrote:
| 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).
| shmerl wrote:
| Nice progress. Still waiting for KWin to support adaptive sync in
| the Wayland session, then switching to it will finally be a good
| idea.
| viraptor wrote:
| 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)
| arghwhat wrote:
| 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.
| viraptor wrote:
| 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.
| VRay wrote:
| > 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
| arghwhat wrote:
| 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.
| chaorace wrote:
| 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.
| tremon wrote:
| Shouldn't the article be called "Wine on Wayland" instead of
| "Wayland on Wine" then? I was really confused by the headline.
| mfilion wrote:
| Updated :)
| loudmax wrote:
| Agreed. This naming approach reminds me very much of the
| Windows Subsystem for Linux.
| ravenstine wrote:
| They just want their name to come first. ;) Besides, it has
| a nice ring to it! _wink wink_
| [deleted]
| scaladev wrote:
| 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.)
| shmerl wrote:
| 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.
| kelnos wrote:
| Forgive my ignorance, but why is it useful to have a
| framerate higher than your monitor refresh rate?
| ubercow13 wrote:
| Lower input latency
___________________________________________________________________
(page generated 2021-02-19 23:01 UTC)