KDE On Wayland: "The Biggest Thing Needed Now Is Adoption By 3rd Party Apps"

[MrCooper]

But Xwayland depends on xserver. So, not even Fedora users could uninstall xserver without issues.

I wrote Xorg, not xserver. And those who know me know I wouldn't make a claim like that without verifying it first:

> sudo dnf remove xorg-x11-server-Xorg
Dependencies resolved.
================================================================================
 Package                 Arch   Version                           Repo     Size
================================================================================
Removing:
 xorg-x11-server-Xorg    x86_64 1.20.14-24.fc39                   @fedora 3.7 M
Removing dependent packages:
 gnome-session-xsession  x86_64 44.0-2.fc39                       @fedora  15 k
 xorg-x11-drv-amdgpu     x86_64 23.0.0-2.fc39                     @fedora 190 k
 xorg-x11-drv-ati        x86_64 19.1.0-10.fc39                    @fedora 501 k
 xorg-x11-drv-evdev      x86_64 2.10.6-14.fc39                    @fedora  78 k
 xorg-x11-drv-fbdev      x86_64 0.5.0-13.fc39                     @fedora  34 k
 xorg-x11-drv-intel      x86_64 2.99.917-56.20210115.fc39         @fedora 2.1 M
 xorg-x11-drv-libinput   x86_64 1.4.0-1.fc39                      @fedora 102 k
 xorg-x11-drv-nouveau    x86_64 1:1.0.17-6.fc39                   @fedora 214 k
 xorg-x11-drv-openchrome x86_64 0.6.400-6.20210215git5dbad06.fc39 @fedora 294 k
 xorg-x11-drv-vesa       x86_64 2.5.0-6.fc39                      @fedora  34 k
 xorg-x11-drv-wacom      x86_64 1.2.0-2.fc39                      @fedora 1.2 M
Removing unused dependencies:
 libXvMC                 x86_64 1.0.13-3.fc39                     @fedora  45 k
 xorg-x11-drv-wacom-serial-support
                         x86_64 1.2.0-2.fc39                      @fedora  40 k

Transaction Summary
================================================================================
​Remove  14 Packages

Freed space: 8.4 M
Is this ok [y/N]:
​

Just because Xorg is no longer actively developing, doesn't mean it's dead.

That's pretty much what it means.

There needs to be a very compelling reason to support multiple targets.

No multiple targets here. Either the compositor supports DRM leasing, and VR apps can work, or it doesn't, and they can't.

"IBM execs that probably don't even know how to code would like to replace X11 with Wayland" [...]

Haha, IBM execs could hardly care less about this.

