Wine's Wayland Driver Is Becoming Mature, May Aim For Upstreaming Early Next Year

[Weasel]

But, I don't agree with what you are saying in this thread. So, respect the opinions of others.

No. It's not about agreement or opinion. It's about the cringe shit he's posting. You, for example, didn't so I have no beef with you here, even though you also disagree with me.

[SilverBird775]

oddities

But, there is a second solution: let the others do it for Wayland. A bazaar solution.

Don't underestimate lazy developers. KDE and UBUNTU way will sort out the oddities as per usual.

[oiaohm]

But, there is a second solution: let the others do it for Wayland. A bazaar solution.

In this scenario, the Wayland protocol allows the compositors to define their own, custom protocols, routed and serialized through the Wayland socket. So, the most essential concept here is that there is only a single connection between the Wayland compositor and the Wayland client. The goal is to make any other "adjunct" connections between a Wayland compositor and a client unnecessary.

This is already what Wayland allows is custom protocols over wayland. This is why gnome, kde and wlroots have their own custom Wayland extensions. But before something can be added to core standard you have to get agreement.

But there is a problem here. X11 tried this single connection idea and we still end up with dbus. X11 protocol with nesting is a stack-able protocol just like wayland.

https://www.youtube.com/embed/9_uRUIctGd0

Its not a new thing for wayland compositors to operate inside other wayland compositers. Just like its not new for X11 to be nested inside X11.

display->compositor->compositor->.....->client is valid just like display->X11 server->X11 server->....->client.

LIke it or not "side-protocols" are requirement here.

https://gitlab.freedesktop.org/xdg/xdg-specs/-/issues/84

Yes even the systemtray solutions under X11 break once you get into sandboxing.

xfcemint like it or not sandboxing gets you to needing two connections from the client.
1) connection to display/input source this be wayland compositor or X11 these could be turtles all the way down.
2) connection to global interface this must have permission system this is being dbus at this stage.

Take globalshortcuts that a good example where turtles all the way down is really bad. Lets say you want to bind a globalshort cut.
1) Under X11 you bind by basically key logging everything this is not great as two different parties can try to claim the same key this can make global short cuts random mess.
2) Lets say you implement key filtering at one of the layers like wayland compositors allow. Now only when you window is active you are getting keys not good.
3) letss try registration of globalshort cuts in each compositor right now as you stack compositors you have to be syncing what globalshortcuts are registered between all compositors resulting lots of traffic up and down the wayland protocol(yes this was tried) adveresly effecting performance of graphics display. (sway did try a custom wayland protocol for this)
4) Dbus service for globalshortcuts. 1 party is put in charge of globalshort cuts. 1 list of globalshortcuts for the complete session can be kept. Filtering can be done exactly once and you have permission system. This is off the main display path so slightly slower not a problem.

xfcemint something you need to consider here is denial of service. Items being routed by dbus using what is define in xdg-desktop-portal if these slow these are not normally session breaking.

One of the reasons why X11 stopped by all major windows managers and desktop environments being used for toolbar icons is traffic over the single X11 IPC causing choppy performance.

Everything done by individual dbus services can basically be rate limited and secured. Rate limiting and secured does include performance overhead.

The reality is the x11 model of a single IPC did not work out that why we have dbus and x11 in our desktop sessions. Wayland protocol does not remove the reasons why dbus exists. Wayland Protocol work is a good time to consider what should have always been in dbus instead of being welded into X11. Yes X11 is older than dbus so lot of things were weld into X11 not because it made sense but because it was the only option..

[oiaohm]

Also note that it is not sufficient to just allow custom Wayland extensions. What I have proposed also depends on how well is this Wayland extension mechanism implemented. For example, there needs to be a mechanism specified by Wayland that allows negotiation of custom extensions between clients and the compositor, as I have mentioned. Also, there might be a question of a mechanism for priorities of messages and events. Also, I said that Wayland developers should play an active role in this custom Wayland extensions system. So, be careful not to misrepresent what I have said.

Problem here you are not seeing the fundamental problem. I have most likely not explained it well enough.

There may be other reasons why "we ended up with DBUS", for example: X11 was becoming too complicated to maintain. Thus, your claim that "single connection idea" must necessarily be unsucessful (since it failed on X11 before) is an invalid argument.

The problem is the point you just stated is disproved by the https://github.com/letoram/arcan lead developer. Because he took the X12 documentation and attempt to implement it and made A12. So his work did not have the too complicated to maintain.

Notice you said between clients and compositor. Is this true when using arcan ipc Shmif the answer is no. Clients use shmif socket/network port but on the other end is not a single process. So you are doing a screenshot under arcan the request to perform a screen shot may not have in fact got to the the arcan compositor.

https://github.com/letoram/arcan/wiki/Shmif

The shmif (shared memory interface) is used both to split engine components into smaller, less privileged processes for improving security, stability and performance but also to allow a higher flexibility and choice when it comes to data sources and data providers for specific tasks like video encoding and decoding, network communications and so on.

It is also used as a bridging transport for translating display server protocols and for implementing dedicated arcan-capable software backends.

Those arcan-capable software back-ends are like dbus services. This is not the X11 or Wayland Protocol IPC. Both X11 and Wayland protocol were really designed for display output.

Single connection idea is truly does not hold up. Dbus is 1 client to many processing applications. arcan IPC is 1 client to many processing applications.

https://wayland.freedesktop.org/faq....ading_toc_j_10 Why is wayland not over dbus. Simple dbus protocol was lacking a few things the compositor need to be able to replicate old X11 functionality. The important thing that not covered by the FAQ is that dbus was considered as the IPC for wayland.

