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

[indepe]

No as easy as one would think. Remember while application can be non responsive. Input devices could have been unplugged and so on. Yes current Wayland compositor has to track current statue
...
...
...

There was no need to write all that. Probably nobody except me reads this and also has a clue what exactly you are talking about.

You are right it is not easy. However you apparently assume that because you don't know how to do it well, that it can't be done well.

As far as I am concerned, I'm happy with how Gnome/Mutter handles this. At least so far. Who knows what dragons are lurking anywhere in this wide world.

[oiaohm]

There was no need to write all that. Probably nobody except me reads this and also has a clue what exactly you are talking about.

You are right it is not easy. However you apparently assume that because you don't know how to do it well, that it can't be done well.

Problem is I understand that if you ping/pong perfectly that this is going to have a higher input lag cost than not doing it at all.

Solid question should responsive applications have their input latency adversely effected by unresponsive application?

This is why I put this in bold.

This question defines what a Wayland compositor developer will be interested in.

There is no such thing as a free lunch when writing software doing what gnome has done has a cost. Optimizing Wayland compositor to be the lowest possible input lag for responsive applications has a cost as well.

What gnome developers have done anyone who is interesting in lowest possible input lag they are not going to like.

Wayland reconnect is need in application code to deal with other problems as well.

indepe you have incorrectly presumed I don't understand how to implement this stuff. I do and that the problem. I know what the dragons are because I have and I know what the trade off are because I have done this.

Reason why I know it so well is have have worked on custom interfaces for machines that the interface being non responsive might be the cause of someone getting hurt. Those systems you learn very quickly that every method you have suggested has a input lag cost to pay. Lot of those platforms go for something way nastier than just disconnect the application and let it recover most of those platforms application non responsive fail ping/pong terminate program and start a new instance.

Like it not there are 3 different responses that application might be hit with.
1) Like gnome is doing where system attempt to detect when application is non responsive and adjust flow. The monitoring for this has adversely effected input lag that the cost you have to pay for this.
2)What KDE and Sway do where they disconnect the application because it non responsive this has almost zero cost on responsive applications for input lag but requires applications to have functional reconnect code.
3) Do the ping/pong is a hard watchdog so a non responsive application does not get to buffer full and no notice goes to user and the application gets kill -9 because it did not respond to the ping in time with pong. This is something you seen in embedded systems.

The problem here application developers have got use to being non responsive and that if they are the OS will cover for them on the Desktop. Those coming from graphical controller space for car systems and the like what KDE/Qt and Sway is doing just letting the application be disconnected when buffer is full is being kind because that space would have had it failure to respond to ping not do anything to the input because that has a cost the application is non responsive it to be terminated and restarted because something must be wrong because it non responsive.. Wayland based on qt and wlroots is choosing not go cover for them.

indepe ask yourself truthful what is the upside to not doing what you are suggesting basically what are the costs. I have drawn up process diagram of different options to see where the costs are. Like it or not 2 or 3 lot less steps to perform and have a lot lower cost for responsive applications. Option 2 reconnect has a higher cost on non responsive applications. The terminate application the third option has even higher cost on non responsive applications because of data loss.

[indepe]

Problem is I understand that if you ping/pong perfectly that this is going to have a higher input lag cost than not doing it at all.

Solid question should responsive applications have their input latency adversely effected by unresponsive application?

This is why I put this in bold.
...
...
...

It's time to tell you that "put this in bold" makes absolutely no difference to me. I'll make it very simple for you: Gnome/Mutter good, KDE/Plasma 5 bad. I hope Plasma 6 will be good, because it has the potential to be a nice DE.

[oiaohm]

It's time to tell you that "put this in bold" makes absolutely no difference to me. I'll make it very simple for you: Gnome/Mutter good, KDE/Plasma 5 bad. I hope Plasma 6 will be good, because it has the potential to be a nice DE.

Personal option. Remember Valve is one of the parties funding KDE developer so not added latency to responsive applications is something Valve and gamers like.

indepe what you call good those who want low latency will call bad and what you call bad those who want low latency will call good.

Like it or not there are three groups of people here.

KDE/Qt/Wlroots services a particular group who want low latency and see disconnection of non responsive applications as a problem that happens to defective programs and they are not going to harm performance of non defective programs.

Solid question should responsive applications have their input latency adversely effected by unresponsive application?

Again I leave in in bold and this time think a little more about this question. If you answer yes to this or no. In fact think over both cases.

If you answer yes you suggested modifications are fine because you are willing to take a latency hit because of non responsive applications so they don't get disconnected or killed. If you answer no.. you will want the non responsive application quickly disconnected or killed so they don't effect the another applications.

Application developers will want to service both groups this means they need to suck it up and implement reconnect support for the group that will not tolerate responsive applications being effected by applications being non responsive.