Wayland was started by one developer, who previously spent years improving Xorg, but then realized there are unfixable issues with X. (He happened to work for Red Hat at the time, that was long before RH became a wholly-owned subsidiary of IBM though, which BTW doesn't mean RH is IBM now)

The current push for finalizing the transition is also coming bottom-up from the developers doing the work, not top-down from some execs. (One of the biggest complaints seems to be that it's taking too long; less push certainly wouldn't make it shorter)

xwayland is xorg-server, but recompiled to draw to a wayland compositor instead of directly to the screen.

When I write "Xorg upstream is dead", I mean the Xorg DDX specific code, which is only used by Xorg. We obviously have to maintain and develop the common DIX code for Xwayland (and other DDXen).

P.S. birdie, are you okay? You almost sound pro-Wayland!

[mSparks]

No multiple targets here. Either the compositor supports DRM leasing, and VR apps can work, or it doesn't, and they can't.

I was referring to the 3rd parties choosing to target X11 and/or wayland on sway/weston/LabWC/Hyprland etc.

KDE On Wayland: "The Biggest Thing Needed Now Is Adoption By 3rd Party Apps"

probably the #1 reason 3rd party apps are so disinterested.
There needs to be a very compelling reason to support/adopt multiple targets. "IBM execs that probably don't even know how to code would like to replace X11 with Wayland" is not a compelling reason, neither is "FC40 users will have to install optional packages".

When I write "Xorg upstream is dead", I mean the Xorg DDX specific code, which is only used by Xorg

Considering xorg upstream uses DRM instead of DDX anyway, not sure why that matters to anyone?

[schmidtbag]

I wrote Xorg, not xserver. And those who know me know I wouldn't make a claim like that without verifying it first:

What difference does it make? The only thing that actually matters is you still depend on some of Xorg to make Xwayland work.

That's pretty much what it means.

No... it doesn't. So long as there are active users, it isn't dead. Not everything warrants frequent updates. By your logic, is grep dead? Because that only sees maybe 1 update per year (and likely no noteworthy changes), whereas Xorg still sees multiple updates per year.

[oiaohm]

Tell me you dont know what a buffer is without telling me you don't know what a buffer is.

I can think of a bigger problem using exactly the same logic., the keyboard buffer does not own any pink unicorns. Wayland is never going to be able to secure the keyboard buffer if it cant cut the hair of pink unicorns to feed the mouse process.

Because its not the keyboard buffer. They keyboard buffers under Linux are filehandles to user space.

https://www.codyhiar.com/blog/linux-keylogger-how-to-read-linux-keyboard-buffer/

When DRM GEM was made it was made independent of the file system. GEM type of buffer in Linux is a raw memory buffer.

Do note you access DRM GEM buffers "driver-specific ioctl". Basically mSparks we are not in Posix here you are not using file system operations to access this DRM GEM buffer.

Linux does have non POSIX buffers. Ideal world they should be kept for internal kernel use only. DRM GEM case is one of the cases where they get exposed raw to user space. Nvidia closed source driver still does this evil today.

You did not get the meaning of does not even own to process 0. Yes most people think PID1 is the first process. process 0 is the kernel itself what not process 0 owns excursively to the driver itself totally outside the domain of selinux/posix.

The argument for DRM GEM being implemented using driver raw memory is that going though the file system layer would add too much processing overhead for graphical work. Yet all keyboard input is going though the file system layer, all networking though file system layers..... DRI3 DMABUF is all though the file system layer and it benched faster than DRM GEM ioctl. ioctl calls are not exactly light.

There are older examples of X11 using these forms of raw memory buffers with no security what so ever back in the days of the UMS when using /dev/mem as well and that not restricted to Linux you find this stuff on Soloris HPUX ..... X11 has been decades of different security nightmares.

[billyswong]

Its like the problem with PID numbers and recycling. This is a case where the POSIX standard breaks the rule that everything is a file and now you have a stack of issues.

Offtopic: any chance we switch PID number to file handle in distant future?

[mSparks]

Offtopic: any chance we switch PID number to file handle in distant future?

cd /proc
ls

Because its not the keyboard buffer. They keyboard buffers under Linux are filehandles to user space.

https://www.codyhiar.com/blog/linux-keylogger-how-to-read-linux-keyboard-buffer/

When DRM GEM was made it was made independent of the file system. GEM type of buffer in Linux is a raw memory buffer.

Do note you access DRM GEM buffers "driver-specific ioctl". Basically mSparks we are not in Posix here you are not using file system operations to access this DRM GEM buffer.

Linux does have non POSIX buffers. Ideal world they should be kept for internal kernel use only. DRM GEM case is one of the cases where they get exposed raw to user space. Nvidia closed source driver still does this evil today.

You did not get the meaning of does not even own to process 0. Yes most people think PID1 is the first process. process 0 is the kernel itself what not process 0 owns excursively to the driver itself totally outside the domain of selinux/posix.

The argument for DRM GEM being implemented using driver raw memory is that going though the file system layer would add too much processing overhead for graphical work. Yet all keyboard input is going though the file system layer, all networking though file system layers..... DRI3 DMABUF is all though the file system layer and it benched faster than DRM GEM ioctl. ioctl calls are not exactly light.

There are older examples of X11 using these forms of raw memory buffers with no security what so ever back in the days of the UMS when using /dev/mem as well and that not restricted to Linux you find this stuff on Soloris HPUX ..... X11 has been decades of different security nightmares.

Meanwhile, in a world without pink unicorns.
On linux, Keyboard buffers are files
AAAAaaand
"GEM handles are local to a DRM file."

reference
The Linux kernel docs
https://www.kernel.org/doc/html/v4.15/gpu/drm-mm.html

Obviously, that doesn't stop you using some stupid distribution that gives permissions to that file to anything and anyone who can get a ping near your operating system.
But file permissions are still absolutely not xorgs problem.
While I can imagine you are using some stupid distribution that gives permissions to that file to anything and anyone who can get a ping near your operating system, the bad news is wayland really aint gonna help you, not least because wayland compositors are using DRM in exactly the same way as xorg-server.

[oiaohm]

Offtopic: any chance we switch PID number to file handle in distant future?

Kind of PID we now have pidfd_open that gives you file handle to perform operations on processed from PID. Doing stuff using pidfd_open you no longer have the issues. That only a recently provided feature. POSIX standard still does not have a common function for this stuff.

[oiaohm]

Meanwhile, in a world without pink unicorns.
On linux, Keyboard buffers are files
AAAAaaand
"GEM handles are local to a DRM file."

reference
The Linux kernel docs
https://www.kernel.org/doc/html/v4.15/gpu/drm-mm.html

Someone need to read.

Notice the first part of that "GEM handles" that all GEM handles and then notice "a DRM file" that 1 single file. Yes a single file for all GEM handles. This means a single set of permissions for all GEM handles.

That right you have process 11 that has it own GEM handle and Process 10 has its own GEM handle you cannot say that process 11 cannot access process 10 GEM handle without blocking process 11 from access its own GEM handle because you have exactly 1 file and exactly 1 set of permissions.

Yes mSpark would be helpful if you could read. Because the bit you just quoted is the bit that tell you that selinux and posix permissions is not going to work to isolate graphical applications from each other when using DRI2 drivers that use GEM.

Yes the GEM handle number basically gives you range in inside the single file where you graphical buffer is.

[MrCooper]

I was referring to the 3rd parties choosing to target X11 and/or wayland on sway/weston/LabWC/Hyprland etc.

VR apps just can't work without DRM leasing at this point, even with Xorg. VR apps which work with Xorg can work unmodified with Xwayland, if the Wayland compositor supports the DRM leasing protocol.

Wayland native VR apps just need specific code for the DRM leasing protocol, not specific code for each individual Wayland compositor separately. No multiple targets.

[repeat from previous post]

If you're going to just repeat arguments I've already debunked, I'm going to bow out.

Considering xorg upstream uses DRM instead of DDX anyway, [...]

That makes no sense.

DDX stands for "Device Dependent X", which refers to the code in the xserver tree which is specific to a particular X server binary such as Xorg (or Xwayland, Xvfb ...), not used by any other X server binary. There can be no functional X server without some DDX code. That's what the dead Xorg DDX code (which is almost 6 times as big as the Xwayland DDX code at this point) is.

The only thing that actually matters is you still depend on some of Xorg to make Xwayland work.

Per above, the dead Xorg DDX code is used only by Xorg, not by Xwayland.

If you're referring to the common DIX (for "Device Independent X") code used by all X servers, development of that is driven mainly by Xwayland at this point, not Xorg. So it would be less inaccurate to say "you depend on some of Xwayland to make Xorg work".

Xorg still sees multiple updates per year.

The last major release of Xorg was 21.1.0 on October 10th 2021. (There have been 3 major releases of Xwayland since) It's not clear if there will ever be another one, nobody has stepped up for it.

The last minor release of Xorg was 21.1.8 on March 29th of this year (one week after Xwayland 23.1.0). It contained two fixes, one for a CVE, which is probably why anybody bothered making a release.

The last one which actually changed any Xorg DDX code (mostly just build-time test code though, plus a minor fix for an EDID log message) was 21.1.4 on July 12th 2022.

The last one with substantial changes to Xorg DDX code (to the logind integration code) was 21.1.3 on January 2nd 2022. (Notice how 6 months passed between 21.1.3 and 21.1.4, same as between Xwayland 23.1.0 and 23.2.0)

If that's not dead, it's certainly on life support.

[mSparks]

Someone need to read.

All you have written is that this problem is an issue with selinux

https://github.com/SELinuxProject/refpolicy/issues/76

that applies equally to X11 and wayland.