NVIDIA 495 Linux Beta Driver Released With GBM Support

[tildearrow]

Having the option to use items before they are fully complete
This feature exist in all those distributions you just listed. SLES, RHEL, Ubuntu LTS and openSUSE all include packages you can choose to install and user that are not fully complete. Like it or not almost all Linux distributions do have early adopter nature. So software will be included before its fully functional.

Yes, but not *all* packages are incomplete.
Same thing on Windows though. You can enable features that are marked experimental.

This absolutely not different to the IPv6 process or the X11 protocol development process or many other development processes. Yes this is a process where you make several different and possible incompatible methods and them bless one that works the best into the standard/reference implementation. Of course to do this process you need some users.

Well, it's been 30 years and we still have like 10 different package managers (dpkg/apt, dpkg/apt-get, rpm/yum, rpm/dnf, rpm/urpmi, rpm/zypp, pacman, xbps, slackpkg, portage), 1000 different Linux distributions of which 10+ are prevalent, 6 different graphics APIs (OpenGL, DirectX 11, DirectX 12, Vulkan, Metal and PlayStation), 3 different user package formats (Flatpak, Snap and AppImage) and over 9000 Android phones. All of them different, incompatible and with nearly equal usage share.
Too much competition (particularly between GNOME and KDE) will prevent this "blessing" from occurring. Sorry.

1) global hotkeys is a unsolved problem with X11 protocol. They are many bugs that are caused by the way people hack around X11 protocol.

This is not getting why Wayland did not include it. How would like you to press a button to make a call only to find out the system stalled out for 15 seconds and you missed the call or if a mute was delayed. This happens under x.org X11 server at what appears to be random. Yes its the multi X11 input system mixed with multi different keylogggers running resulting in mega screw up.

The realty is every time you use a global hotkey under X11 you are rolling a dice if it works right. Yes it also a cause why input under X11 can stutter badly when particular mixes of applications are loaded.

So welcome to hell. You have users asking wayland developers to implement features of X11 that are in fact broken and not working right. These features need to be redesigned.

Adding a hotkey protocol to Wayland is as easy as it was to add the clipboard protocol. The only reason why it is missing is because the Wayland devs simply don't care.

Average Joe is not happy with the behavour of X11 in many places either. People complaining about not being able to restart Wayland compositor there is a mirror problem that you cannot restart x11 server generally either. Remember Xpra has been around for a very long time and if it methods had been embedded in toolkits there is a good chance that we could just randomally fully restart the X11 server.

That's an excuse to counter my argument...
Usually X.Org doesn't crash too often and is much more stable than any of the Wayland compositors out there.
In 6 years of Linux usage I only had X.Org crash 4 or 5 times, while I had GNOME Wayland crash 1 times in 48 hours of usage and KDE Wayland crash 20 times in 6 days of usage.
One crash per year for X.Org, one crash per month on GNOME Wayland (pretty sure stability has increased since), one crash every 6 hours on KDE Wayland (hopefully things are better now though).

The broken state of X11 you can find by look at the features that are missing from Wayland then checking out if they in fact work properly under X11. 99.9% of the time(and that not a guessed number) the case is X11 is also broken in that area. Lot of ways instead of demarding Wayland get particular feature instead the focus should be how to implement these feature so into the future it can work right under X11 and Wayland for new applications.

Yes, but better to have it "broken" but working than missing.
During survival, living with at least raw food or fruits is better than no food at all.
During a car battery failure, being able to start the car by pushing it and shifting to second gear while pressing the clutch is better than not being able to start it at all.
During a power outage, having at least a candle is better than not having a single lamp at all.

The correct solution as done by macOS is a permissions system.

This get interesting.

Yes

There is a problem here. Is most of this data query using the compositor protocol of MacOS. The answer is no. Wayland protocol is the compositor protocol. MacOS is use their equal to dbus back to the compositor for the Data query stuff on windows positions. This would be more like a freedesktop portal protcol like how screen capture is being done.

Then why is clipboard and scaling part of the Wayland protocol? By your definition they should be separate as well...

This is a hack that not part of the specification. MS-Dos by design did not technically support global hotkeys either. Yes the TSR hack. Please note both MS-DOS and X11 global hotkey hacks break down if you get too many applications attempting todo global hotkeys at the same time. This is not IT Works this is "It works for me while I am lucky" one day you lucky will run out.

Having the ability to at least work it out in a "hacky" way, as ugly as that sounds is better than not being able to work it out at all.

