Wayland Clients Can Now Survive Qt Wayland Crashes / Compositor Restarts

[oiaohm]

Even if the compositor has no read permissions it can still give out a handle. Dealing with permissions and access could then be handled in the program doing the capture when it tries acessing the buffer by whatever mechanism.

Nvidia also lacks support for DRI3 and other things. It didn't even support gbm as commonly used in Wayland at all. Still, people moved on and Nvidia eventually relented. I think they do support it to some degree now, at least you don't need EGLStrerms any more.

https://download.nvidia.com/XFree86/...EADME/gbm.html
Yes they do support gbm now. Yes the libgbm interface has functional implicit sync interfaces when you use it.

The reason I think this belongs into the compositor is because you need to talk to the compositor directly if you want the frames as soon as possible for the lowest latency. Otherwise you have wait until the compositor actually submits a frame to the kernel for scanout or maybe even until next vblank if this is done suboptimally in the kernel but I don't know if it's that bad.

Except that is not how the systems working again. dmabuf at the wayland compositor from application contents may not be GPU rendered yet. Wayland compositor yes wants to provide the GPU the information of what instructions to make the frame to render as close to the vblank as possible. Notice I said make the frame to render Wayland compositor is not holding the output frame. Wayland compositors don't in fact submit frame for scanout as such when using GPU acceleration. Wayland compositors send directions to the GPU on how to assemble frame for scanout. The scanout frame only exists in the GPU. This is why now direct KMS/GBM comes in to get the scanout you need to request the GPU sends it back. Maybe you want the GPU to compress that to save some PCIe bandwidth.

The reality is you are not getting the rendered frame back with Wayland until after vblank in most cases because that is when the GPU will have in fact created it before that it just a set of numbers saying where different buffers go. Think paint by numbers item that what you have at the Wayland compositor and this is what wayland compositor sent with a set of dmabuf to paints use as to the GPU and its the GPU who is the party who paints the picture yes some of those colors in the dmabufs need the gpu painter todo some final mixing to make their colors as well. Attempting to get the scanout early just gets you the paint by numbers representation with partly mixed paints.

Yes you have been making the mistake thinking a paint by numbers with part mixed paints is a final painting. Wayland is design this way to reduce the latency.

And yes, dbus is how I'd expect a modern desktop to handle input. The compositor's job would then be to tell dbus where to send events (focused window) but it shouldn't have to deal with input otherwise, except for its own when you type the close window shortcut or something. Of course, this requires a way to register those shortcuts (inputd?), something which is still WIP in Wayland, too.

Wayland Protocol is one IPC and dbus is a different IPC. Wayland protocol IPC does the delivery of events to active windows.

https://github.com/flatpak/xdg-desktop-portal/blob/main/data/org.freedesktop.portal.GlobalShortcuts.xml

DBUS items you don't see in Wayland protocol. This is xdg-desktop-portal. DBUS is handling the inactive window Global Shortcuts cut delivery. Dbus xdg-desktop-portal being a high privilege thing can be requesting straight from libinput or straight from the input device itself so bypass the Wayland compositor. . Yes this is new as of Sep 2022 and will take a while to be implement though and wrappers created for legacy applications.

Yes stacking wayland compositors if wayland compositors are in charge of global short cuts handling conflicts is going to be trouble. xdg-desktop-portals is a stack of dbus services and all dbus services are like their own applications. Yes the generic xdg-desktop-portal implementation of GlobalShortcuts will be able to work no matter the Wayland compositor/X11 server you are using because it will just go to the raw kernel level input events as it has the privilege todo this.

Yes the X11 solution for global shortcuts is simply every application with a global shortcut capture all input and filter out the short cut application needs this is why you could have two or more applications attempt to come active under X11 at the same time when you pressed global short cut and if both programs were deterred to activate end in cat fight consuming all CPU resources. So correct handling of global shortcuts is something X11 desktops need as well. So it make sense for the solution to generic.

[smitty3268]

In no way, does the Wayland devs refusal to fix their broken standard have anything to do with funding. Funding lets people quit their day jobs and get something done faster. When they refuse to even begin the journey of going down the path towards fixing this dumpster fire, that is not a funding problem.

