Am I the only one that thinks policykit is retarded?

[oiaohm]

You mean wayland is used in embedded devices like car automation. They use modified wayland stuff that does not benefit desktop users. The arguments for wayland are not valid when the Xfce desktop can run in a pentium III 512MB RAM computer, while gnome3 and kde not.

Sway that is for wayland that basically i3 runs on a pentium III with 512MB of ram so does Enlightenment in wayland mode both with xwayland loaded.

Gnome3 and KDE are not light weight.

Gaming is one that drives desktop development. SteamOS and ubuntu do not use wayland. So game developers are not interested of Xwayland.

Ubuntu should be currently don't use Wayland as default. This is important.

https://www.phoronix.com/scan.php?page=news_item&px=Wayland-Conformance-Suite-1.0

https://discourse.ubuntu.com/t/wlcs-1-0-release/10800

Ubuntu has moved into the formal process of testing wayland for release. Ubuntu for wayland is tagged at 2020-2021.

SteamOS starting from a Ubuntu base you can expect to wait for upstream to declare Wayland readly. 2022 most likely.

We are to the point you can start time-lining the migration with reasonable predictability.

By the way from a game software development point of view what is the difference between xwayland and normal xorg server. Answer is nothing. xwayland is basically xorg server with special driver.

Many people are brainwashed with wayland and gnome3 hype. Smart people use stable and fast software.

I will make it blunt next Wayland issue you want to raise attempt to find it in i3, weston or enlightenment . These have been doing wayland for longer and don't have some very bad horrible internal issues.

My interest in Wayland predates Gnome even having Wayland parts.

Smart people also aware what is classed as stable and fast software today in future may not be. xorg server direct on hardware is coming up on EOL. Replacement with be xorg server on wayland this is xwayland.

[oiaohm]

When there is a 4 years old fatal bug, only few distributions use wayland in the future .

I told you find a non Gnome example. That bug is Gnome unique.

In your dreams but in reality. No plans to drop X.

Not by dreams is the x.org conference covered this very topic. Progressively the driver level of x.org is going away. You did not watch the 2018 conference videos.

https://github.com/clearlinux/distribution/issues/544

There are a lot of bugs like this one. Do note that the developer is very clear the bad break is gnome. End users are now asking for it on not for gnome but to use the other wayland options.

Really lot blockage to wayland going forward would disappear once Gnome one of the major desktop wayland compositor stops having unique horrible faults.

Hey Gnome is known for have unique horrible faults under X11 as well. So you cannot consider this highly special.

[oiaohm]

So it has been for 10 years. It will be so in future too, just plans and nothing concrete. xorg driver development is active, f.ex there is no wayland freesync support.

What are you talking about. Wayland protocol is not required to support freesync for it to work.

DRM KMS API to turn VRR in compositor.
Have EGL in mesa beaware of it.

There is a lot of bugs but most people don't notice wayland protocol does not have sync primitives. Instead it defaults to opengl/vulkan sync items.

https://en.wikipedia.org/wiki/File:W...r_protocol.svg

So anything with sync in it name really has nothing todo with a wayland issue.

Embedded displays had VRR before either Nvidia or AMD decided to provide it. So yes the embedded wayland compositors perfectly support VRR.

[xfcedebian]

Fellas, fellas, no need to argue. Xorg is immortal and all the developers will dump Wayland and go back to it just as soon as we rip IBM of it's evil mind control devices that's making these poor, sweet, innocent Xorg developers not maintain Xorg anymore. This is actual fact and if you disagree with me or show me evidence of the contrary then you're an evil IBM lacky and I'm going to put my hands over my ears and scream at the top of my lungs.

[oiaohm]

https://gitlab.freedesktop.org/wayla...land/issues/84

No point quoting this bug report at me. I have used VRR embedded wayland compostitors. They are the Wayland 1.0 protocol and it works perfectly. Why VRR epaper displays they make your Freesync and the like displays look not flexible in redraw speeds.

Basically what is written in that bug report makes no sense. Why are you creating a sync item in a protocol that does not contain sync items.