There is a third. People like you who have the idea that feature that don't exactly make sense to be in a compositor protocol should be in a compositor protocol.

Again, by that definition clipboard wouldn't fit in a *compositor* protocol. I thought Wayland was a *display server* protocol, not just a compositor one?

There are particular things that were done under X11 by hack methods that really should be moved to dbus and the likes of org.freedesktop.portal.

Doing these things in D-Bus would bring more problems:
1. No easy to use C/C++ implementation, forcing you to either use a bloated toolkit (GLib or Qt), an implementation that will break sooner or later (dbus-cxx or dbus-cpp or dbus-c++), an implementation that is tied to a specific system manager (sd-bus) or write a custom one with libdbus (pain).
2. Ironically the stutter problem from X would come back, and even worse than before. If something odd happens in the bus, by default the timeout is 30 seconds and I would miss the call as the application would stall since the bus glitched up.
3. Things become more complicated. Way more complicated which leads to lower performance (which kinda counters the point of Wayland, huh?).

The final standards for a wayland desktop should be a mix of wayland protocol for output and generic input and stack of dbus protocols for items that need permissions like query the real location of mouse on screen and real window positions.

Read above.

tildearrow the the third problem type that you are is that you have the wayland hammer in you hand and now everything thing to drive in has to be a nail right. The correct answer is not that black and white. Some things should be solved by wayland protocol, others should be solved in mesa/graphics stack and others should be solved with dbus protocols and there is possible another other.

Read above.

[tildearrow]

Wasn't aware of this whole page of discussion when I edited my last post where I mentioned that searching "'data query' Wayland" on Google only resulted in three relevant results on the first page and two of them were you. This explains why.

Excuse me. I merely don't know any shorter name for "querying mouse position, keyboard strokes, window positions and sizes, etc.".

[tildearrow]

Also I wasn't sure what "data query" was so I looked it up and when you search "'data query' wayland" on Google, the first page only brings up three relevant results and two are posts by you. Just based on that, it doesn't seem to be a super requested feature so I don't see why it would be so amazing that it's not part of the protocol yet. I'm not saying it wouldn't be a useful feature but I think some people are putting certain features at priorities that don't match their importance.

Read post above this one.

One of the aforementioned posts of yours, dated February 23, 2021, is from your website and says that Wayland was cleverly designed to be Gnome-centric. You said that Wayland's lack of support of server-side decorations was proof of that even though Wayland 1.15 added XDG-decoration to negotiation the use of CSD or SSD in 2018. Then you acknowledged that the extension existed in the next sentence and complained that Gnome and Weston didn't implement it and said the only reason they didn't implement it was because they were selfish and wanted to pretend that KDE/MATE/Cinnamon didn't exist. I'm not exactly sure what Gnome and Weston have to do with them though. There's no way to comment on your site so I'm asking for an explanation here.

Sure!

https://arcan-fe.com/2018/01/27/argu...e-decorations/

https://blog.martin-graesslin.com/bl...s-and-wayland/

https://blogs.gnome.org/tbernard/201...sd-initiative/

KDE devs push for SSD while GNOME and Wayland devs push for CSD. This creates endless conflict.

Also why not write a draft for these extensions yourself or at least open an issue or participate in discussions on Wayland's Gitlab?

For data query and global hotkeys? Already done, but the problem is that the one who proposed them is known for his bad behavior and also I don't agree with some of the points...

Furthermore I've heard that Wayland works as a meritocracy, and since I have not done anything for the protocol it would be very unlikely to get my draft accepted.

[Myownfriend]

Again, by that definition clipboard wouldn't fit in a *compositor* protocol. I thought Wayland was a *display server* protocol, not just a compositor one?

I think they're saying compositor and display server interchangeably since they're the same thing in Wayland.

Also they're completely correct that MacOS doesn't implement data query in the display server/compositor protocol. Its part of the accessibility API.

Sure!

https://arcan-fe.com/2018/01/27/argu...e-decorations/

https://blog.martin-graesslin.com/bl...s-and-wayland/

https://blogs.gnome.org/tbernard/201...sd-initiative/

KDE devs push for SSD while GNOME and Wayland devs push for CSD. This creates endless conflict.

Who cares if they have disagreements though? Of course they will. You were claiming that Wayland was Gnome-centric because of it's lack of support for SSD but you already knew that Wayland doesn't prefer or require CSD or SSD and has a means to negotiate which is used. That's counter to the point you were making.

