Wine's Wayland Driver Is Becoming Mature, May Aim For Upstreaming Early Next Year

[joshx1]

Firefox is mostly good on Wayland although under Kwin clicking-and-dragging to tear out tabs into new windows is buggy.
Chromium under Wayland is generally OK if you are only using a 60 Hz display. It gets all kinds of glitches on high refresh rate monitors because it can't keep up with screen refresh rates of > 60Hz.

I've been running 165hz fine with Wayland/Chrome on Sway. If you're using Plasma (KWin/KDE), Chrome is stuck at 60hz though.

[bple2137]

Nice. Seems all we need is some more mature Wayland support from Firefox and Chromium and we can leave X11 behind for good.

What's wrong with Firefox on Wayland? I've been using the native FF backend on both Intel and AMD and it's been perfectly fine, on Intel iGPU even better than X11, because it's noticibly smoother (on X11 scrolling of more complex pages still stutters) while eating less battery. Some time ago there was some caveats like splitting tabs into separate windows and merging it back was misbehaving, or it wasn't "require attention" after clicking link or so. Now those issues has been fixed. I seriously don't understand what's missing and why it's not default when running a Wayland session.

[mdedetrich]

I suspect that the majority if waylandissues can be tied to Nvidia drivers? I m using wayland and Firefox on GNOME now cosmiq since years and with mesa (Intel/AMD) I cant recall any glitches in the recent one maybe two years.

Nope this is classic scapegoating. Unless you are using the system in a very basic way, Wayland has historically had many issues completely aside from NVidia (and this is one of those non basic cases).

[Weasel]

I hope it gets rejected once it fails to pass most tests because of Wayland being Wayland. Don't need such maintenance burden on Wine devs for a piece of shit protocol flawed by design. This guy can keep maintaining it himself out of tree.

[TemplarGR]

I hope it gets rejected once it fails to pass most tests because of Wayland being Wayland. Don't need such maintenance burden on Wine devs for a piece of shit protocol flawed by design. This guy can keep maintaining it himself out of tree.

No one is forcing you to use it. You are not developing WINE, so it is not your burden. Wayland is the future. If you don't like it, you could always switch to BSD, or Windows.

[Vistaus]

Chromium under Wayland is generally OK if you are only using a 60 Hz display. It gets all kinds of glitches on high refresh rate monitors because it can't keep up with screen refresh rates of > 60Hz.

That's not true. I have a 75 Hz display and Chromium keeps up just fine on Wayland.

[treba]

I hope it gets rejected once it fails to pass most tests because of Wayland being Wayland. Don't need such maintenance burden on Wine devs for a piece of shit protocol flawed by design. This guy can keep maintaining it himself out of tree.

I hope you help maintaining the display server part of Xorg then, because most if not all the people who did that so far seem to prefer Wayland.

[MrCooper]

Looking forward for this to land!

Unfortunately, Wine on Wayland can run into a lot of trouble when attempting to reduce the latency of windowed Windows applications. This happens because Wayland is unable to provide the information on the expected timing of the front buffer flip event, as described in another thread (from this post untill the end of thread).

While it's true that there's no explicit protocol for this yet, in practice the Wayland frame events are pretty close. They mark the deadline for a new buffer attached to a Wayland surface being used for the compositor's next output frame.

Even if there was new protocol explicitly communicating this deadline in advance, a compositor such as mutter which dynamically adjusts the deadline per frame (which is required for achieving good latency while minimizing the risk for missing frames) cannot necessarily even make a good guess when the deadline will be until the previous frame has been presented, which is late for a client which wants to utilize a significant part of GPU capacity. So in practice, Wayland clients which want to minimize latency need to have a feedback loop which constantly measures the effective deadline of past frames, and estimates the deadline for future frames based on that. Whether those measurements are based on frame events or explicit future deadline events likely won't make much difference in practice.

- Wayland vs. screen capturing (I don't know what's the current status)

Screen capturing works great in Wayland sessions. No Wayland protocol is required for this.

- Wayland vs. session locking, here (2022)

This only requires any protocol (Wayland or otherwise) if the screen locking functionality isn't part of the Wayland compositor itself.

[Weasel]

You are not developing WINE

And you know this because...?

Just to be clear, I will neither confirm nor deny this, so you won't get more out of it. There are reasons I want to keep my identity hidden, although I do contribute to open source projects, so...

But back to the statement you made. You made it, so prove it?


But even ignoring that part, it's beyond cringe. Let's turn this around. Are you developing the Linux kernel? If not, why do you type bullshit after bullshit when they remove stuff, or ask to deprecate things you don't use or think it's "outdated" (32-bit for example, not sure if you were the one who asked for it, but if it was someone else then, I'm sure you asked for at least something to remove). You don't develop it so why the hell do you care about their maintenance burden?

You're so full of shit it's beyond cringe.

And xfcemint wonders why I flame people on this board. Look at the cringe shit I have to put up with.

[Weasel]

I hope you help maintaining the display server part of Xorg then, because most if not all the people who did that so far seem to prefer Wayland.

Same thing i asked TemplarGR: how do you know I'm not?

Also, not sure why anyone has to maintain Xorg in this discussion when it's already working better than Wayland.