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

[oiaohm]

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.

1 does not appear going to be fixed the merge requests to libwayland to allow changing buffer size has been basically abandoned. Mostly as soon as Xwayland implemented reconnect/wayland robustness fully this work stopped.

1 appeared simple to fix just expand the buffer. About 5 months ago they notice the out of file handle problem from increasing the buffer size. Remember out of file handles is a kill be OS kernel termination. A wayland disconnect application can keep on running and choose to reconnect instead of crash/die.

So pick you poison and that the problem. Disconnecting application because buffer gets full the application can choose to keep on running. KIlled by kernel for attempt to use too many file handles is an OOM Killer still kill where application is just force terminate no chance to save state or keep running.

This is not as simple as it first appears.

[oiaohm]

What varikonniemi said.

Again write about this. That what varikonniemi said does not work and I have already told you that..

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

Except there is a problem. Linux kernel socket buffer rules. Once full you will be disconnected.

Ping and pong you can put message that application is non responsive but the ping/pong message is reducing the number of other event messages you can put into the buffer.

indepe one of catches with socket buffers. You are putting items into socketbuffer for another application you cannot ask how full the socket buffer is. You find out it full after you have been disconnected. This is Unix/Posix designed system logic.

I have written in detail that what you suggesting simple does not work.

indepe think network traffic it design that connection breaks and that application operating over should network handle breakages with killing themselves. For some reason X11 applications took the idea that the smallest network disruption should equal commit suicide .

[mirmirmir]

I haven't played windows game In a while, I wonder if we can navigate with controller. It's kind of obvious feature to have tbh.

[Hazel]

Stop improving wayland, bring XFree86 back!

[varikonniemi]

Again write about this. That what varikonniemi said does not work and I have already told you that..



Except there is a problem. Linux kernel socket buffer rules. Once full you will be disconnected.

Ping and pong you can put message that application is non responsive but the ping/pong message is reducing the number of other event messages you can put into the buffer.

indepe one of catches with socket buffers. You are putting items into socketbuffer for another application you cannot ask how full the socket buffer is. You find out it full after you have been disconnected. This is Unix/Posix designed system logic.

I have written in detail that what you suggesting simple does not work.

indepe think network traffic it design that connection breaks and that application operating over should network handle breakages with killing themselves. For some reason X11 applications took the idea that the smallest network disruption should equal commit suicide .

why not simply buffer the messages locally if not enough pings are received, so you stop sending more in-flight buffers so that 1024 won't get exceeded. Then you can buffer a gigabyte of messages locally, and when pings start flowing you continue where you stopped. This way no messages are dropped so wayland protocol spec is fulfilled, and application just pauses. In this state the window manager can popup a message that application is slow to respond, wait or kill?

[oiaohm]

why not simply buffer the messages locally if not enough pings are received, so you stop sending more in-flight buffers so that 1024 won't get exceeded. Then you can buffer a gigabyte of messages locally, and when pings start flowing you continue where you stopped. This way no messages are dropped so wayland protocol spec is fulfilled, and application just pauses. In this state the window manager can popup a message that application is slow to respond, wait or kill?

This is not understanding the specification or the limitation that the design of the Wayland protocol has due to Posix limitations.

The compositor cannot just keep on buffering up gigabytes of wayland messages because of the limitations. Remember the clipboard is with wayland uses a file handle and so on ..... Lot of the message use a file handle. Be it application or compositor you can only have 1024 file handles at any one time attempt to have 1025 welcome instant death to your application/compositor on most Posix like systems. So the compositor can only buffer so many file handles before it terminated. Socket/filehandle protocol under posix has very tight limitations and this is for all protocols of this type not just Wayland. Bad part here is break these posix design in limitations the posix standard says instant kill your application..

Also the idea of buffering up gigabytes of message is the compositor is how to get compositor a really bad OOM Killer score so another path to instant compositor death. Yes people wasted over a decade of work looking for different memory leaks in x.org server that were nothing more than x.org having a non responsive application so stacking up events in memory.

Disconnecting the client allows message to be dropped so nothing get back pressured. Yes this end up requiring client to have reconnect code.

1024 is a file handle count limit of the application. Sending a file handle over local socket subtracts from the applications count. Also once the compositor has sent the file handle to the target application it gets to free that file handle so have it back to receive the next messages from other applications.

