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

  • oiaohm
    replied
    Originally posted by indepe View Post
    Based on that information I can only say that it sounds like a bug to me. You appear to acknowledge that it is only special situations and/or compositors.
    This is argument of someone who only has a 90% there solution.

    WSL is using RDP backend on weston.

    Does it make sense when network connection is lost between Weston and the rdp client that can be resumed to inform application of loss of focus the answer no it does not. You find this with all the weston network backends that you can resume.

    Weston running nested. Yes you are debugging you applicaiton inside weston running as a Wayland application because it nested the wayland application inside is intentional not informed that the nested weston compositor loses focus. For application debugging being able to switch from the application to a debugger without the application knowing it lost focus is important. .

    I am very sure you idea of how to do direct input does not cover the last 10% of the problem being the specialist cases. Yes being able to hide loss of focus to allow debugging also allows users to hide loss of focus for horrible client side anti cheat applications. Users who will want the lower latency majority of them are the game players the ones most likely to come into contact with horrible client side anti-cheat.

    Over network you solution not going to work without creating uinput device right. Before you say does not have to work over network someone will want to use an application that someone has coded when full screen only to work with the feature you have added so once it believes it full screen input does not work right without emulating.

    indepe is really simple to think you have a solution until you look for the specialist requires and go darn this is lot harder than it first appears.

    We have 3 cases here.
    1) debugging
    2) remote
    3) horrible applications coded either wrong or intentional adversary to the user.(client side anti cheat intentionally adversary to user)

    These thing make doing direct input trickier. These 3 you need up needing to mute input when application loses focus without informing application that it has lost focus.

    Yes those 3 cases is why informing applications that is has gained or lost focus is optional. Looking at general well behaved applications get the false believe that the message is always sent. Because for a well behaved application that you are not attempting to debug while application believes it focused and are not using remote there is no reason not to send the messages. Of course not well behaved applications are going to exist and it important that protocols like wayland are design to allow for this case so that supporting them is not doing something in breach of protocol.

    Leave a comment:


  • indepe
    replied
    Based on that information I can only say that it sounds like a bug to me. You appear to acknowledge that it is only special situations and/or compositors.

    Leave a comment:


  • oiaohm
    replied
    Originally posted by indepe View Post
    Optional on part of the application maybe because it doesn't have to install an handler maybe (I haven't tried out not to do that). But the usual thing is to get those messages. The common tutorial app implements that as well.
    Option part of the compositor to send the messages.

    Originally posted by indepe View Post
    I haven't read or encountered that. Reference please. In any case, the regular situation is to get these messages.
    Windows build number: 10.0.22621.1992 Your Distribution version: n/a Your WSL versions: WSL version: 1.2.5.0 Kernel version: 5.15.90.1 WSLg version: 1.0.51 MSRDC version: 1.2.3770 Direct3D version:...


    indepe the example here is weston running nested when the nested weston loses focus it does not inform applications inside that you have lost mouse/keyboard or screen.

    There are many regular situations like the WSL one where you don't get the messages about lose of focus.

    Basically you just asked me for a reference when I had already provided a reference demo the issue.

    This stealth is part of Weston protocol. This stealth makes implementing direct input little harder.

    Simple question do you have a option that allows application to get direct input without the application being able to find out when it has lost focus?...‚Äč

    indepe you have failed to answer this question. Should I take it that the method you have come up with cannot do this. The problem has been you have incorrectly presumed that keyboard/mouse/output loss of focus will always be given to the application when the Wayland protocol has it as optional for the Wayland compositor to inform the application of these events.

    The reason for the optional part of informing applications about loss of focus is be able to deal with client anti-cheat systems and the like that can can be counter to allowing the user interface from being correctly functional from the user point of view.

    Leave a comment:


  • indepe
    replied
    Originally posted by oiaohm View Post

    This is not in fact always. The Wayland protocol has those messages as optional to be sent the the application and this is intentional feature of the Wayland protocol..

    ... https://github.com/microsoft/wslg/issues/1084

    Sometimes it happens due to bugs that applications don't get informed about losing focus. But the Wayland protocol has it coded in that the compositor for miss behaving applications can intentionally choose not to send the application keyboard and mouse enter/leave events and the applications are meant to cope with this event of not getting informed about losing or gaining keyboard and mouse focus. Yes it implemented in the reference Wayland compositor Weston to behave this way in particular cases.

    This is your monitoring behavior not reading the protocol on what is mandatory and what is optional. Yes notice of application of enter and leave on keyboard and mouse being optional is to deal with client anti-cheat back in 2008 when this was discuss this is a very old intentional feature of the Wayland protocol and has been in every version of Weston under particular use cases not to provide those events.

    Optional on part of the application maybe because it doesn't have to install an handler maybe (I haven't tried out not to do that). But the usual thing is to get those messages. The common tutorial app implements that as well.


    Originally posted by oiaohm View Post
    the applications are meant to cope with this event of not getting informed about losing or gaining keyboard and mouse focus
    I haven't read or encountered that. Reference please. In any case, the regular situation is to get these messages.

    Leave a comment:


  • oiaohm
    replied
    Originally posted by indepe View Post
    A wayland client always gets a message that focus is lost. There is keyboard enter/leave which signifies the active window, and mouse enter/leave.
    This is not in fact always. The Wayland protocol has those messages as optional to be sent the the application and this is intentional feature of the Wayland protocol..

    Windows build number: 10.0.22621.1992 Your Distribution version: n/a Your WSL versions: WSL version: 1.2.5.0 Kernel version: 5.15.90.1 WSLg version: 1.0.51 MSRDC version: 1.2.3770 Direct3D version:...


    Sometimes it happens due to bugs that applications don't get informed about losing focus. But the Wayland protocol has it coded in that the compositor for miss behaving applications can intentionally choose not to send the application keyboard and mouse enter/leave events and the applications are meant to cope with this event of not getting informed about losing or gaining keyboard and mouse focus. Yes it implemented in the reference Wayland compositor Weston to behave this way in particular cases.

    This is your monitoring behavior not reading the protocol on what is mandatory and what is optional. Yes notice of application of enter and leave on keyboard and mouse being optional is to deal with client anti-cheat back in 2008 when this was discuss this is a very old intentional feature of the Wayland protocol and has been in every version of Weston under particular use cases not to provide those events.

    Leave a comment:


  • indepe
    replied
    Originally posted by oiaohm View Post
    Yes your idea is that you can kill the handle when the application loses full screen and you can send another one over. This is a message to client side anti-cheat that the user has switched away from the application.
    A wayland client always gets a message that focus is lost. There is keyboard enter/leave which signifies the active window, and mouse enter/leave.

    Leave a comment:


  • oiaohm
    replied
    Originally posted by indepe View Post
    What are you talking about? The game/framework still gets the usual input from wayland.

    There is no degradation in latency at all, just a gain when in full screen mode.
    Simple problem that you keep on missing. This is not just about latency.

    Game decided to lock self that once in full screen users leave full screen for any reason it detects game terminates user.

    indepe you have been coming from this problem that you can work cooperatively with the application. Client side anti-cheats say that you cannot work cooperatively with the application.

    Yes your idea is that you can kill the handle when the application loses full screen and you can send another one over. This is a message to client side anti-cheat that the user has switched away from the application.

    Dealing with the client side anti cheat systems you need to be able to switch away from application that is full screen without it known this has happened. Microsoft windows in Windows 11 implemented this feature by the way.

    indepe what the point of improving latency if when the user tabs out of application to deal with obs/mubble/email... what ever they lose their game playing progress because you have informed application it lost focus so causing the client side anti-cheat to trigger. EVIOCMUTE design would not cause this problem.

    Basically you are ignoring a particular problem. Client side anti-cheat is something the parties who most will want lower latency will have to deal with. This is broader picture.

    You have been focusing on can I implement this without considering the bigger picture limitations. You have not looked at what client side anti-cheat does to see hey you have loss of focus detection. Loss of focus detection gets treated as cheating so banning players in lot of cases.

    Like or not in 2013 EVIOCMUTE was designed for the full problem space including applications with nasty configured client side anti-cheat systems.


    Simple question do you have a option that allows application to get direct input without the application being able to find out when it has lost focus?...

    This time answer the question can your design do this indepe. if it cannot you are going to trip client side anti cheat on particular users so making their experience worse by either have them banned or game crashes.

    Will you now get this this stealth from the application that it lost focus is not want in a feature but a need feature. Current way where the Wayland compositor is a input proxy the application can be kept in the dark when it lost focus and it a full screen application this feature need to be maintained with what change you come up with or you are going to run users fowl of the client side anti-cheats.

    Leave a comment:


  • indepe
    replied
    Originally posted by oiaohm View Post
    ...
    so on because if you do the game will go splat will make users experience worse.
    ...
    Originally posted by oiaohm View Post
    Simple question do you have a option that allows application to get direct input without the application being able to find out when it has lost focus?...
    What are you talking about? The game/framework still gets the usual input from wayland.

    There is no degradation in latency at all, just a gain when in full screen mode.

    Leave a comment:


  • oiaohm
    replied
    Originally posted by indepe View Post
    The game or its framework (like SDL or Wine) would have to support this feature anyway, it doesn't come for free. Neither does Wayland support. Just like the game needs Wayland support, it would need support for this feature.
    To answer question is is framework or game its a bit both.

    Its not frameworks like SDL or Wine. Instead its the anti-cheat frameworks. Every client side anti-cheat framework has a client side lose of focus detection. Its the game developer who sets in the anti cheat options what happens when focus is lost this can be nothing, logging, application termination, application having a intentional causes seg fault/other bug so it does not appear as intentional..

    Remember just because a game is running under wine does not mean it not using a Linux native anti cheat system to collect all the input events.

    The first anti cheats with lose of focus detection cause bad thing to happen to users appeared in 2002.

    This bit of fact means you need a feature to lie to application that it still has focus when you have in fact taken focus completely away and give focus back without the application knowing what has happened..

    Originally posted by indepe View Post
    If you want to wait for EVIOCMUTE you will be waiting a long time. Really long. And all other possibilities have higher latency (unless you wan t to access USB directly).

    So the question is are you actually interested in low latency. I say no.
    This is the wrong call. I would love lower latency but this cannot come at the price of making user experencie with games where user will want to use low latency of making their life worse. Yes not being able to tab out of game to check on OBS/email... so on because if you do the game will go splat will make users experience worse.

    indepe yes the 2010-2012 by the core Wayland developers saw this exact problem.

    Simple question do you have a option that allows application to get direct input without the application being able to find out when it has lost focus? Remember if you cannot pull this off many different games with their anti cheat system is going to be mucking up on users because you will be allowing those anti cheat systems by not having this feature to prevent alt tabbing or any other switch away method..

    This is because I am looking at the bigger picture and where the pit falls are this pit falls limit what are workable options.

    Leave a comment:


  • indepe
    replied
    Originally posted by oiaohm View Post
    Take user doing OBS and Game as a base example on a single monitor item. Both applications are full screen and you are alt tab between them so you are not in fact returning to desktop an activating another application.

    Good point but it doesn't actually make a difference. Just requires more experience to tell.

    Even if it did, the compositor could keep a spare file handle in reserve, being ready in advance.


    Originally posted by oiaohm View Post
    Then remember some games to be really horrible detect they have been pushed out of full screen mode instant terminate.
    The game or its framework (like SDL or Wine) would have to support this feature anyway, it doesn't come for free. Neither does Wayland support. Just like the game needs Wayland support, it would need support for this feature.

    Originally posted by oiaohm View Post
    EVIOCMUTE some thing like it is need for games due to some game makers idea of anti cheat design yes this also does mess up recording the game when you have a single screen under MS Windows so this is not a Linux only problem..
    If you want to wait for EVIOCMUTE you will be waiting a long time. Really long. And all other possibilities have higher latency (unless you wan t to access USB directly).

    So the question is are you actually interested in low latency. I say no.

    Leave a comment:

Working...
X