Announcement

Collapse
No announcement yet.

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

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #21
    Originally posted by oiaohm View Post
    ...
    Wayland make it clear to application that it been cut off from new events with the socket disconnect.

    ...
    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.
    ...
    It's not Wayland you are talking about, but Plasma 5.
    This (disconnection) isn't defined by the Wayland protocol.

    Just wanted to clarify that specific point.
    Last edited by indepe; 14 January 2024, 08:19 PM.

    Comment


    • #22
      Originally posted by oiaohm View Post
      ???
      This has nothing to do with the topic. This is about the speed of killing processes (that refuse to close because, for example, data in Excel is unsaved or you have an unsaved project in Visual Studio etc., or some other reason) when the user gives the restart command.

      In your opinion, how much should the system wait during a restart to kill a process that refuses?

      Anyway this has nothing to do with the topic so I don't know why you are linking. Did you read it at all?



      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.
      And it's fine because why send events to the app if you won't see their effects? It is right that they are cut off.

      For me and other users the solution works well. If for some reason the application loses responsiveness for a while (e.g., it is poorly written), I know to leave it alone until it recovers. And that is enough. After recovery you can continue working. And if it hangs up, I close it.

      Sending events, caching them to the application that crashed is completely pointless, because you don't know what you clicked on and what the consequences are.

      Permanent, complete shutdown is also pointless, because it might have just hung for a while for some reason - waiting seems reasonable.

      In my opinion, this solution is optimal. Hundreds of millions of people on windows work every day in thousands of different programs. And probably complaining about the handling of crashed applications is the last thing they would do looking for flaws in Windows.
      Last edited by HEL88; 14 January 2024, 09:49 PM.

      Comment


      • #23
        Originally posted by indepe View Post
        It's not Wayland you are talking about, but Plasma 5.
        This (disconnection) isn't defined by the Wayland protocol.

        Just wanted to clarify that specific point.
        The means to reconnect is defined the wayland protocol all the parts required. SDL and Xwayland server have implemented it as well. Wayland robustness is on the blender ghost UI roadmap as well.


        Clean up your wayland objects (or just leak them)
        This one is funny. If the wayland object you leak are wl_proxy objects as define by the wayland protocol these will auto clean themselves after a reconnect or second connect.

        Where does it say in the Wayland protocol that compositor cannot close socket. In fact Wayland protocol support you running the wayland connect multi times and not having something bad happen.

        The wayland protocol does not define that you will not be disconnected. The fact with wl_proxy and that the connection command can be run multi times without issue by protocol design suggest that it designed that disconnections happened.

        The reality here is the Plasma5/KDE developer doing this work did not have to add anything to libwayland-client to get it to work. Losing connection to wayland compositor by design does cause application to lose it data and this is designed into the protocol.

        KDE developer pushed what libwayland-client is designed todo. There is stuff there that not in the protocol documentation. Yes the KDE developer added code to libwayland-client at first to get this to work then had to delete it all because that was just duplicating what was already in libwayland-client.

        Comment


        • #24
          Originally posted by oiaohm View Post

          The means to reconnect is defined the wayland protocol all the parts required. SDL and Xwayland server have implemented it as well. Wayland robustness is on the blender ghost UI roadmap as well.
          That's beside the point I made: Disconnection due to buffer overflow/ unresponsive application. I am not surprised by your response.

          The behavior that you talk about is Plasma 5, and not specified by the Wayland protocol.
          Last edited by indepe; 14 January 2024, 10:04 PM.

          Comment


          • #25
            Originally posted by HEL88 View Post
            ???
            This has nothing to do with the topic. This is about the speed of killing processes (that refuse to close because, for example, data in Excel is unsaved or you have an unsaved project in Visual Studio etc., or some other reason) when the user gives the restart command.

            In your opinion, how much should the system wait during a restart to kill a process that refuses?

            Anyway this has nothing to do with the topic so I don't know why you are linking. Did you read it at all?​


            In fact it does because that one flag does not just effect shutdown.


            Originally posted by HEL88 View Post
            And it's fine because why send events to the app if you won't see their effects? It is right that they are cut off.​

            Then remember lot of people suggest just expanding the event buffer that as you correctly pointed out when you are not seeing the effects because the application has not kept up this is pointless.

            Originally posted by HEL88 View Post
            For me and other users the solution works well. If for some reason the application loses responsiveness for a while (e.g., it is poorly written), I know to leave it alone until it recovers. And that is enough. After recovery you can continue working. And if it hangs up, I close it.
            Disconnecting the application wayland protocol does happens to make sure that you cannot keep on attempting to stack messages on.

            Originally posted by HEL88 View Post
            ​Sending events, caching them to the application that crashed is completely pointless, because you don't know what you clicked on and what the consequences are.​
            Some poorly written programs under MS windows when events are dropped you end up with events like drag select stay on after you have let go of mouse. Why because the button up message was dropped because the application was non responsive at the time so the application still believes the button is down. This get really bad when it like a alt key. This is why some applications developer attempt to get the buffer size expanded to the point that user can into an application way too many input event queued resulting in user have something happen they were not planning on happening.

            This something the wayland disconnect followed by connecting again does suffer from. The connection gets the current input device state under the wayland mode and it what the application believes and what input state is really close to each other because the buffer is small. Yes you have the 1024 file limit and you have that small buffer equals not too event queued up and this limits application miss behavior..

            The reality is the application should be informed when input events are cut off. Wayland method of closing the connection to-do is kind brutal but the application is getting a message. Yes in the time between disconnection and re-connection application knows it event messages would be missing.

            Originally posted by HEL88 View Post
            In my opinion, this solution is optimal. Hundreds of millions of people on windows work every day in thousands of different programs. And probably complaining about the handling of crashed applications is the last thing they would do looking for flaws in Windows.​
            The reality here you a person over time learns to ignore the defects that complaining about does not get fixed. So this nothing more than fancy works for me argument that should automatically not be used HEL88 because all it says is you have not studied the problem space.

            Comment


            • #26
              Originally posted by indepe View Post
              That's beside the point I made: Disconnection due to buffer overflow/ unresponsive application. I am not surprised by your response.

              The behavior that you talk about is Plasma 5, and not specified by the Wayland protocol.
              It happens with users of weston, gnome and sway as well. Because when buffer gets full the kernel takes over and closes the socket. You are making out its a Plasma5 only issue.

              Yes gnome ping/pong does mean early message before you get to that point. There are rules that are at pay here because Wayland is using a local socket.

              This problem is reproducible in every DE I tried: GNOME, Plasma, weston. The most common situation where this happens is in applications blocked due to disk I/O. As...


              You can see in 159 its not KDE only. KDE reconnect solution works with all other Wayland compositors because that not doing anything outside protocol.

              indepe I have pointed you to this issue 159 before.

              Comment


              • #27
                Originally posted by oiaohm View Post

                It happens with users of weston, gnome and sway as well. Because when buffer gets full the kernel takes over and closes the socket. You are making out its a Plasma5 only issue.

                Yes gnome ping/pong does mean early message before you get to that point. There are rules that are at pay here because Wayland is using a local socket.

                This problem is reproducible in every DE I tried: GNOME, Plasma, weston. The most common situation where this happens is in applications blocked due to disk I/O. As...


                You can see in 159 its not KDE only. KDE reconnect solution works with all other Wayland compositors because that not doing anything outside protocol.

                indepe I have pointed you to this issue 159 before.
                This is from "3 years ago". In so far as it was ever in Gnome/Mutter, I'll assume it was fixed:

                As you know, I recently tested stopping a Wayland app in the debugger, for more than 5 minutes moving the mouse over the suspended window, and it continued fine afterwards. In Plasma 5, just doing this for a few seconds (and I don't have a high speed mouse), will already cause a disconnection and the forceful closing of the windows (after a few single steps in the debugger, before the app sees the error code).

                So as far as I can tell from testing, this is Plasma 5/Kwin . Gnome will bring up a Message Window instead. As you know.

                Comment


                • #28
                  Originally posted by indepe View Post
                  This is from "3 years ago". In so far as it was ever in Gnome/Mutter, I'll assume it was fixed:
                  You have assumed wrong mostly because you have not see what was changed and understood the effect..


                  This change made the issue more hidden. Gnome reduced the ping/pong time window before it declared application no longer responsive and cut of sending messages.

                  Of course gnome response you run into the window and mac os problem where the application end up with incorrect information about the current state of the input devices.

                  Originally posted by indepe View Post
                  As you know, I recently tested stopping a Wayland app in the debugger, for more than 5 minutes moving the mouse over the suspended window, and it continued fine afterwards. In Plasma 5, just doing this for a few seconds (and I don't have a high speed mouse), will already cause a disconnection and the forceful closing of the windows (after a few single steps in the debugger, before the app sees the error code).
                  I don't have high speed mouse to for test this stuff. Instead I use a software uinput device where I can emulate any hz speed of input I like right into real stupid levels. Remember I I had side 10 years people people would be using 8hz computer mice you would have straight up laughed at me for proposing something so stupid.. I can tell you that 159 is still in gnome just now you don't have fast enough input device to trigger it.

                  Originally posted by indepe View Post
                  So as far as I can tell from testing, this is Plasma 5/Kwin . Gnome will bring up a Message Window instead. As you know.
                  Problem is it not just plasma.
                  Sometimes clients can't process events quick enough and the connection gets terminated even though everything is fine. (this can already happen, if the client doesn't process events for...

                  wlroots developer takes the same point of view at KDE/Plasma and qt core developers..

                  There is a reasons why qt and wlroots do not want to use the ping/pong solution.
                  1) Its not 100 percent fix. So to cover all possible outcomes application need to support re connection anyhow.
                  2) the ping and pongs effectively request the number of event messages that can be queued up for application.
                  3) finally the gnome stop messages when ping as not be responded to with pong end up creating out of sync state like Windows and MacOS suffers from.

                  By the way my software uinput mouse can pretend to be 1mhz mouse at max at this point do have plans to make if faster. This is to make sure that program if a gamer happens to be using auto-clicker and fire at application the application does not instantly explode. 8kz mouse is nothing compared to the horrible speed macro programs and autoclicker can do.

                  1mhz I have see wayland compositors crash out.

                  You and I have been testing this problem at different levels. You have been testing with hardware a non gamer would have. I have been testing with emulated hardware to match up to the worst possible case that the program on the receiving end of decent fast auto-clicker or high speed macro program.

                  Wayland robustness implemented in the applications means be it compositor crash from more input than it can handle or application losing connection because it not keep up with input everything will recover itself.

                  Horrible me has at times put 8 times 1Mhz software emulated mice against kde plasma kwin.

                  The reality is gnome has masked over 159 a little not in fact fixed it and if you are tool up like me you can just make your emulated mouse faster and see that the patch really did not fix it for good. Reality is only fixed up to about ~8hz mouse with gnome current settings. So a 8hz running slightly outside specification here gnome exploding again. if you happen to have 2 8kz mice plugged in at the same time and happen to move them at the same time you can exceed what gnome can tolerate this is why I don't class it as fixed. What happens if 16hz mouse appears.

                  Remember plasma with applications that support reconnect/wayland robustness. I can throw 1mhz mouse at it. Yes the application getting disconnected a lot but everything recovering.

                  Comment


                  • #29
                    Originally posted by oiaohm View Post
                    You have assumed wrong mostly because you have not see what was changed and understood the effect..
                    You are assuming wrong with what you think I am assuming.

                    Originally posted by oiaohm View Post
                    This change made the issue more hidden.
                    "More hidden" is already much better.

                    If there is more to do than Gnome did: maybe, I don't know.

                    Originally posted by oiaohm View Post
                    ​wlroots developer takes the same point of view at KDE/Plasma and qt core developers..

                    From your quote I can't tell if the ​wlroots developer has given this much consideration at all.

                    Originally posted by oiaohm View Post

                    Of course gnome response you run into the window and mac os problem where the application end up with incorrect information about the current state of the input devices.​
                    The current state can be communicated once there is a "pong". The compositor always needs to track the current state.

                    Originally posted by oiaohm View Post

                    There is a reasons why qt and wlroots do not want to use the ping/pong solution.
                    1) Its not 100 percent fix. So to cover all possible outcomes application need to support re connection anyhow.
                    2) the ping and pongs effectively request the number of event messages that can be queued up for application.
                    3) finally the gnome stop messages when ping as not be responded to with pong end up creating out of sync state like Windows and MacOS suffers from.
                    We seem to agree that this is an important issue.
                    Regarding these points:
                    1) Nothing is a 100% fix regarding unresponsive applications. Not a reason to bail early.
                    2) ping/pong in combination with other means can be used for a more differentiated response to this issue, and it is worth it. No reason to wait until the buffer is full.
                    3) Disconnection, by comparison, seems horrible in this regard.

                    Originally posted by oiaohm View Post

                    ....1 Mhz ...
                    All that you are writing about 1Mhz mouse clickers, makes coalescing mouse-move events only more important. If Gnome could handle this better, then it should.

                    I have already indicated ways to address these things generally, in the other discussion, and sorry but I won't spend more time here in this context to explain or further explore them.

                    This is almost like asking me to present the source code for review that would handle all this.

                    Comment


                    • #30
                      Originally posted by indepe View Post
                      The current state can be communicated once there is a "pong". The compositor always needs to track the current state.​

                      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.

                      With current wayland protocol to be able to catch application up cleanest way is disconnect and have the application connect again this way it ask the compositor for current state again.

                      There is no Wayland command to que for a Wayland application to say sorry you have been non responsive everything you think you know about is input devices is to be trashed please start over. Then there will need to be a new connect command added to wayland to allow for case where application has not been responsive to reconnect the input devices

                      If you don't have some form of start over you start getting in the location where the compositor has to at least buffer the differences in state to try to catch the application up. At some point this is going to break the compositor like when many applications decide to stop non responsive at once.

                      This is the back pressure problem. The ping/pong solution very quickly can start putting more load on the compositor itself. It also increase code complexity inside the compositor so increases odds of bugs in the compositor.

                      Originally posted by indepe View Post
                      We seem to agree that this is an important issue.
                      Regarding these points:
                      1) Nothing is a 100% fix regarding unresponsive applications. Not a reason to bail early.
                      2) ping/pong in combination with other means can be used for a more differentiated response to this issue, and it is worth it. No reason to wait until the buffer is full.
                      3) Disconnection, by comparison, seems horrible in this regard.
                      This is where you get into problems.

                      Originally posted by indepe View Post
                      All that you are writing about 1Mhz mouse clickers, makes coalescing mouse-move events only more important. If Gnome could handle this better, then it should.
                      https://learn.microsoft.com/en-us/wi...ser-mouseinput There is a elephant in the room.
                      MOUSEEVENTF_MOVE_NOCOALESCE
                      There are applications that part of their design says no mouse-move event coalescing. Commonly drawing programs and games. The exact reason why someone going to have a high speed input device is they are going to be using a program that does not support having mouse messages coalescing performed.
                      Windows will "coalesce" pointer events if they are not handled by the time the next pointer event arrives, removing the old event from the queue and replacing it with the newest one. This results i...

                      That not my point of view either. You have different parties having issues with MS Windows coalescing mouse move events.

                      Auto Clickers will have the left or right click going at a bat out of hell fast enough to fill the wayland buffer on a poorly responding application because these are not movent actions. Mouse with a rapid fire key do get made like it or not..

                      Macro programs like https://github.com/snyball/hawck can be sending text in as if they are a keyboard too fast.

                      indepe something you are missing you are not going to 100% fix unresponsive applications because they will always happen for some reason.

                      Solid question should responsive applications have their input latency adversely effected by unresponsive application?
                      This is the core problem. If your answer is unresponsive should not effect responsive application the disconnect looks like a really good idea. Because the compositor is losing basically no processing time to the non responsive application.

                      There comes problem as you attempt to coalescing messages that starts causing overhead on the compositor so this could slow down input going to the responsive applications. Having the compositor coalescing buffer up the differences between current state and the last state the program got is going to cause same issue of causing overhead in the compositor. You are also going to cause problems with programs that expect input not be coalescing mouse-move events or other events as well.

                      Processing ping and pong that extra workload on the compositor why should I have this effect on the applications that are currently responsive just because some application off to the side decides to go non responsive..

                      Maybe wayland should be nicer and do a half disconnect but then that does not work with applications that render own mouse pointer.

                      The disconnect non responsive application sux bad for the non responsive application the upside of this solution of let the buffer fill let kernel auto disconnect the compositor gets to put more processing time into having lower input latency for the responsive applications.

                      indepe this is the problem here everything you are suggesting has a negative trade off. Yes disconnect has it issues as well. Handling a disconnect is required to deal with the case wayland compositor crashes and is restarted as well.

                      Coalescing mouse move events when you are aware of the issues windows have with this I would say that this should be a Wayland protocol extension where application informs compositor that it wants the messages Coalesced if input is exceed khz event speed with the compositor able to say No I will not do that sorry.

                      This is the case Coalescing mouse events is not a magic cure all. Happens to be a lets cause problem option that need to be turned on or off in cooperation with applications turn it on generally you will have like the issue above where user is complaining that it getting in the way so something not working right.

                      When you look at this problem to be as kind as possible on the compositor you need the application that been non responsive to get message of some format be it a disconnect or something else added to the protocol that say sorry application you have been non responsive everything you knew about the input state invalidate and ask for new state because you have been non responsive and are now out of sync sorry.



                      Comment

                      Working...
                      X