varikonniemi 1024 file limit does mean you are playing a game of hot potato. The party that non responsive either has to be removed out the game or instead of being a nice harmless potato you are playing with you have a live explosive and the person who gets stuck with it is going to die. That party could be the compositor out of file handles because it attempted to buffer up messages for non responsive application so it run out of file handles so now got terminated by the kernel.

The Linux/BSD/most posix kernel has it own private executioner that you cannot forgot it has. Particular things will trigger this to kill an application.

[Weasel]

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

Facts hurt eh?

[Hibbelharry]

Stop improving wayland, bring XFree86 back!

Did you get the point that this work cured problems users also have had in X11? An application being unresponsive is especially harming in Wayland but its a serious bug in both worlds.

[HEL88]

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.

Nice theory.

And in practice, in a hung program under Windows, after about 3 seconds, a message appears on the title bar (Not Responding), Windows takes over (you can move the window freely), you can close - then you will be prompted whether to close or wait.

This has worked perfectly for years. And it should be a model. Why change something that has worked well in practice?

[oiaohm]

And in practice, in a hung program under Windows, after about 3 seconds, a message appears on the title bar (Not Responding), Windows takes over (you can move the window freely), you can close - then you will be prompted whether to close or wait.

This has worked perfectly for years. And it should be a model. Why change something that has worked well in practice?

https://www.tomshardware.com/how-to/auto-end-tasks-windows

HEL88 with the issues non responsive applications cause for windows lot of Windows end up enabling enabling AutoEndTasks. There are issues here that non responsive application happens to be non responsive when you log out your logout can jam up and not work under Windows.

Works well in practice is just a works for me argument. You skip over all the cases this not working well for all windows users.

Also something else when MS Windows is showing "Not Responding" in the title bar someone has to remember that was client side rendered. There is a interrupt on the event processing in the windows setup.

Debugging a program under windows and block it CPU access completely you can have a window stuck on screen non responsive and it never shows the "Not Responding" in the title bar.

Also when Windows display the non responsive message it also totally stopped sending new events to the application and does not buffer more past that point. In fact some of the messages by the interrupt to get the CSD redraw with Not Responding in the title have in fact cleared messages client side as well.

Windows hides from application that its been cut off from new events. Wayland make it clear to application that it been cut off from new events with the socket disconnect.

The reality here is you cannot infinity expand the event buffer. At some point there has to be a line in the sand with the event buffer that if the application is not being responsive that the events being sent to the application past that point go to /dev/null.

Wayland compositor disconnecting application tells application that is getting no more input. Wayland protocol application can reconnect once it caught up with the que of messages it had.

The issue here is Wayland has the application more in the loop on what is going on.

Windows and Mac OS on non responsive applications will in fact drop messages this causes fun for people using auto hotkey and the like attempting to drive programs as fast as possible and this is before the 2-3 second mark that it informs the users. Yes this causes macros to have application to actions users are not expecting under Windows and Mac OS.

Yes some of the jitter applications have when scrolling when they are not responsive enough on Windows and Mac OS is in fact the event messages MS Windows or Mac OS sent to the void.

HEL88 really once you start digging around under the Mac OS and Windows hood you start finding what wayland is doing disconnecting applications that Mac OS and Windows are doing as well on non responsive application the difference is application does not know they has disconnected under Windows and MacOS.

Lot of ways non responsive application have it window disappear while non responsive is still inline with limiting the miss behavior to the non responsive application.

This is part of the problem people have been thinking this is happening because the buffer is too small. This is more you need to more effectively hide the disconnect. Yes while disconnected keep the same wayland behavour that all messages going to the application go into the void while disconnected until it connected again so you don't back pressure anything like file handles that will cause something else to miss behave other than the non responsive application..

Simple little rule that make sure that you don't expand the area of miss behavior. Non responsive application should be the party that taking 99% of the problems of being non responsive do other wise is not a good idea.

HEL88 like it or not the Windows and Mac OS way has bugs in handling non responsive. No matter how you choose to solve this problem something going to be adversely effected.

Yes application developers would like to keep their head and sand and not know how often their applications are getting picked up for being non responsive. Allowing this is not great for end user experiences.

Remember the code fixes to reduce how often Wayland compositor closes the socket for the buffer getting full make the application in general usage more responsive to the user actions even on X11. 99% of the reason the wayland socket will be closed due to buffer full will be application code bugs that have been hidden by X11/Windows/Mac OS being tolerant to them and users being adversely effected by them.. The 1% is Wayland compositor bugs where wayland compositor crashes and has to restart so the socket closes then reopens..