Remember from the point of view of a person like me measuring the input latency of the system KDE has less input latency than gnome so KDE is good and gnome is bad and this is linked to what gnome has done so non responsive applications don't get disconnected as often. Do note under particular cases gnome will still end up with applications getting disconnected because the buffer got full.

[indepe]

Personal option. Remember Valve is one of the parties funding KDE developer so not added latency to responsive applications is something Valve and gamers like.

indepe what you call good those who want low latency will call bad and what you call bad those who want low latency will call good.

...
...
...

I have already measured Gnome/Mutter (on Wayland) mouse and keyboard input latency and posted the results on this forum a while ago.

[indepe]

Again I leave in in bold and this time think a little more about this question. If you answer yes to this or no. In fact think over both cases.

LOL that's funny.

EDIT:
Ok, so just that I have more to think about: which operation exactly is going to affect the latency, in your mind?
(Warning: it's a rhetorical question.)

[oiaohm]

Ok, so just that I have more to think about: which operation exactly is going to affect the latency, in your mind?

Really this is the problem. "rhetorical question." this is not a rhetonical quesiton it what you need to able to answer.

CPU schedulers of OS hand out time slices. There is latency between each time slice you program gets. You rate limit what you put into the buffer because ping/pong this limits how much can be processed per time slice. This has a direct effect on latency. Remember ping takes up a space in the event buffer.

There is a measurable latency effect to the gnome method and it greater than what KDE and Wlroots do,

Letting the buffer get as full as possible with user events so the application can process the most number of user events per allocated time slice that KDE and wlroots is doing has an advantage..

[indepe]

You rate limit what you put into the buffer because ping/pong this limits how much can be processed per time slice. This has a direct effect on latency.

Complete nonsense. It's limited only if the app is already non-responsive. Also, with this method the buffer can be safely made larger.

Remember ping takes up a space in the event buffer.

That's not only minuscule, but also part of the latency that I have already measured.

The fact that you waste my time with this hogwash is an insult to my intelligence. I warned you.

[oiaohm]

Complete nonsense. It's limited only if the app is already non-responsive. Also, with this method the buffer can be safely made larger.

This is you ignoring a fundamental. There is only 1024 file handles a Linux application is allowed to have open at a time. As you push file handles across a local socket they in fact count against the receiving application. When you hit 1024 your application is kernel killed. Using file handles and local sockets give you a hard limit on how large you can make buffer before you risk being kernel killed. The buffer full causes you application to disconnect from socket not be killed.

Remember the wayland compositor also has to operate inside the 1024 file handle limit. There are a few true hard limits on the Linux system 1024 file handles per process is one of those hard limits.

Do you want to hit softlimit that program can choose to recover from like a buffer full or a hard limit like the file handle limit where the kernel will straight up kill the program and not even give the application option to terminate cleanly or save state.

That's not only minuscule, but also part of the latency that I have already measured.

How small. Thinking those using a Viper 8KHz mouse are after 0.5-0.6ms latency. As you said did not have a 8kz mouse you are also not the party who normally buys 8kz or in future faster mouse.

What you are calling minuscule to particular class of users they class a problem.

indepe is the problem. This is something where you cannot do a one size fits all solution. Its like the time someone make a set of clothes that was based on exactly average measurement so far not a single human has been found that can wear it.

Yes only minuscule is a work for me argument. Those who are using good quality 8kz mice don't want even minuscule extra latency and that where this problem comes in.

You have gamers and other parties who want as low as latency as possible and non responsive applications can die for all they care most of the time.
Then you have people like you indepe who want to avoid applications being cut off from the compositor who are willing to justify a small latency cost to have this.

indepe like it or not KDE/wlroots is aiming to service the people who are after high responsiveness.

[indepe]

This is you ignoring a fundamental. There is only 1024 file handles a Linux application is allowed to have open at a time. As you push file handles across a local socket they in fact count against the receiving application. When you hit 1024 your application is kernel killed. Using file handles and local sockets give you a hard limit on how large you can make buffer before you risk being kernel killed. The buffer full causes you application to disconnect from socket not be killed.

Considering that these discussions are more of an obfuscating nature, I'm simply not going to discuss file handles with you. You'd first have to show you understand how to handle simpler issues. However rest assured it doesn't change my position in any way.

How small. Thinking those using a Viper 8KHz mouse are after 0.5-0.6ms latency. As you said did not have a 8kz mouse you are also not the party who normally buys 8kz or in future faster mouse.

What you are calling minuscule to particular class of users they class a problem.

So how much time do you think it takes to send a ping event over a pipe?

indepe is the problem. This is something where you cannot do a one size fits all solution. Its like the time someone make a set of clothes that was based on exactly average measurement so far not a single human has been found that can wear it.

No, the problem is that in spite of the knowledge you get from reading bug reports and other sources, you know too much about problems (which you call "dragons") and too little about solutions.