Am I the only one that thinks policykit is retarded?

[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.

[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]

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]

Number 1 Mistake application are already self solving this under X11 with errors. So its normal to think applications will solve this. Yes X11 fixes this in fact in xcb that xlib uses so fix in libwayland-client would make sense. So not a protocol fix and never was.

Number 2 never is a long time.

https://www.youtube.com/watch?v=sjRUiqJVzOA

There is low level stuff to fix the multi time domain sync problem. This problem is not just your gpu using a different clock to your core. The mega level of clock mess is covered in the above video.

To fix input and output clocks to be the same clock in fact requires fixing the multi time domain problem.

So the is lower level tech barrier making the libinput clock and the presentation time clock be out of sync with no way of resolving to single clock domain for simple usage at this stage.

Before you say never it would have paid to read the Wayland mailing list. I was not suggesting a idea that is not being considered. So your idea of never is not the case.



Being a idiot you have forgot a totally basic point.
1) You provide a default when application installs it can change that default to it preferred setting.
2) So providing default policy files absolutely would not change the problem of steam changing settings the way it wants and then user having to work out how to fix it.
3) duby229 so your idea of a solution totally failed to address gens problem.

Only problem here is a lack of effective editor.

Basically stop suggesting something that changes nothing about the outcome.

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

[oiaohm]

There you have the fact. A home/office user does not need any restrictions. You have locks in the doors. Do not leave your laptop unguarded. For internet attacks, use a firewall, surf in safe sites only and use a virus scanner.

So home user should be running all there applications as root and having a mistake brick their systems. This is exactly what you wrote debianxfce the idea.

I think you need to change from that "does not need any restrictions" and try putting forwards a sensible idea.

[oiaohm]

Think about it.... Wayland -will NEVER- solve the problems described in this thread, it doesn't have the capability and every single end user application will have to solve the problem individually and many -if not most- of them -NEVER- will..... Fact....

Number 1 Mistake application are already self solving this under X11 with errors. So its normal to think applications will solve this. Yes X11 fixes this in fact in xcb that xlib uses so fix in libwayland-client would make sense. So not a protocol fix and never was.

Number 2 never is a long time.

https://www.youtube.com/watch?v=sjRUiqJVzOA

There is low level stuff to fix the multi time domain sync problem. This problem is not just your gpu using a different clock to your core. The mega level of clock mess is covered in the above video.

To fix input and output clocks to be the same clock in fact requires fixing the multi time domain problem.

So the is lower level tech barrier making the libinput clock and the presentation time clock be out of sync with no way of resolving to single clock domain for simple usage at this stage.

Before you say never it would have paid to read the Wayland mailing list. I was not suggesting a idea that is not being considered. So your idea of never is not the case.

Oh YES it is! Policykit forces end users to configure it themselves, they refuse to provide a sane default configuration and make it so that end users MUST configure it manually. The end result is that policykit by default is -NOT- sane and to make it sane it requires end users to be xml programmers..... It's fucking retarded....

Being a idiot you have forgot a totally basic point.
1) You provide a default when application installs it can change that default to it preferred setting.
2) So providing default policy files absolutely would not change the problem of steam changing settings the way it wants and then user having to work out how to fix it.
3) duby229 so your idea of a solution totally failed to address gens problem.

Only problem here is a lack of effective editor.

Basically stop suggesting something that changes nothing about the outcome.

[duby229]

Manually need to edit javascript and xml does not mean Policykit itself is bad. Just there is a serous lack of a editor. Old saying don't throw the baby out with the bath water. So far looking a policykit policy engine itself I find nothing major wrong. Decent editor gui is about all that is missing.

Steam messing with system wide settings to issue happens under windows with user having go into registry to reverse it as well.

Oh YES it is! Policykit forces end users to configure it themselves, they refuse to provide a sane default configuration and make it so that end users MUST configure it manually. The end result is that policykit by default is -NOT- sane and to make it sane it requires end users to be xml programmers..... It's fucking retarded....