For data query and global hotkeys? Already done, but the problem is that the one who proposed them is known for his bad behavior and also I don't agree with some of the points...

Birdie can't make a case to save his life, though. I mean the dude even mentions drag and drop not being part of Wayland when it already is. If you want to make the case for these things then you should join in the discussion. You're allowed to respond and say that you agree about some of the things he said and not others.

Furthermore I've heard that Wayland works as a meritocracy, and since I have not done anything for the protocol it would be very unlikely to get my draft accepted.

Test out what you heard then. Plus Simon's response to global shortcuts wasn't a flat out "no". He said "Global shortcuts: needs someone to work on a Wayland protocol". You can be that someone.

[oiaohm]

Adding a hotkey protocol to Wayland is as easy as it was to add the clipboard protocol. The only reason why it is missing is because the Wayland devs simply don't care.

This is wrong. KDE and Gnome have both been working on a hotkey protocol.
https://blog.martin-graesslin.com/bl...yland-session/ have been for a while. By having a dbus solution under X11 fixes up some serous problems caused by stacking of .

Again, by that definition clipboard wouldn't fit in a *compositor* protocol. I thought Wayland was a *display server* protocol, not just a compositor one?

That where you are totally screwed up. Wayland protocol define is compositor not display server.

https://wayland.freedesktop.org/docs/html/

Wayland is a protocol for a compositor to talk to its clients as well as a C library implementation of that protocol. The compositor can be a standalone display server running on Linux kernel modesetting and evdev input devices, an X application, or a Wayland client itself. The clients can be traditional applications, X servers (rootless or fullscreen) or other display servers.

This bit of text is important. Wayland is for compositor communication not for total display server protocol. Display server solutions using Wayland protocol are allowed to use other protocols like xdg desktop portal that is over dbus for things. Wayland protocol is not X11 protocol. X11 protocol was a complete cover everything protocol. Wayland protocol is absolutely not cover everything protocol.

So your thought here is completely wrong tildearrow.

Then why is clipboard and scaling part of the Wayland protocol? By your definition they should be separate as well...

Scaling does fall under the role of a compositor that is something the compositor should control/do.

https://wayland.freedesktop.org/docs...-wl_data_offer
This is where things get wacky. Clipboard support in wayland core protocol is a side effect of implementing drag and drop. Rendering drag and drops fall under compositor.

Doing these things in D-Bus would bring more problems:
1. No easy to use C/C++ implementation, forcing you to either use a bloated toolkit (GLib or Qt), an implementation that will break sooner or later (dbus-cxx or dbus-cpp or dbus-c++), an implementation that is tied to a specific system manager (sd-bus) or write a custom one with libdbus (pain).
2. Ironically the stutter problem from X would come back, and even worse than before. If something odd happens in the bus, by default the timeout is 30 seconds and I would miss the call as the application would stall since the bus glitched up.
3. Things become more complicated. Way more complicated which leads to lower performance (which kinda counters the point of Wayland, huh?).

Sorry shoving everything down a single IPC will also bring very big problems. Wayland protocol IPC does not have a permission system. This is because it a compositor IPC. D-Bus is a IPC designed with a permission to be integrated.

For data query and global hotkeys? Already done, but the problem is that the one who proposed them is known for his bad behavior and also I don't agree with some of the points...

https://gitlab.freedesktop.org/wayla...3#note_1048220

This response is important.
Screen recording and casting be it gnome kde or wlroots based it is xdg-desktop-portal.

Screen recording and casting
Querying of the mouse position, keyboard LED state, active window position or name, moving windows (xdotool)
Global shortcuts
System tray
Features like drag-n-drop
Graphical settings management (i.e. tools like xranrd)
Fast user switching/multiple graphical sessions
Session configuration including but not limited to 1) input devices 2) monitors configuration including refresh rate / resolution / scaling / rotation and power saving 3) global shortcuts

This is your list right tildearrow. Drag-n-drop is part of core Wayland protocol wl_data_offer so what the hell is that doing in your bug report in the first place. Drag and drop to X11 clients on wayland and back has been a complex ass because there are 8 different drag and drop protocols in X11 protocols. Xwayland is finally getting that nightmare sorted. Yes drag and drop has worked pure wayland to wayland application from day 1 without issue. That the clipboard and drag and drop works at all under X11 is more example of toolkit developers and applications developers have hacks on to of hacks that somehow about 95% of the time works. This kind of made getting Xwayland clipboard/dnd to work to wayland applications kind of problem child.

