Lutris 0.5.15 Fixes Crashes When Using Wayland With High DPI Gaming Mice

[phoronix]

Phoronix: Lutris 0.5.15 Fixes Crashes When Using Wayland With High DPI Gaming Mice

Lutris 0.5.15 has been released as the newest version of this open-source game manager that allows managing games from within Steam, GOG, various retro game console / emulator solutions, and other sources...

https://www.phoronix.com/news/Lutris-0.5.15-Released

[varikonniemi]

I believe this is related to the issues in current wayland compositors where messages can pile up under heavy load, eventually leading to the client being disconnected if ping-pong is not handled fast enough. So it's not fixing anything, it's working around something that should be fixed in the compositors.

[qlum]

It definitely seems to be related, But to blame it on the compositors is a bit one sieded, its one of those wayland things that need to be worked around. Seems firefox managed to fux ut application side I guess lutrus follows the same strategy, considering the timing.

[FedFer]

Oh boy, Wayland problem post, can't wait for my daily does of X11 fanboys

[indepe]

I was curious what they did to "fix crashes", but couldn't find any related lutris githup issues or PR's. I guess I don't really know where to look...

[oiaohm]

I believe this is related to the issues in current wayland compositors where messages can pile up under heavy load, eventually leading to the client being disconnected if ping-pong is not handled fast enough. So it's not fixing anything, it's working around something that should be fixed in the compositors.

There are two ways that program end up disconnected with Wayland
1) the buffer to or from the client application gets full.
2) failure to handle the ping/pong events.

Number 1 here is the most common problem. Before you say making this buffer bigger there is a trap. Applications under most Linux/Unix systems are only allowed up to 1024 filehandles at one time. Wayland is a local socket protocol that using the OS means to transfer file handles over that socket those are counted. Make the buffer bigger now you can stack up too many file handles causing the OS kernel to instant kill the application. Yes something as nasty as the Out of Memory killer of the Linux kernel that you normally don't see.

Clients being non responsive under X11 x.org bare metal server equals expanding server memory usage. MS Windows you can find yourself running out of resources/ram from non responsive applications. If you cannot work out yet hello cascading failure . Yes causes of x11 server and MS windows suffering from random freezing up of the complete system can be the back-pressure on to the display server from non responsive items.

Something to remember these bugs is the application crashing as in the application it self deciding to die..

This is a simple chain of failure.

1)Wayland compositor disconnects application.
2)Application sees disconnection
3)Application chooses to terminate.

X11 protocol does not say application has to terminate when disconnected either.

Wayland and X11 protocol when application is disconnected the application is free to reconnect.

Yes disconnecting the application when buffer is full or application not responding to ping/pong prevents applications causing the complete interface to stall. This solution equals applications cannot back pressure the compositor. Of course it also means applications now need reconnect code.

[varikonniemi]

There are two ways that program end up disconnected with Wayland
1) the buffer to or from the client application gets full.
2) failure to handle the ping/pong events.

Both 1 and 2 are certainly fixable quite easily. And if i'm not mistaken the work is already underway in libwayland which makes the changes needed in the compositors trivial.

[oiaohm]

I was curious what they did to "fix crashes", but couldn't find any related lutris githup issues or PR's. I guess I don't really know where to look...

https://github.com/lutris/lutris/commit/a97a81d3cdf083c80a629b3259d760ac548056d0

https://github.com/lutris/lutris/commit/e80de5ddca9e902e011eafa43556819f6bb9bdb6

Moved a stack of code out of the main event loop that did not need to be there by using async calls. It had the side effect if your network connection was slow that that complete lutris interface could stall out in the past as well.

Yes the code that been moved out under async calls in lutris in worst possible case could take over 15 min complete. Yes 15+ min non responsive was possible with the old lutris code before the fix.

Most of the time when wayland is cutting applications off due to event buffer getting full there is a bug in the program event loop that is causing other problems.

lutris as far as I can see lutris has not added socket wayland closed reconnect code.

There is a lot of applications out there with event loops containing code that should not be in the event loop thread.

So we can expect that its not 100 percent cured but the cures so far are caused by lets just put everything in the event loop thread and then wonder why our application is not responsive for end users.

Yes the wayland fixes for Lutris prevent lutris from freezing up under X11 as well. So wayland the application crashes/stop clear problem. X11 application is stall out annoying user also a clear problem. 99% of what need to happen to fix Wayland disconnecting applications is fixing faults that should be fixed anyhow.

[indepe]

There are two ways that program end up disconnected with Wayland
1) the buffer to or from the client application gets full.
2) failure to handle the ping/pong events.

....

What varikonniemi said.

[indepe]

Yes the wayland fixes for Lutris prevent lutris from freezing up under X11 as well. So wayland the application crashes/stop clear problem. X11 application is stall out annoying user also a clear problem. 99% of what need to happen to fix Wayland disconnecting applications is fixing faults that should be fixed anyhow.

Bringing up a Message Window that says "Application is unresponsive, quite or wait?" is just as effective, more informative and less annoying.

With that, I don't want to enter another long discussion as we had elsewhere, and leave it at that.