Wayland 1.20 Planned For Release In December

[billyswong]

So your proposal is an IME infrastructure that works in GBM/DMA-BUF layer and functions even in non-composited fullscreen gameplay. This looks like a compelling suggestion that can truly push people to put IME away from display server / compositor. Way better than "Wayland protocol is not supposed to support this and that" as that has been heard too many times in too many cases and people got numb.

[oiaohm]

So your proposal is an IME infrastructure that works in GBM/DMA-BUF layer and functions even in non-composited fullscreen gameplay. This looks like a compelling suggestion that can truly push people to put IME away from display server / compositor. Way better than "Wayland protocol is not supposed to support this and that" as that has been heard too many times in too many cases and people got numb.

There is also the other problem that people are not look for the other options either. Yes two questions.
1) Does this own in the wayland protocol that is the compositor protocol? Yes this is asking what limitations being dependant on a compositor will this bring yes some of these limitations are going to be problem as I have listed with IME. So there are cases where stuff just does not fit to be done by the wayland compositor so does not fit to be in the Wayland protocols .
2) What are the other ways todo this feature that is possibly generic? This is a big problem people are not going over the other options. Its not just numb. People were not even consider the possiblity that other options could exist when someone said it does not suite the Wayland protocol.

https://gitlab.freedesktop.org/libinput/libei

This one is a good example where it uses dbus for security(that has some performance issue) and socket for fast communication and still able to fully bipass the compositor.

Reality here it is possible to have a collection of protocols. Wayland protocol be for compositor. Then we have another protocol that specialist in IME and possibly accessibility these are items that need to kept lock-step with toolkit developments.

GBM/DMA-BUF and the means to pass input around this stuff coming generic shareable is all sided effects of the wayland protocol/wayand compositor work.

Wayland work as made a new set of common foundations. Yes a common set of foundations from kernel level and gpu drivers.

Reality here no one would suggest making opengl/vulkan... 100 percent operate by using wayland IPC. Its really easy to miss that KMS/DRI/GBM/DMA-BUF are all parts that link back to the IPC system of the graphical drivers.

https://en.wikipedia.org/wiki/Wayland_(display_server_protocol)#/media/File:Wayland_display_server_protocol.svg

Yes some of the problem is we don't have a complete diagram of the Linux desktop.

Like that one there says Wayland display server protocol. But its showing that you have Wayland protocol between the applications and compositor yet you also have the applications going to EGL and then going straight out to the graphical so able to bipass the compositor.

pipewire with xdg-desktop-portal(over dbus) being used for screencapture this also means of bipassing the wayland compositor 99% of it operations.

billyswong we have a big case of tunnel vision where people are like X11 server did this so now it has to be part of the wayland protocol. Problem with the way X11 drivers were there was not the generic GBM/DMA-BUF or a lot of other generic IPC stuff(like dbus) when parts were added to the X11 protocol.

Wayland was and is a group of X11 developers taken the chance to rebuild what would have been the X11 core without a stack of extra stuff. With a true chance for use to go back to the draw board and think should this be in the compositor. Should this be using some other IPC or combinations of IPC.

