-
-
Simple problem that you keep on missing. This is not just about latency.Originally posted by indepe View Post
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.Comment
-
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.Originally posted by oiaohm View PostComment
-
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..Originally posted by indepe View Post
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.Comment
-
Originally posted by oiaohm 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.
I haven't read or encountered that. Reference please. In any case, the regular situation is to get these messages.Originally posted by oiaohm View PostComment
-
Option part of the compositor to send the messages.Originally posted by indepe View Post
Originally posted by indepe View Post
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.Comment
-
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.Originally posted by oiaohm View PostComment
-
This is argument of someone who only has a 90% there solution.Originally posted by indepe View Post
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.Comment
Tweet
Comment