The only section of wayland with any sync structures appears in Wayland 1.2.
https://github.com/wayland-project/w...ation-time.xml
You could most likely run this with clients without changing anything.

"bitmask of flags in presented event" section of presentation-time add a new bitmask for variable sync and job done on wayland protocol side. Of course the existing vsync could be used.

Some how I think those attempting to make desktop compositors are thinking too much X11 server that sync stuff is part of server protocol because it designed to go over network. Wayland is designed to be local different logic is required.

[duby229]

Ok, so I had no choice but to notice that -BOTH- of you are wrong. Or at least at the very minimum, you've both formed opinions that don't make any damn sense. Here are the facts about X11, it's NOT secure, if you're are running X, then -anybody- can get your root password at -any- time from -any- user account with a very simple script. X11 will never be secure. And Wayland -can't- replace X11, it's just too simplistic, it just doesn't implement all the features that X11 does. Wayland -DESPERATELY- needs to be considerably extended. The reason Wayland is still so incomplete a decade later is -because- the protocol itself was -always- and -still is- incomplete.

[oiaohm]

OAnd Wayland -can't- replace X11, it's just too simplistic, it just doesn't implement all the features that X11 does. Wayland -DESPERATELY- needs to be considerably extended.

This is wrong. I have used Wayland in embedded with epapper. I am aware that Wayland has the core protocol and platforms. Platform EGL/VULKAN that is khronos.org problem.

Reality here is Wayland is different designed to X11 protocol. X11 lot of opengl/vulkan things are implemented again in the protocol. Wayland opengl/vulkan/platform are the khoronos problem so 1 party for problems instead of two parties able to blame each other for screwing it up.

Its the same with input. All input for X11 and Wayland will be done by libinput in time. Again 1 party. Libinput is not in fact putting anything in the protocol the wayland compositor has to worry about.

Yes I am not wrong here. Lot of people who say Wayland is just too simplistic fail to notice that Wayland core is simple because its design has delegated so removed the two parties problem and massively reducing the size core protocol needs to be.

[duby229]

This is wrong. I have used Wayland in embedded with epapper. I am aware that Wayland has the core protocol and platforms. Platform EGL/VULKAN that is khronos.org problem.

Reality here is Wayland is different designed to X11 protocol. X11 lot of opengl/vulkan things are implemented again in the protocol. Wayland opengl/vulkan/platform are the khoronos problem so 1 party for problems instead of two parties able to blame each other for screwing it up.

Its the same with input. All input for X11 and Wayland will be done by libinput in time. Again 1 party. Libinput is not in fact putting anything in the protocol the wayland compositor has to worry about.

Yes I am not wrong here. Lot of people who say Wayland is just too simplistic fail to notice that Wayland core is simple because its design has delegated so removed the two parties problem and massively reducing the size core protocol needs to be.

Don't you realize how stupid that is? A display protocol that has no possible way of acknowledging -INPUT-!! Have you ever used Wayland, like at all?What "feels" like input lag isn't really input lag, it's actually the fact that Wayland doesn't consider input -AT ALL-! Libinput -will NEVER- solve that. Nothing Kronos does can solve that.The blame falls squarely and solely on Wayland being incomplete and inadequate for desktop computers.

EDIT: If you're saying that a display protocol doesn't have to consider user input, then you are so wrong its actually stupid.

[oiaohm]

Don't you realize how stupid that is? A display protocol that has no possible way of acknowledging -INPUT-!! Have you ever used Wayland, like at all?What "feels" like input lag isn't really input lag, it's actually the fact that Wayland doesn't consider input -AT ALL-! Libinput -will NEVER- solve that. Nothing Kronos does can solve that.The blame falls squarely and solely on Wayland being incomplete and inadequate for desktop computers.

EDIT: If you're saying that a display protocol doesn't have to consider user input, then you are so wrong its actually stupid.

https://drewdevault.com/2018/07/17/Input-handling-in-wlroots.html