Screen recording and casting that under xdg-desktop-portal why this need permissions. This is why extend to wayland protocol to support Screen recording was hit on the head something being a compositor protocol wayland does not have is a permission processing system.

Querying of the mouse position, keyboard LED state, active window position or name, moving windows (xdotool). This complete list does not own in wayland protocol for the same reason Screen recording does not. All these actions should require permissions to be able to be done. Gnome has query LED state by dbus.

Global shortcuts this problem need to be solved on X11 as well to prevent breaking X11. KDE has KGlobalAccel I would love to see global short cut registration appear as xdg desktop portal. Remember under wayland global shortcuts still need to solved for X11 applications so Xwayland can work. Remember that one person recently point out you could block applications for getting key strokes under X11 when you were not over that applications window. This breaks all X11 global short cut methods other than the likes of KDE one where can need to authorise 1 service. So global shortcuts is something we need a generic X11/Wayland solution to. Wacky would be add a new minetype called globalshort cut and when you put that in the clipboard that is to be registered as your applications global shortcut.

Graphical settings management (i.e. tools like xranrd)<< This. Should this be done over a protocol without permissions? I would say no. I would say Graphical setting management is another thing that owns under xdg desktop portal or equal.

Fast user switching/multiple graphical sessions<< This one X11 and Wayland protocols both don't cover. There is work outside Wayland and X11 to cover this problem. This is the fast check point and restore work on top of the normal tty stuff.

Session configuration including but not limited to 1) input devices 2) monitors configuration including refresh rate / resolution / scaling / rotation and power saving 3) global shortcuts<< This is another stack of what the hell. This list of items you don't want to be doing over a protocol that for compositor that does not have a heavy permission system. Dbus has Polkit and processing Polkit has overhead. You think about it wayland protocol core IPC is design to be fast for graphic compositor work if it has to slow everything down to be checking permissions all the time performance is not going to be great. One of the big problems with xace and X11 is that you are processing permissions on everything so having terrible performance.

tildearrow there is a valid reason to have two IPC solutions in a desktop solution. Apple with Mac OS and IOS has two IPC solutions. Android has two IPC solutions. The stuff you are asking for majority is what Android would do over binder this is not the IPC on Android for the graphical yes that is surface flinger IPC. Yet with what you are requesting is trying to force everything though 1 IPC.

dbus/polkit for where you need permissions processed this could be slow. wayland protocol IPC for where it need to be reasonable fast without the overhead of processing permission system where possible.

[oiaohm]

I think they're saying compositor and display server interchangeably since they're the same thing in Wayland.

https://wayland.freedesktop.org/docs/html/

Wayland is a protocol for a compositor to talk to its clients as well as a C library implementation of that protocol. The compositor can be a standalone display server running on Linux kernel modesetting and evdev input devices, an X application, or a Wayland client itself. The clients can be traditional applications, X servers (rootless or fullscreen) or other display servers.

I am sorry to say no. A person using display server and compositor interchangeably with wayland is making a mistake. A wayland compositor can be display server not that wayland protocol is a display server. The wayland protocol is only for compositor. Thinking wayland protocol extends to cover all the features of a display server leads to tildearrow level of mega goof up.

[xanas]

Question about this beta driver... with some background first

I'm on Manjaro. I have the latest plasma there, which seems to be right version of this. I'm using linux-tkg from FroggingFamily-git along with the 495 driver from the same location. This works fine in X11, and I can get the plasma wayland session to load (as well as gnome plasma) whereas I couldn't in the past. But... there is a lot of latency for everything (animations themselves seem to be smoother if anything, but lots of slowness elsewhere). The gnome wayland session works similarly, so I don't think it's anything special to plasma that is the issue.

I am not sure where to even go to troubleshoot anything for this but I am interested. One thing I am hoping to get out of it is independent display scaling as I have a 4K monitor mixed in with an 3440x1440 and a 2560x1440. I was actually able to scale it to 150% in gnome and that part of it worked really well, better than windows as the transitions of windows between displays were almost seamless.

Is there any sort of guide on what needs to be done to get it working in either plasma or gnome? I'm not committed to any particular DE as long as it works. I kind of like switching about from one to another from time to time.

[tildearrow]

https://wayland.freedesktop.org/docs/html/

