Would creating a xlib emulator be better

[lnee94]

The thing is pipewire and portals all ready exist but may be hard to use so for the things that can be done with wayland but require a shift in how a program works could be abstracted with a xlib emulator. And with the protocols that exist out of the way more focus can be put on protocols that don't exist.

[probonopd]

Hi @lnee94, basically one Wayland protocol for each xlib function (and possibly more)?

[lnee94]

Hi @lnee94, basically one Wayland protocol for each xlib function (and possibly more)?

I don't know what you ment by that, but the core point I'm making is that pipewire dbus etc exist and are standard so make a xlib emulator so that application devs have a easier time porting apps

[probonopd]

pipewire dbus etc exist

On some, but not on all systems.

A display server that can't work properly on its own is imho conceptually flawed. XOrg has no dependencies on those things, and not everyone will consider to use Wayland if that means that those dependencies are forced upon people.

[markusbkk]

pipewire dbus etc exist

On some, but not on all systems.

A display server that can't work properly on its own is imho conceptually flawed. XOrg has no dependencies on those things, and not everyone will consider to use Wayland if that means that those dependencies are forced upon people.

The problem with Xorg is exactly that it has no external dependencies for a lot of things. Things that should be achieved through other means were simply hacked into Xorg over the years (I assume mainly to give a "free lunch" to all the *nixes that weren't the then predominant ones and would've had to shim any external dependencies).

The behemoth that is XScreensaver is a prime example of that. Things that could be done externally and sanely (like tracking mouse cursor movement to wake up the system/close the screensaver. Things libinput can be used for nowadays) are done through extensions such as XQueryPointer instead.

[probonopd]

Xorg's big benefit is that it unifies how things work across all desktop environments and window managers, regardless of what is or is not installed on the system. With Wayland, "it depends". Wayland will make for a very fragmented, generally broken desktop experience when compared with the incumbent Xorg.

[markusbkk]

Xorg's big benefit is that it unifies how things work across all desktop environments and window managers, regardless of what is or is not installed on the system. With Wayland, "it depends". Wayland will make for a very fragmented, generally broken desktop experience when compared with the incumbent Xorg.

That's only half the story.

Xorg itself doesn't set any policy, so with just Xorg on its own there's none of that mythical desktop environment convergence that people like to muse about. There's ICCCM but nobody was ever required to implement all of its window hints, let alone in a consistent fashion.

Anybody who has ever browsed for X11 window managers across the board (or anybody who ever wrote their own X11 WM) will have faced the situation of one WM not handling a particular application the way every other WM did.

Heck. Even things like a simple wallpaper didn't work the same everywhere. Originally, WMs mostly drew the background image to the root window. Later, after the introduction of virtual desktops, some WMs switched to virtual root windows. Meanwhile larger desktop environments such as KDE and Gnome drew their own (set of) desktop window(s).

If a modern "X11" is the goal, I suggest somebody either implement a meta compositor with some custom IPC mechanism that makes it easy to communicate with the clients and even easier to implement traditional WMs on top of it, or push for people to use Arcan or Mir more. I'd say Mir is the closest thing we have to an "Xorg-on-Wayland", currently.

BTW: I feel the true beauty of Wayland lies in the fact that one can benefit from it even without actually utilizing it. If you tinker with GDM3, LightDM or SDDM, you'll realize that, unlike /usr/share/xsessions/, /usr/share/wayland-sessions really doesn't have any dependencies. Whereas an xsession typically launches Xorg and thus uses Xorg to display any graphical application, a wayland-session can be anything that understands DRM/KMS. In fact, that's how I currently run my Arcan Durden session inside Pop!_OS.

[markusbkk]

As for software depending on the presence of other software: How is that different/worse from what we had before? Just like certain features require things like Pipewire, X11 WMs required Xorg.

This doesn't sound like a fundamentally flawed design but simply something package managers have to deal with.

[myownfriend]

As for software depending on the presence of other software: How is that different/worse from what we had before? Just like certain features require things like Pipewire, X11 WMs required Xorg.

Exactly my thoughts. Mutter and Kwin both require Xorg in order to run an X11 session but they can run Wayland sessions "natively". They may use Pipewire, Dbus, and Portals but those aren't specific to a Wayland session anyway. All three can and are used in X11 sessions as well so they might as well be used. OBS Studio can literally drop it's XShm, XComposite, PulseAudio, and V4L2 modules and still maintain the same functionality in Wayland and X11 using Pipewire + Portals. I'm not sure if they would drop their Jack input capture as well since Jack is still slightly lower latency than Pipewire but I'm not sure if that matters for capture. If not then they could drop that, too.

No matter what, something is going to have dependencies but by having more dependency in the compositor/DE, it can simplify software. Why maintain separate methods of audio, video, and input capture and control for X11 and Wayland when you can use the same thing to support both? That would also allow X11 software to do those things in a Wayland session without first needing to make the software itself support Wayland.

[myownfriend]

Xorg's big benefit is that it unifies how things work across all desktop environments and window managers, regardless of what is or is not installed on the system.