EDIT: I'm reasonably certain you can guess the fact that most end users -are NOT- xml programmers, and that making it a requirement that end users -MUST- be xml programmers is literally in -EVERY- possible sense a bad thing to do.

[duby229]

Boy by this point you have gone completely wrong.

https://github.com/wayland-project/w...ation-time.xml

Wayland protocol includes presentation-time this means in theory you should not have to guess how the display stack is behaving. Because you can in fact monitor.

Your application has input lag and output lag. Both input lag and output lag from an application is the reality no matter what platform.

There is a horrible problem in wayland. libinput is using one clock source and presentation is using a different clock source. If time stamps on presentation time and libinput were like both clock monotonic you would really simple be able to measure total lag between action and display by simple subtracting the input event time from when the output frame display time of action.

The way X.org server does X11 you have to guess as vsync information to application is somewhere between 1-5 vsync late. X.org X11 server never in fact informs you of the correct vsync time.


The hard reality here. Wayland Compositor or xorg X11 server or Windows dwm or what OS X one is called cannot in fact fix input/output lag.

You have forgot something important. The OS kernel has scheduler. How long is the delay between when x.org X11 server/wayland compositor sends input to application and the application in fact gets cpu time to process that message. Welcome to another random lag factor and yes message from application to x.org X11 server/wayland compositor has the same problem.

Timestamping of input and output the closer you can get it to the input and the output the more valid the timestamps will be.

The wayland protocol support passing though timestamps on input and output so it has everything that is required to function bar one thing. The 1 missing thing that all timestamps come from the 1 clock source or you have a tool to sync them to 1 clock source.


Kind of right the solution need to be an application side library. Only change to protocol would be mandating time stamping be from all the same clock source. Then add a few things to the likes of libwayland-client.

Using application side library to process timestamps to solve lag issues is exactly how windows and OS X in fact do it. Not everything should be in the compositor/display protocol somethings like lag control make no sense in compositor/display protocol because you are not able to calculate value at the correct point in time. The correct point of time is in the application wanting to draw when it has cpu time.

Please not for VR head sets there is a lot of work to allow x.org X11 server and wayland applications to pass over a raw DRI device of course you will still want to be wanting timestamps out of that..

duby229 here something you have not consider the compositor does a animation thinking it between the hardware and the wayland protocol how does it screen and input sync correctly. The answer is always timestamps. Because the compositor could be delayed by scheduler as well.

Input and Output really depends on having a useful clock source once you have any animation/movement..

You are so horribly indoctrinated, you can't see the forest through the trees... Yes, in fact those trees -are- the forest....

Think about it.... Wayland -will NEVER- solve the problems described in this thread, it doesn't have the capability and every single end user application will have to solve the problem individually and many -if not most- of them -NEVER- will..... Fact....

[oiaohm]

A while ago i noticed that turning on steam would bring up my wifi connection.
Turns out steam came with a policykit policy that allowed it to tell networkmanager to do stuff.
Solution was to fiddle with FUCKING JAVASCRIPT AND XML.
Policykit is bad. Something like it is needed, but it itself is bad.

Manually need to edit javascript and xml does not mean Policykit itself is bad. Just there is a serous lack of a editor. Old saying don't throw the baby out with the bath water. So far looking a policykit policy engine itself I find nothing major wrong. Decent editor gui is about all that is missing.

Steam messing with system wide settings to issue happens under windows with user having go into registry to reverse it as well.

[retardxfce]

Use Kdenlive and the Xfce desktop without X then.


Wayland implementations are bloatware, buggy and slow. See the internet.

XFCE is not GTK3, it is a buggy frankenstein of GTK2 and GTK3. XFCE uses more RAM than KDE plasma while having 5% of the features.
Xorg implementation is bloatware, buggy and slow. That is why Xorg devs abandoned X and started Wayland. Xorg like XFeces is abandonware.

Install Wicd and remove all IBM software.

Wicd is developed by IBM and Linux Kernel and Mesa is also IBM. You should delete Linux kernel and replace it with GNU-Hurd and then delete yourself from existence too.