Wayland is a protocol for a compositor to talk to its clients as well as a C library implementation of that protocol. The compositor can be a standalone display server running on Linux kernel modesetting and evdev input devices, an X application, or a Wayland client itself. The clients can be traditional applications, X servers (rootless or fullscreen) or other display servers.

I am sorry to say no. A person using display server and compositor interchangeably with wayland is making a mistake. A wayland compositor can be display server not that wayland protocol is a display server. The wayland protocol is only for compositor. Thinking wayland protocol extends to cover all the features of a display server leads to tildearrow level of mega goof up.

Then Windows would be a Microsoft level of giga goof up because it would be worse than X11 in this regard. The data query functions are freaking system calls which have the possibility of stalling the system (and it used to happen often, especially in the Windows XP era).

Furthermore I did not say all features. It is fine to have window/screen capture on a separate channel (like PipeWire), but for something that's low-bandwidth like data query, come on.

[oiaohm]

Then Windows would be a Microsoft level of giga goof up because it would be worse than X11 in this regard. The data query functions are freaking system calls which have the possibility of stalling the system (and it used to happen often, especially in the Windows XP era).

Yes Microsoft did make this level goof up but they also have fixed most of it. Windows Vista Microsoft did add a compositor IPC this is why the problem stopped being common after the XP era on Windows. Mac OS 9 had the same problem Mac OS X is where you see the compositor IPC and accessibility IPC appear on Apple Mac OS so the split into dual IPC.

The first one split the into two IPC is Beos. Next os to split was OS/2 Warp then next/macos then windows. Remember windows was the last to start fixing properly and that was over a decade ago. X11 and Wayland is kind of major tail of hunt here on fixing this problem.

Dual IPC is the normal on everything else now. Yes android has a IPC for compositor and IPC for the data query stuff that is independent to each other. X11 protocol is like the last thing that was attempt to do everything by a single IPC and hard reality this method of having a single IPC as soon as you attempt security turns to hell for everyone. Yes everyone include Microsoft, Apple and IBM who tried this single IPC stuff.

Furthermore I did not say all features. It is fine to have window/screen capture on a separate channel (like PipeWire), but for something that's low-bandwidth like data query, come on.

The problem is not just low-bandwidth. Problem is a lot of the features in the list are features for security reason or stability reasons should be behind a permission system. dbus with polkit exists that is a IPC with permissions.

Think xrandr when application uses this there is nothing in the design to allow screen mode to switch back in case of application termination or in case of tab away from application that changed those values. Yes those nicely messed up desktop icon locations because you tabbed off a full screen application that had xrandr the screen. Using dbus service for xrandr this it possible to be a lot smarter.

Lot of the data query stuff in you list is stuff that you may need to fake in future. Think about you have a program that when you plug in a 4k screen and it get information about a 4K screen it dies due to some coding bug because it was only tested with 1080p screen do you wish to have to patch the compositor side to work around this.

Data query stuff lots of it you want independent to the compositor IPC so that when required you can fake answers without messing with the compositor IPC. I said the compositor IPC is missing permissions its also missing a system for per application hacks. Really low latency output and input path you don't want lots of permissions and per application hacks.

dbus was really designed as desktop data query IPC right down to including a fully functional permission system plugin system.. Yes the libraries and other interfaces to dbus does need work as well.

tildearrow note you said low bandwidth so this is not needing high speed right. Compositor IPC is for high speed traffic does not need to be stalled on by low speed traffic. Yes why in most countries its illegal to be in the high speed lane on a road with a slow item because it can cause congestion as well. This is something you have be careful not todo on the compositor IPC. Not everything owns in the wayland protocol because its a Compositor protocol for a Compositor IPC.

Yes some of the remaining glitches in Windows 10 are because Microsoft did break the rules in a few places with the same arguement you are making "Its only low bandwidth putting this though the compositor IPC will not cause any problems right?" and of course the answer is going to be no it will cause problems at some point. So learning from Microsoft mistakes here no way in hell does your arguement hold up.

Current functional answer is dual IPC. Wayland protocol only has one IPC because the lead developer was not going to reinvent the wheel when dbus already existed. So yes dbus and wayland protocol were originally intended to be used in combination with each other so giving a dual IPC solution.

https://github.com/wayland-project/weston/blob/58dba727c910665c7d4891b8b991226e4d3b28f2/libweston/dbus.c