That's exactly what Dbus, Pipewire, and Portals are trying to do but you have a problem with them because each part has it's own name. Just pretend they're one solution with different parts. Pipewire, Dbus, and Portals unify audio playback, video capture, audio capture, and input capture across display server protocols. If your software isn't a native Wayland client then just use portals and you can support those features in Wayland, X11, and XWayland without having to support each individually.

Right now I'm running Ubuntu with an X11 session in a VM on my other monitor. I have OBS open and these are my options for capture sources.

• Audio Input Capture (PulseAudio)
• Audio Output Capture (PulseAudio)
• Jack Input Client
• Screen Capture (Pipewire)
• Screen Capture (XSHM)
• Video Capture Device (V4L2)
• Window Capture (Pipewire)
• Window Capture (XComposite)

If people would adopt Dbus, Pipewire, and Portals then OBS could handle all linux capture with Pipewire which would reduce the list to this

• Audio Input Capture
• Screen Capture
• Video Capture Device
• Window Capture

On top of that, it could use Portals to support global hotkeys and it could support virtual camera functionality without requiring V4L2-loopback. I repeat: That same code would implement that functionality in X11 and Wayland. That's a lot of unification.

Also my VM doesn't have hardware acceleration so neither screen capture method is smooth but Pipewire is noticeably smoother so XSHM doesn't even provide a performance advantage.

[probonopd]

@myownfriend try to see this from the perspective of someone using a lean system and has no GLib, Gtk, doesn't want D-Bus, etc. (E.g.: GNUstep, helloDesktop, FyneDesk, etc.)

The display server must not force half of the Gnome stack on everyone.

[myownfriend]

@myownfriend try to see this from the perspective of someone using a lean system and has no GLib, Gtk, doesn't want D-Bus, etc. (E.g.: GNUstep, helloDesktop, FyneDesk, etc.) The display server must not force half of the Gnome stack on everyone.

It's good that it doesn't then.

But also do you not see how beneficial something like Portals and Pipewire are to applications like OBS? Do you really think it's better for OBS to support two different protocols for global hotkeys, screen capture, window capture for Wayland and X11?

[probonopd]

But also do you not see how beneficial something like Portals and Pipewire are to applications like OBS?

No. In fact, I think they are harmful. Because they make the OBS developers believe these things are "solved" now, instead of pushing for a proper pure-Wayland solution without all the additional Red Hat baggage.

Do you really think it's better for OBS to support two different protocols for global hotkeys, screen capture, window capture for Wayland and X11?

The best solution, of course, would be to make Wayland use the same protocols as X11. If this is not possible/not wanted, the second best solution is to make Wayland use protocols conceptually very close to the ones in X11. The latter is the approach advocated by this repository.

[myownfriend]

No. In fact, I think they are harmful. Because they make the OBS developers believe these things are "solved" now, instead of pushing for a proper pure-Wayland solution without all the additional Red Hat baggage.

There's no reason whatsoever that a pure-Wayland solution is proper when you can de-couple those things from the display server protocol and get the benefit of a shared method of input, window, and screen capture in both protocols

It is solved just not to your liking. If Portals had a dependency of Qt instead of Glib and if Wim Taymans wasn't payed by Redhat then you wouldn't have an issue with these things.

The best solution, of course, would be to make Wayland use the same protocols as X11.

That would be a horrible solution. Giving everything an open door policy and having global hotkeys work identically to a keylogger will always be dumb.

If this is not possible/not wanted, the second best solution is to make Wayland use protocols conceptually very close to the ones in X11. The latter is the approach advocated by this repository.

It's baffling to me how incapable you are of imagining anything working differently or better than X11. Using Portals (or at least something outside of the display server protocol) is literally providing applications like OBS a way to remove code while retaining compatibility with X11 and Wayland and it's allowing X11 software to retain those features when run in a Wayland session. In another thread I even explained to you that OBS is able to screen capture with noticeably higher performance using Portals in an X11 session than it can using XSHM or XComposite. It's nuts that it has all of these benefits but you still think it should work the way X11 does it.

[probonopd]

@myownfriend well I guess if you like the current state of Wayland then you have no need for this repository. This repository is for the rest of us who are not satisfied with what Wayland currently has to offer.

[myownfriend]

@myownfriend well I guess if you like the current state of Wayland then you have no need for this repository. This repository is for the rest of us who are not satisfied with what Wayland currently has to offer.

There's a lot that Wayland can do to improve but this repository isn't going to be the source of any of that improvement. If you're not familiar with the protocols that exists then you can't create proposals for protocols that don't break what's there.

[probonopd]

Always happy to learn. Best have a look at the protocols proposed in this repository and then make specific comments on why you think they are not needed because existing protocols can already do the same thing.

[myownfriend]

Always happy to learn. Best have a look at the protocols proposed in this repository and then make specific comments on why you think they are not needed because existing protocols can already do the same thing.

Your screen-video-capture-v1 protocol says...