arcan.
Client=>IPC routering->compositor or arcan software backend..... 1 to many
Dus
Client->Dbus service that is IPC routing->dbus service 1 to many.
Wayland
Client=>Compositor. 1 to 1.
X11
Client->Server again 1 to 1.
X12 document mandates 1 to many if X12 was going to keep network transparency..

The idea of negotiation custom extensions between client and compositor where the client can add custom extensions works with dbus and arcan shmif because you have IPC routing . Where is your IPC routing in the Wayland design to enable adding custom extensions on the fly. That right its not there.

Remember both X11 and Wayland allow turtles all the way down.
Client0->compositor0->compositor1->compositor2->compositor3 for this class compositor1 having client1 and so on connected. Now if a client3 negotiates to provide extra protocol feature should client2, client1 or client0 see it. Now if client0 adds a protocol feature should client3 see it. Should compositor2 between compositor 1 and 3 be able to filter out extension. Now this is where it turns nasty. Every one of those stacked compositors can have individual rules on what client application can see what.

There is a reason why arcan forbids stacking of arcan and it this problem. Early version of arcan allowed arcan to be stacked on arcan. You end up with too many IPC routers adding too much latency and a confusing mess of rules when you attempt to secure the IPC. Processing all those rules increase risk of denial of service all the extra data traffic traveling between compositors increases denial of service as well.

Wayland protocol fairly much has input devices flowing in 1 direction and output flowing in the other so keeping traffic levels under control so allowing stacking.

xfcemint like it or not the is a issue that comes about by allowing Wayland compositors to stack and X11 servers to nest that limits how Wayland and X11 protocol IPC can be used without causing issues.

Things would be different if Wayland IPC was in fact 1 client to many services but if Wayland IPC was 1 client to many services as we can see from arcan you would end up having to forbid stacking.

Wayland protocol + dbus protocol is a middle ground. Wayland protocol is the one you can stack safely and dbus is the one client applications can extend safely.

Like it or not when you design IPC systems you have to make choices some of them rule out particular uses.

xfcemint what you did was suggest what would break Wayland protocol design choices that allow Wayland compositors to stack.

1 to 1 connection idea is a failure this was documented with X12 requirements. 1 client to many services was documented as a X12 requirement and arcan implements that.

Windows and MacOS if you look closely for desktop at their core is 1 to many. Wayland protocol + dbus protocol is a work around to the fact that Wayland protocol is a 1 to 1. dbus started because X11 protocol is also a 1 to 1.

Problem here is the 1 to 1 design bit that wayland has does in fact come from some of the X11 features that the developer of Wayland wanted to keep. Arcan developer was not this restricted so got rid of the stacking feature.

Stacking feature is useful in some ways for compatibility layers and other things but having it has a price that has to be paid. Part of that price is a restriction on the IPC usage.

[oiaohm]

First of all, there is no "client3" in your description. I guess that you meant "compositor3". Compositor3 is not a client. Compositors 0, 1, and 2 are clients. That is probably an unintentional small mistake from your side.

If a compositor3 "negotiates to provide extra protocol feature", should compositor2, compositor1, compositor0 or client0 see it?
My answer: It depends.
- The compositor2 could decide that this feature does not need to be passed through to compositor1, so in that case compositor1, compositor0 and client0 do not see it.
- The compositor2 could decide to pass through the feature, in that case it must negotiate the feature with compositor1, and so on.

I said having client1 not being client1. Compositors are all client0 to the compositor under them.

Think client3 being like VLC registering it global hotkeys or system tray entry or so on. So try your answer again. So your answer was so far that all compositors could have their own rules so the fact your VLC global hotkeys or systemtray has not turned up could be any of the compositors fault right.

Yes providing a system tray entry under X11 was registering to provide extra protocol feature before dbus took over. Arcan putting up a systemtray entry is done over the Aracn IPC.

No it was not a unintentional mistake on my-side what I wrote was totally intentional.

[SilverBird775]

I must say that I can't quite figure out what you mean. Can you elaborate on this remark of yours?

It was the response to the Wayland missing features and its overall bare bone nature. A few key distributions (with commercial user base especially) will de-facto decide what the actual Wayland standard will be. It’s the early bird that gets the worm.

[Azrael5]

Xorg and Xwayland must be purged by 5 years in order to guarantee the maximum efficiency of linux operating systems making them Vulkan/Wayland based.

[oiaohm]

OK, it is possible that a few key distributions have a lot of influence.

In that case, I hope that those few key distributions will seriously consider what I have suggested in this thread, as my suggestions could benefit them and everyone else. Perhaps someone who agrees with me can notify some people involved in those key distributions about my suggestions. I mean, a lot of people read Phoronix forums.

https://github.com/letoram/arcan

The reality here is some distributions have picked up arcan. Those would be the parties interested in your ideas.

xfcemint think about it protocols implemented under dbus applications can have the same code with X11, Wayland and possible arcan.

Wayland protocol not coming everything and the kitchen sink means it should be simpler to replace in future.

There are fundamental limitations one connection for everything xfcemint can you name any OS desktop solution that has done that ever that has not end up in hell for attempting that.

Yes X11 end up in hell attempting to have single IPC for everything. Ywindows end up in hell attempting to have single IPC for everything. Early next OS attempted single IPC for everything and end up in hell.

Arcan is the closed to single IPC for everything that works. But the developer has had to restricted particular features to pull that off.

It really simple to suggest parties should do X without understanding why they are doing Y and the limitations of doing X.