tildearrow maybe the dbus support code should be moved out of libweston and moved into libwayland? Yes the first version of weston the reference wayland compositor has it using dbus in combination with wayland IPC to give the dual IPC system. When you need dbus support anyhow to match the functionality for the reference wayland compositor why are you attempting to force everything though the wayland protocol/Wayland IPC?

[tildearrow]

This is wrong. KDE and Gnome have both been working on a hotkey protocol.
https://blog.martin-graesslin.com/bl...yland-session/ have been for a while. By having a dbus solution under X11 fixes up some serous problems caused by stacking of .

The problem is that this solution is vendor-specific and tied to one implementation (kglobalaccel5). This means that any other compositor would have to pretend to be kglobalaccel5 and even bring in some other toolkit like Qt or KF5, which is super messy.

That where you are totally screwed up. Wayland protocol define is compositor not display server.

https://wayland.freedesktop.org/docs/html/

Wayland is a protocol for a compositor to talk to its clients as well as a C library implementation of that protocol. The compositor can be a standalone display server running on Linux kernel modesetting and evdev input devices, an X application, or a Wayland client itself. The clients can be traditional applications, X servers (rootless or fullscreen) or other display servers.

This bit of text is important. Wayland is for compositor communication not for total display server protocol. Display server solutions using Wayland protocol are allowed to use other protocols like xdg desktop portal that is over dbus for things. Wayland protocol is not X11 protocol. X11 protocol was a complete cover everything protocol. Wayland protocol is absolutely not cover everything protocol.

So your thought here is completely wrong tildearrow.

Using D-Bus means that if the compositor processes D-Bus messages in a synchronous and single-threaded way then the stutter problem would not be gone.

Scaling does fall under the role of a compositor that is something the compositor should control/do.

https://wayland.freedesktop.org/docs...-wl_data_offer
This is where things get wacky. Clipboard support in wayland core protocol is a side effect of implementing drag and drop. Rendering drag and drops fall under compositor.

.............

Sorry shoving everything down a single IPC will also bring very big problems. Wayland protocol IPC does not have a permission system. This is because it a compositor IPC. D-Bus is a IPC designed with a permission to be integrated.

Sorry using D-Bus means possible stutter and stalls. If the compositor does not do it well and handles D-Bus events in a synchronous, single-threaded way (it potentially could!) then it will be no different from X11 in this regard.

https://gitlab.freedesktop.org/wayla...3#note_1048220

This response is important.
Screen recording and casting be it gnome kde or wlroots based it is xdg-desktop-portal.

Screen recording and casting
Querying of the mouse position, keyboard LED state, active window position or name, moving windows (xdotool)
Global shortcuts
System tray
Features like drag-n-drop
Graphical settings management (i.e. tools like xranrd)
Fast user switching/multiple graphical sessions
Session configuration including but not limited to 1) input devices 2) monitors configuration including refresh rate / resolution / scaling / rotation and power saving 3) global shortcuts

Regarding this list

Screen recording and casting? Already done by PipeWire which seems to be what most compositors are using.
Querying of the mouse position, keyboard LED state, etc. (data query)? This is missing. AT-SPI2 is not a solution as it is incomplete and GNOME-only. So it is missing, at least in a standard way.
Global shortcuts? This is missing. At least in a standard way.
System tray? I personally ignore this point, but yeah. It could be something like org.freedesktop.ApplicationTray1 or wait even better why not extend the notification system to support it?
Features like drag-n-drop? Already done
Graphical settings management? Missing in a standard way. Currently you have to use D-Bus and rewrite your code THREE times. One for KWin (KScreen), one for GNOME (whatever it is) and one more for Sway (wlroots). And if somebody uses Weston then you are out of luck as it does not provide any interface for display setup. If there was a standard, like org.freedesktop.DisplayConfiguration1 then that would be nice.
Fast user switching/multiple? I ignore this point.
Session configuration? I ignore this point as well.

tildearrow there is a valid reason to have two IPC solutions in a desktop solution. Apple with Mac OS and IOS has two IPC solutions. Android has two IPC solutions. The stuff you are asking for majority is what Android would do over binder this is not the IPC on Android for the graphical yes that is surface flinger IPC. Yet with what you are requesting is trying to force everything though 1 IPC.

dbus/polkit for where you need permissions processed this could be slow. wayland protocol IPC for where it need to be reasonable fast without the overhead of processing permission system where possible.

Thing is that the secondary IPC on Windows, macOS, iOS and Android is fast. Android does it at a near-kernel level. Windows does it using syscalls.
But D-Bus is slow. Usually.