This is a proposed Wayland protocol to simplify porting existing applications from X11, Windows, macOS to Wayland while keeping the existing application logic as much as possible -

...but you already said you're completely unfamiliar with how Windows or macOS does video capture. That means you aren't even aware if they're similar to each other.

Also it's a video capture protocol and you defined how the application should sync video with audio. Didn't you say that the display server protocol shouldn't define how an application should work? Wayland has nothing to do with audio and the whole point of the protocol is just to try to define how one client can get access to another client's buffer. Don't define what the application does with it's captured audio?

Also did you know that a compositor isn't required to implement an extension? Even if this was merged into the official repo (it won't be), there's no guarantee that every DE would support it so how does this have a benefit over Portals/Pipewire? From the perspective or porting an application, what difference does it make if it's using a Wayland API call or Portal/Pipewire API call? At least with Portal/Pipewire the application can run under X11 or Wayland use the same code and implementations already exist.

[probonopd]

you already said you're completely unfamiliar with how Windows or macOS does video capture

I am familiar with the desired user experience.

Also it's a video capture protocol and you defined how the application should sync video with audio.

Of course there must be a way for the application to sync audio and video, don't you think? The display server has no business in audio but it must provide a way for the screen capturing application to sync with the audio, no matter how it acquires it.

Also did you know that a compositor isn't required to implement an extension?

Yes.

Even if this was merged into the official repo (it won't be)

You are proving my point why we need this repository outside of the upstream echo chamber.

there's no guarantee that every DE would support it so how does this have a benefit over Portals/Pipewire

There's no guarantee that every system has Portals/Pipewire installed, so it's on par in that regard. The advantage is that usin this protocol

• You are not forced to install Portals/Pipewire (and their undesired dependencies)
• You are not forced to have Portals/Pipewire user experience (nag screens)

At least with Portal/Pipewire the application can run under X11 or Wayland use the same code and implementations already exist.

Under X11 my applications and desktop environments have no need for and don't support Portals/Pipewire, and I don't want to introduce that baggage just so that I can use Wayland.

If you'd like to have a more structured conversation, then please open individual tickets for each protocol and each issue you have with them.

[markusbkk]

@myownfriend try to see this from the perspective of someone using a lean system and has no GLib, Gtk, doesn't want D-Bus, etc. (E.g.: GNUstep, helloDesktop, FyneDesk, etc.)

The display server must not force half of the Gnome stack on everyone.

You don't need D-Bus for a Wayland compositor. AFAIK, ravynOS' WindowServer only uses Mach IPC.

[markusbkk]

RE screen-video-capture-v1

I'm somewhat naive on the matter myself but isn't this already solved through GStreamer's waylandsink?

[probonopd]

You don't need D-Bus for a Wayland compositor. AFAIK, ravynOS' WindowServer only uses Mach IPC.

Exactly. But things like Portals and Pipewire were deeply interwoven with D-Bus last time I checked. Hence we are proposing protocols that can do without them.

[probonopd]

RE screen-video-capture-v1

I'm somewhat naive on the matter myself but isn't this already solved through GStreamer's waylandsink?

What if you want to use e.g., ffmpeg rather than GStreamer?

[markusbkk]

RE screen-video-capture-v1 I'm somewhat naive on the matter myself but isn't this already solved through GStreamer's waylandsink?

What if you want to use e.g., ffmpeg rather than GStreamer?

They are not even the same layer AFAIK. And GStreamer can use codecs provided by ffmpeg.

[markusbkk]

You don't need D-Bus for a Wayland compositor. AFAIK, ravynOS' WindowServer only uses Mach IPC.

Exactly. But things like Portals and Pipewire were deeply interwoven with D-Bus last time I checked. Hence we are proposing protocols that can do without them.

But without Pipewire you'd end up with a single point of failure, no? If Pipewire crashes, my video or audio capture may get interrupted. But if your internal thing crashes, it'll bring down the entire compositor.

[probonopd]

They are not even the same layer AFAIK. And GStreamer can use codecs provided by ffmpeg.

Am looking for a solution which doesn't require GStreamer (my use case is that I want to build a GLib-free system.)

[markusbkk]

Anyhow. I think this wlmaker project you forked looks really interesting and could very well serve as the basis of a reference compositor for what you want to do.

I still think the best way to go about this would be to implement a meta compositor. If you want to attract people used to the X11 way, why not actually create a framework to ensure the X11 way?

Have a small but capable Wayland compositor that establishes its own IPC protocol, write a simple tutorial WM that uses this compositor like an X11 WM would use Xorg, profit.

If you build it, they'll come.

[probonopd]

Hmm. Interesting thought. Maybe this is a direction I might take helloDesktop into.

[markusbkk]

Hmm. Interesting thought. Maybe this is a direction I might take helloDesktop into.

You could have your cake and eat it too that way. 😸 It would basically be X12.

Mir went a similar direction.

I think that's the secret beauty of Wayland. It doesn't actually push any particular stack requirements on people. As I said before: You're not even required to use Wayland to benefit from Wayland.