Am I the only one that thinks policykit is retarded?

[oiaohm]

You are so horribly indoctrinated..... Those trees -ARE- the forest.....

Really the problem is your ideas are not really fact.

Here a simple one. If a compositor is causing input to lag due to vsync there is simple problem. Why is the input thread processing thread and the graphics processing thread 1 thread?

Input processing thread in compositor could be passing on received input to application before the compositor output processing thread has todo anything.

Fun fact as well that is not consider with present time under wayland so compositor can in graphics processing thread render up frame to be displayed and go to sleep. When it wakes up check the que of input for the render.

You want to call be indoctrinated because it means you don't have to admit to yourself you have got the mechanics of the problem wrong.

[duby229]

Really the problem is your ideas are not really fact.

Here a simple one. If a compositor is causing input to lag due to vsync there is simple problem. Why is the input thread processing thread and the graphics processing thread 1 thread?

Input processing thread in compositor could be passing on received input to application before the compositor output processing thread has todo anything.

Fun fact as well that is not consider with present time under wayland so compositor can in graphics processing thread render up frame to be displayed and go to sleep. When it wakes up check the que of input for the render.

You want to call be indoctrinated because it means you don't have to admit to yourself you have got the mechanics of the problem wrong.

Have you ever actually used wayland? Seriously? Be honest now....

What you call input lag is a -DIRECT- result of the -fact- that wayland doesn't handle input -at all-... Nothing can be done about that until the protocol gets extended to do so. The solution is in the compositor and most definitely not at end user applications. Even if they -could- be fixed almost none of the existing binaries for end user applications will ever get updated. Most games, most tools, most business apps, most of everything will continue to be laggy and will never get fixed if the approach taken is what you describe.

It seems to me I understand the outcome of this topic far better than you, you are so indoctinated you can't even see the facts of what will happen right in front of you.... Those trees -ARE- the forest. Fixing input lag at the end user level will be an -impossible- task. Too much effort that almost nobody is going to make. It is -NOT- end user applications where the fault lies, it is in the display protocols total lack of input handling where the fault lies. If it gets fixed at the display protocol the compositor fixes -everything- in one shot, if it gets fixed at the end user application then -almost NOTHING- will ever get input lag fixed.

[oiaohm]

Have you ever actually used wayland? Seriously? Be honest now....

Yes have. Not only the desktop class stuff you are dealing with. Proper low latency embedded wayland usage.

What you call input lag is a -DIRECT- result of the -fact- that wayland doesn't handle input -at all-...

What straight out lie.

https://wayland.freedesktop.org/docs/html/ch03.html

The basics of wayland input is part of the wayland protocol already.

The compositor looks through its scenegraph to determine which window should receive the event.

Basically you have it backwards totally. X11 at times can be faster because its not in fact handle input and just passes all messages to all active windows. This is why it so simple for application to capture you keyboard input of passwords and the like.

The facts
1) Wayland protocol defines proper input handling.
2) X11 does not define proper input handling.
Yes lack of proper input handling has some serous downsides.

Disabling scenegraph search can in fact be done wayland compositor side yes application using any one of the following options :
1) unstable sections of the wayland protocol can already allow applications request this.
2) Wayland compositor can choose to be embedded for 1 application/have a single application mode so in this mode don't do scenegraph processing before passing input on to applications.
3) Wayland compositor can have a game mode that reduces complexity of scenegraph search while game is like a window. So still be lighter than most desktop targeted wayland implementations while maintaining the security of doing proper input handling..

Try again duby229 this time read what the wayland protocol and X11 protocol are doing.

Due to the fact input handling is in the wayland protocol there is nothing to fix in the wayland protocol. There are implementation choices wayland compositor side causing input problems.

Current desktop wayland compositors not implementing game mode/single application mode this is not wayland protocol fault. The wayland items used in car dashboards does implement single application mode way lower latency when you play with those. In fact less than X11 because you don't have the X11 server checking if a compositor has been added or going to the compositor every input event..

Also the ability for applications to measure how bad the input lag is happens to be missing so able to adjust. Yes adding a compositor to X11 server can see input be processed though a scenegraph as well .

Basically a wayland compositor designed for games is going to have lower latency than X11. Yes even with xwayland loaded there is less code to run before input gets to application than x.org straight without wayland or a x11 compositor.