If someone was paying them, it'd get done because their bosses would tell them to do it or they'd be fired. The very option to refuse only exists because of the lack of funding. They aren't paid, so they tell people to file bugs in the apps that do have paid developers.

[Barnacle]

If someone was paying them, it'd get done because their bosses would tell them to do it or they'd be fired. The very option to refuse only exists because of the lack of funding. They aren't paid, so they tell people to file bugs in the apps that do have paid developers.

The solution, as you are describing it, is to pay somebody else (other than the Wayland developers) to either fork Wayland, or just come up with a new standard without all of the mistakes of Wayland. Which, frankly, is where this is all headed anyway, as we enter year 14 of struggling to make Wayland viable for real users. At some point, people are going to have to come to grips with Sunk Cost Fallacy on this one.

[oiaohm]

If someone was paying them, it'd get done because their bosses would tell them to do it or they'd be fired. The very option to refuse only exists because of the lack of funding. They aren't paid, so they tell people to file bugs in the apps that do have paid developers.

Large number wayland developers are paid.

The solution, as you are describing it, is to pay somebody else (other than the Wayland developers) to either fork Wayland, or just come up with a new standard without all of the mistakes of Wayland. Which, frankly, is where this is all headed anyway, as we enter year 14 of struggling to make Wayland viable for real users. At some point, people are going to have to come to grips with Sunk Cost Fallacy on this one.

Really please do not be the made up mistakes that are not based on how everything works.

Yes screen-capture is good one. wlroots did implement screencapture by wayland. You read the protocol extension wlroots did they had to include message being you know that DMABUF that you were sent its now invalid. Yes too slow to pick up the dmabuf and you find it been freed as well..

Barnacle its not the Sunk Cost Fallacy. At some point people have to stop asking for features to be added to the wayland protocol that simple don't work in the Wayland protocol well because Wayland protocol is too far abstracted away from hardware or does not have the security framework.

Lot of people forgot when Wayland started the wayland developer looked at using just pure dbus. Dbus IPC protocol is not low latency enough.

Its bit of a hard concept for people get brain around that dbus protocol and wayland protocol are design to solve different problems and they are perfectly designed to cover each other weaknesses.

Barnacle there is been a lot of time wasted in answering issues asking for features on Wayland that absolutely don't suit Wayland Protocol and people not accepting the answer.

There is another problem people saying we will stay on X11 so we don't have to fix anything. Systemtray moved across from X11 solution to dbus solution before Wayland existed.

Remember screencapture under x11 if you xnest applications or use any of the X11 forms of sandboxing it comes not really functional. Same applies to globalshort cuts and so on. There is a stack of things broken under X11 that need fixing. Those happen to be 99% alignment with the features people complain about being missing from Wayland. There is need to work on some generic solutions.

[gotar]

I don't care about compositor hotkeys. I have those on X11 as well and barely use.
[...]
I'm a power user, not a mobile peasant who just wants to watch movies on his fucking phone.

This made me wonder - how does Wayland cope with accessibility aids like screen readers?
Are visually impaired in a need to write their own entire compositor? In 2023?

[gotar]

honestly i dont want apps to be able to set global shortcuts, seems like a keylogger risk to me. If i want global shortcuts it should be set through compositor settings by the user. Where global shortcuts can be passed to certain apps. priviliges should be de escalated not escelated.

I got some bad news for you. Wayland doesn't prevent any keygrabbing. Wayland doesn't provide app separation. Wayland doesn't isolate resources.

The only thing that Wayland does (not), when compared to X11, is that it doesn't implement a (secure nor insecure) way for the job.
Wayland security model is not even obsoleted (for a decade), it's nonexisting.

Last week I've escalated my (fine-tuned) restricted environment ...by accident (tab-completed into wrong option), via dbus. The core problem is well known and a few approaches has been made in the past to solve it, all failed.

If you want to have secure Linux (regular) desktop, you're restricted to run only one app per user account.

[intelfx]