Point 5 particularly.
Your compositor then looked around to see if the pointer had moved over any new surfaces. Since wlroots doesn’t handle rendering or know where anything is displayed, this was a rather introspective question.

So input lag correct is not really input lag. How effective wayland compositor is at solving surface order really effects how bad your input lag is. Of course this will change on how many windows are in fact open. This delay is kind of unpredictable and input lag is always going to exist.

Libinput for gaming can solve this to point.

https://who-t.blogspot.com/2017/04/inputfd-protocol-for-direct-access-to.html

Its inputfd where a control can be passed straight past the compositor stack straight to program.

Due to the fact the amount of time input can be delayed in the processing stack.

But correct fix for input going though wayland protocol would still be in libinput or kernel level and application side.

https://wayland.freedesktop.org/libinput/doc/1.11.3/timestamps.html

Lets think if the libinput event timestamps were in fact from clock_monotonic. https://linux.die.net/man/2/clock_gettime So libinput/kernel records when it received the keyboard/mouse event. Now the application would be able to compare the timestamp on the event to clock_monotonic and work out how much delay was going on in the compositor and adjust.

Input lag counter measures need to start before the compositor and in the client. So yes this does not need to be wayland protocol stuff as such. The protocol can already send across input event timestamps just the current libinput timestamp is not highly useful.

This would be kind of the same solve as the presentation time solve. Programs can adjust so much for delays if they know what in hell the delay is. Having to guess delay that equals mess.

[duby229]

https://drewdevault.com/2018/07/17/I...n-wlroots.html
Point 5 particularly.
Your compositor then looked around to see if the pointer had moved over any new surfaces. Since wlroots doesn’t handle rendering or know where anything is displayed, this was a rather introspective question.

So input lag correct is not really input lag. How effective wayland compositor is at solving surface order really effects how bad your input lag is. Of course this will change on how many windows are in fact open. This delay is kind of unpredictable and input lag is always going to exist.

Libinput for gaming can solve this to point.
https://who-t.blogspot.com/2017/04/i...access-to.html
Its inputfd where a control can be passed straight past the compositor stack straight to program.

Due to the fact the amount of time input can be delayed in the processing stack.

But correct fix for input going though wayland protocol would still be in libinput or kernel level and application side.
https://wayland.freedesktop.org/libi...imestamps.html
Lets think if the libinput event timestamps were in fact from clock_monotonic. https://linux.die.net/man/2/clock_gettime So libinput/kernel records when it received the keyboard/mouse event. Now the application would be able to compare the timestamp on the event to clock_monotonic and work out how much delay was going on in the compositor and adjust.

Input lag counter measures need to start before the compositor and in the client. So yes this does not need to be wayland protocol stuff as such. The protocol can already send across input event timestamps just the current libinput timestamp is not highly useful.

This would be kind of the same solve as the presentation time solve. Programs can adjust so much for delays if they know what in hell the delay is. Having to guess delay that equals mess.

Talk about putting the cart before the horse.... So I hope you realize what you just described will -NOT- solve Waylands problem. The applications at the end of the stack will know exactly when an input event happened but will have to take guesses about how the display stack will behave. You've just moved the problem from the best possible place at the compositor to the worst possible place at the end user application. If the problem was solved at the display protocol, the compositor would totally solve the problem, but now according to your proposed solution each and every single app will have to individually solve the problem one application at a time. So dumb....

EDIT: And not only does it -NOT- solve the problem, but I absolutely guarantee your proposed solution will be exponentially more complex due to the fact that it will -require- an immense amount of duplicate effort in -every- single application. Every game, every program, every library, every everything.... And a huge proportion of what would -NEED- updated will never be, either because its a proprietary product or because the project doesn't have the developer time to do it.... What you proposed will -NOT- fix Waylands lack of input handling....

EDIT: Actually, after thinking about it more, I think your proposed solution would actually -highlight- the problem and would exacerbate it by making it so it can't be fixed just once, it would have to be fixed over and over and over and over and over and over and over and over and over and over........... endlessly..... With many cases where it -never- will be......