Yes we have a very rich set of IPC options these days. We are not forced to attempt to use the display server/compositor IPC for everything any more. Yes some horrible examples exist in the X11 protocol from history of it being the only dependable IPC like Xprint( https://www.x.org/archive/X11R6.9.0/...ml/Xprt.1.html ) being print server in X11 protocol.

Yes due to broader IPC options it truly possible that a new IME could be made that is truly neutral does so it does not care if a applications in running on X11 server or running Wayland compositor or direct screen. IME is not the only thing like this. There is a serous need with all the features people are attempt to push into wayland protocol to ask the questions "Does this own in the wayland protocol that is the compositor protocol? " and "What are the other ways todo this feature that is possibly generic?"

Lot of cases of features where you see many attempted to add feature to the wayland protocol when you ask the questions the answers start showing it makes no sense to be in the wayland protocol. In fact most cases it will add extra complexity having it in the wayland protocol. IME is horrible enough to implement correct between the toolkits and the IME systems without putting every wayland compositor in the middle as well.

The environment we have now is very different to when the X11 protocol was mostly written. We really do need to go back to the drawing board and start fresh on a lot of features that were put in the X11 protocol. Lot of the features that are in the X11 protocol most likely should be pulled out into their own protocols and this is able to be done today that could not have been done even a year ago.

Why as wayland development been so slow as in 13+ years. Getting Nvidia to provide buffer solution for graphical in their binary drivers for Linux and freebsd that does not depend on wayland compositor/X11 server to keep on running has been teeth pulling. Yes IME using GBM/DMABUF without Nvidia recent change would have locked out all users of Nvidia closed source drivers.

The level of problem nvidia stubborn eglstreams has caused is a lot larger than people can dream. Remember 10 years wayland protocol core developers wanted to make GBM/DMABUF the graphical buffer handling standard for wayland that was blocked by Nvidia not coming on board. Yes this also explains why some people started to return to we have put huge stack of stuff in the wayland protocol that don't really own in wayland protocol.

[billyswong]

In this flow of logic one can also suggest sidestepping the CSD/SSD debate by introduce a "server side decoration" module that is independent of the compositor.

[oiaohm]

In this flow of logic one can also suggest sidestepping the CSD/SSD debate by introduce a "server side decoration" module that is independent of the compositor.

That is a valid possibility now. While we had the GBM/DMABUF vs eglstreams something like that was not possible. There are a lot more options to solve these problems than people have been considering. Yes its been annoying that Nvidia been in the way for 10 years restricting the options.

[Charlie68]

I don't think anyone really believes that the wayland rollout has gone smoothly. It's been a struggle.

However, the reason that it was made so minimal is precisely the same reason it's been such a struggle to port everything over and get all the necessary features working. It's because there is a very limited amount of resources being spent on this project. There's simply not enough manpower to accomplish much very fast.

Microsoft or Apple can dump $50 million in order to get a new desktop system up and running. Having a good desktop experience is fundamental to their business model in a way that just isn't there on Linux. With Linux, there's maybe a handful of guys employed by Red Hat and otherwise it's up to volunteers to do everything in their spare time, and lots of them are more interested in adding new features or bug fixes that people can see right away rather than digging into something low-level and largely hidden from human view like a display system.

wlroots is a way to share code between different compositors, as some people have criticized wayland for stopping. But Gnome and KDE don't seem very interested in it, so that's hardly wayland's fault at that point, it's what the developers are choosing to do.

It's not like sticking with X really would have solved all these issues, either, because the real problem is manpower. Hacking on extra features into X certainly would have taken less effort in the short term, but each new feature getting added just gets more and more difficult, and there's not enough manpower to do that indefinitely either. The goal with wayland was to try to reset back to a lower level of maintenance effort required, at least in the longer term, once everyone has switched over to using it. Getting to that point is just going to be rough.

I agree, but I think this "minimalism" thing should give way to common sense.
In a while we will end up with just one terminal, just because it's minimal, less chance of bugs etc. which is quite absurd.
What Xorg did before, composers have to do now, so if Wayland is thin, composers have become fat and I don't see the point.
For Microsoft or Apple it's different, they only have to support one DE, so it doesn't change much for them.

[Myownfriend]

so if Wayland is thin, composers have become fat and I don't see the point.

I feel like everybody is looking at Xorg and Wayland and assumes that compositors have to fill in the delta of the feature set between the two. They don't.

Some of the things that Xorg implements are things like font and primitive rendering APIs which aren't even used by most X11 clients. Wayland doesn't specify any rendering APIs; the clients just use whatever API they want and that doesn't require the compositor to implement anything anything. Compositors also don't need to implement their own way for clients to do frame capture.

Outside of all of that, keeping Wayland thin means that when a Wayland successor gets created, the adoption process won't be as arduous as it has been to go from X11 to Wayland.

[oiaohm]

What Xorg did before, composers have to do now, so if Wayland is thin, composers have become fat and I don't see the point.

Thing here is if the Wayland protocol gets fat all Wayland compositors will have to get fat.

X11 protocol did not stay thin. X.org group spend a lot of time delete bits that were added to the X11 protocol that no body was using but the X11 x.org server had to support because those items were in the X11 protocol.

Also do remember common sense is not that common. What seams like common sense can be the absolute worst idea.

Its like the idea of putting screen capture in the Wayland protocol as a required feature. This means you cannot have a direct rendering manager screen capture option if you did this.

There is a lot more thinking required. The xdg portol way of doing screen capture the compositor can decide to help with screen capture or the compositor can be bypassed for a direct rendering manager screen capture.

Thing to remember wayland protocol is purely designed to go between the client and the compositor. dbus and so on are not. Direct rendering manager screen capture for example would by pass the wayland compositor completely. Yes the direct rendering manager screen capture can capture all your text based termianls So ctrl/alt f1 to a framebuffer terminal still would be able to be captured. Same with using uinput to allow faked up input.

There is a lot of cases where adding a feature to wayland protocol would be basically tieing you hands on how the feature can be implemented and how much functionality the feature really can have.

[Charlie68]

Myownfriend oiaohm Mine was not meant to be a criticism of Wayland for how it was made, however when I hear that Wayland is skinny, it makes me smile, it's just a protocol.
Much of what used to be handled by Xorg is now handled by composers.

[oiaohm]

Much of what used to be handled by Xorg is now handled by composers.

That not just wayland compositors either. The amount of stuff that has to be handled by X11 compositors is quite insane as well. Part of why wayland started was that X11 developers started looking at how much in the X11 protocol was now depending on third party bits to work.

Yes due to how much is handled by X11 compositor makes it really hard these days to alter the x11 bare metal X11 protocol usage without running into the case you wish to change X you now need X11 compositors to update as well.

https://www.youtube.com/watch?v=GWQh_DmDLKQ this video on the real story behind why wayland goes into this as well.

The reality is X11 x.org bare metal server was not handling as much as what people think it does either. Lot of cases the X11 protocol end up mandating slow/horrible IPC operations for operations that really should not be done slowly. Yes this explains why opengl driver makers basically made their own bipass.

The wayland process is a good chance to look at everything and work out how should be hooked up. Of course this process is going to result in things needing to be different and also will be messy.

[Etherman]

Gnome wayland doesn't work on my perfectly fine radeon hd card. Xorg Gnome works perfectly smooth on the same card. Any ideas?

It works now.
Idk what has changed, mesa or gnome-shell, but it works now. 👍