alfredon996

According to the specs, it has only 1 GB of RAM. Is it true?

https://trimui.com/pages/trimui-brick-hammer

But no achievements and no cloud saves…

This year I switched to Linux and to playing on GoG (a Polish company) exclusively.

I would do the same, but GoG support for Linux is so bad :(

I think there will be more collaboration regarding protocols between Gnome, KDE and Sway, but one single implementation? Hardly.

Lol, no. Wlroots stuff doesn’t work on Sway and vice versa, then there’s a few extra limited-scope imlementations with the same problem and Weston is reference only.

Sway is based on Wlroots. No way Wlroots stuff doesn’t work on Sway.

If only they would add multiplayer to Ravenfield…

I think Linux is for everybody, depending on their setup (distro+hardware)

That’s why I miss Flattr

My goal is to code basic buttons and understand how operating systems implement the way they draw windows for applications.

So do you want to program a GUI yourself, and not using a library, correct ?

Thanks for the detailed answers. So we can say that Wayland sacrifices lower latency in exchange for higher accuracy.

According to this post Gnome allows you to change this behavior through an environment variable (MUTTER_DEBUG_ENABLE_ATOMIC_KMS=0 on Ubuntu 22.04). It should be a configurable option, considering the amount of people complaining about this mouse behavior.

Oh and this is also why the cursor movement might visibly start stuttering during heavy GPU load. This is a problem that was solved back in the 80s but here we are…

Sad, but does this problem only affect Wayland or also Xorg?

For example, the recently publicized about mouse latency differences is true and something I’ve noticed but the difference doesn’t particularly bother me. Something like that is just one of those inevitable consequences of the design of Wayland being so fundamentally different.

It would be interesting if someone explained the relationship between Wayland design and mouse latency