11 comments

[ 5.1 ms ] story [ 38.1 ms ] thread
My memory is that things like new time-slice in the kernel, significant FS changes have done this in linux, BSD in times past.

Sometimes, you only find the problems in real-life deployment.

FS Quotas had a bumpy start. NFSv4 had a bumpy start (both in BSD, decades ago)

(comment deleted)
Best comment: https://github.com/libsdl-org/SDL/pull/9345#issuecomment-201...

> SDL is not your tool for "signaling to stakeholders" about what is important.

But but but I need engagement for my team!

Well, the original commenter is not entirely wrong. Wayland would improve faster if things in real applications everyone cares about were noticeably broken.

Many apps do not use Wayland, but rather the XWayland fallback, so people are not up in arms about how broken various aspects of Wayland actually are for end users.

It's a funny kind of dance

Users are not your guniea pigs, either.

To convince people to use something, what you're proposing needs to be less-broken than what they already have. The whole "let's burn down their house because they don't want to move to the new one we built" attitude is a disgrace.

I use Sway (a Wayland compositor), but I'm embarrassed to admit that when I see the WaylandBrigade pulling crap like this.

I have tried to switch to wayland a number of times over the years, but invariably it always turns out to be completely unusable to me. The reasons are not always the same, but the outcome is. I just revert to X11, which despite its shortcomings, just works.
Wayland is perfectly ready to be used for normal desktop applications, but the devil is in the details.

Lately, I struggled with: (1) a flickering bug in the NVIDIA driver only affecting Xwayland (2) streaming to my TV via SteamLink (3) reduced performance (compared to X11) on very old (2013) hardware

I fully support the idea of Wayland, but it needs to be adapted better for games.

Perfectly ready* to be used.

* Recently tried to run an Electron application, in particular Element. It failed completely to show UI even with the extra options to do it. Even with Xwayland

* Interesting handling of drag was spotted in GNOME on Wayland with touchscreens, as in events are discontiguous breaking apps. The one we spotted it in is Blender.

* Multiple important use cases have no replacement or equivalent, especially remote desktop access is weak, and software KVM like Barrier doesn't seem to exist.

* Issue with 3D also messes up timings on video playback at high frame rates.

Issue (1) has been a long-standing issue and a prolonged back and forth [0,1] between NVIDIA and Xorg/Wayland devs about implicit and explicit synchronisation protocols. It looks like the explicit sync protocol is in the process of getting merged upstream and the 555 series driver [1] will take advantage of this so hopefully things are looking better. Problem with wayland is that all of the driver, xwayland and every compositor must support the new protocol but it looks like mutter, kwin and wlr will eventually support it. That being said there are constantly new paper-cuts appearing with the NVIDIA driver and Wayland support so who knows what will break with the new driver. Definitely not a pleasant experience. I'm not saying that AMD is smooth sailing but at least you don't have to fight the driver at every new release.

I'm afraid (2) will probably never work properly :-(

[0] https://gitlab.freedesktop.org/xorg/xserver/-/issues/1317

[1] https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests...

[2] https://github.com/NVIDIA/egl-wayland/pull/104#issuecomment-...