This made me wonder - how does Wayland cope with accessibility aids like screen readers?
Are visually impaired in a need to write their own entire compositor? In 2023?

Exactly in the same way as X11 used to "cope" with accessibility aids. It is all done at the toolkit level over D-Bus, as neither X11 servers nor Wayland compositors have any (useful) knowledge of the layout or logical contents of the windows.

[intelfx]

I got some bad news for you. Wayland doesn't prevent any keygrabbing. Wayland doesn't provide app separation. Wayland doesn't isolate resources.

The only thing that Wayland does (not), when compared to X11, is that it doesn't implement a (secure nor insecure) way for the job.
Wayland security model is not even obsoleted (for a decade), it's nonexisting.

Last week I've escalated my (fine-tuned) restricted environment ...by accident (tab-completed into wrong option), via dbus. The core problem is well known and a few approaches has been made in the past to solve it, all failed.

If you want to have secure Linux (regular) desktop, you're restricted to run only one app per user account.

Wayland (in and of itself) does not prevent keygrabbing, true (it is not a security framework, dumbass, it cannot "prevent" anything). That's still one step above X11 because X11 facilitates keygrabbing (and anything-grabbing).

Maybe you would like an analogy. Imagine a fence with lots of holes in it. Wayland is a piece of solid fence erected in place of a gaping hole (X11). Surely, it does not close any other holes in the fence, those have to be addressed separately. Yet, it is a necessary step towards a fully solid fence.

[Weasel]

Wayland (in and of itself) does not prevent keygrabbing, true (it is not a security framework, dumbass, it cannot "prevent" anything). That's still one step above X11 because X11 facilitates keygrabbing (and anything-grabbing).

No, X11 gives you the feature to "grab" it so any LEGIT app can do it in a clean way, without roundabout hacks. Now, if X11 would isolate such requests from different users it would be perfect (just like Windows' model).

Wayland doesn't give you this feature so you need either: custom extension per compositor (i.e. a compositor-specific "hack" on the app side making use of it), or even worse, driver-specific hack to e.g. grab the framebuffer. This is possible without special privilege, it's just that legit apps don't fucking want to do workarounds like this.

Malware doesn't care of any of that. It will do the worst hacks you could think of to exploit anything. It's only legit apps that want to grab your stuff for legit purposes that will suffer.

So what does Wayland accomplish here? Piss off legit apps and legit screen grabbing / key grabbing (as i outlined above several use-cases), while malware is still unrestricted.

Complete bullshit pseudo "security".

[piotrj3]

No, X11 gives you the feature to "grab" it so any LEGIT app can do it in a clean way, without roundabout hacks. Now, if X11 would isolate such requests from different users it would be perfect (just like Windows' model).

Wayland doesn't give you this feature so you need either: custom extension per compositor (i.e. a compositor-specific "hack" on the app side making use of it), or even worse, driver-specific hack to e.g. grab the framebuffer. This is possible without special privilege, it's just that legit apps don't fucking want to do workarounds like this.

Malware doesn't care of any of that. It will do the worst hacks you could think of to exploit anything. It's only legit apps that want to grab your stuff for legit purposes that will suffer.

So what does Wayland accomplish here? Piss off legit apps and legit screen grabbing / key grabbing (as i outlined above several use-cases), while malware is still unrestricted.

Complete bullshit pseudo "security".

I would add one more log to a fire.

X.org has known issues with security but because it is everywhere with one responsibility it is suprinsingly audited quite a lot. So technically speaking X has a lot of responsiblities that are kinda audited, and all surrounding stuff X that depends on DE, distro etc. are of course audited less but because they have lower responsibility that's not so big issue. Because now compositors took certain responsibilities that X previously had, now security wise you have to audit those pieces as well (to have let's say equal confidence by auditing). But no one gonna audit now all diffrent compositors/DEs one by one.

When I don't doubt base of Wayland is more secure then X. And I don't doubt you could make secure Wayland sessions with proper sandboxing with cgroups, properly written Rust compositor, audits. But is it your default Ubuntu, Fedora, OpenSuse enviroment? And I underline that DEFAULT?