Wine's Wayland Driver Is Becoming Mature, May Aim For Upstreaming Early Next Year

[treba]

Same thing i asked TemplarGR: how do you know I'm not?

I didn't say that you don't, but just that I strongly hope you do if you allow yourself comments like that.

Also, not sure why anyone has to maintain Xorg in this discussion when it's already working better than Wayland.

Ok, I take it back. If I have to explain to you why software like Xorg needs maintenance, then nobody should trust you with that job anyway.

[dragon321]

That looks to be Yes.

V1tol You are confusing different projects. There aretwo projects that provides Wayland driver for Wine - independent from varmd on GitHub and backed by Collabora developed mainly by Alexandros Frantzis. This article is about latter. As far I know it supported OpenGL from beginning and it is supposed to be as much complete (like X11 driver) as possible and merged into Wine. varmd project is focused on games and doesn't support OpenGL or most GDI applications (so most desktop Windows applications won't work). As far I know there isn't and won't be any work to support it as developer is aware of Alexandros project and knows there is no sense of duplicating effort, especially due to fact that Alexandros has Collabora support.

No one is forcing you to use it. You are not developing WINE, so it is not your burden. Wayland is the future. If you don't like it, you could always switch to BSD, or Windows.

BSD is not really "safe" in that regard as well. BSD developers are not X11 fanboys and they are well aware that sooner or later Wayland will replace X11 so they need to support it. FreeBSD supports Wayland just fine. Well, Windows in some regard as well because Wayland is used for GUI in WSL. Perhaps macOS is the choice? Of course if you are not against Quartz Compositor that is more similar to Wayland compositor than to X11 WM.

Topic: Finally some news. I was worried that development stalled. Good to know it's still going and maybe will be merged in near future.

[oiaohm]

Wait a minute, this doesn't seem right (as I have so easily conceded in one of my previous posts).

You need a Wayland protocol for screen capture (or something similar, like "adjunct" Wayland protocol, whatever you want to call it).

If you allow every Wayland compositor to invent its own protocol for screen capturing, you are going to create a huge mess. Screen capturing is a commonly used functionality. It should have been specified, either as a part of Wayland, or in an adjunct suite of protocols, specified (ideally) by Wayland developers. Without a specified screen capturing protocol, the functionality of Wayland is incomplete.

Ditto, the same question for session locking: does the same kind of problem arise for session locking?

There is a defined protocol for screen capture for application to use that not wayland protocol or X11 protocol yes neutral to X11 or Wayland.

https://flatpak.github.io/xdg-desktop-portal/

Do note everything specified in xdg-desktop-portal is use-able under X11 as well as Wayland as long as the xdg-desktop-portal support bit is installed. Since globalshort cuts, screencapture and so on is defined under xdg-desktopportal using a dbus connection there is no need for these to be in the Wayland protocol and go over the wayland protocol connection.

This is more a case why should wayland protocol duplicate screencapture. flatpak was needing screencapture interface for sandboxed applications. Yes sandbox could be nested X11 inside X11 as well.

Lot of people have this problem thinking wayland protocol has to be incomplete because X feature is missing without thinking if it makes sense for X feature to be in Wayland protocol. Screencapture is one of those cases putting in Wayland protocol would just result in having to duplicate the functionality that has to exist in xdg-desktop-portal for heavily sandboxed applications on X11 to work somewhere near right. Sandbox applications on wayland are going to need xdg-desktop-portal as well.


Remember Wayland compositors and protocol allows for turtles all the way down.
Yes weston compositor can run a weston compositor inside then another weason compositor can run inside and so on.
https://en.wikipedia.org/wiki/Turtles_all_the_way_down infinite regress. Wayland protocol support infinite regression.

Not all items are suitable in a protocol where infinite regression exists and is classed as correct function. Screencapture, globalkeyshortcut and quite a few other little items don't suit this infinite regression existence.

Dbus is not infinite regression. Individual item can claim a dbus service and that is it. So anything desktop that infinite regression would be a bad thing is better off in the xdg-desktop-portal in most cases.

Session locking most likely does not own in Wayland protocol at all. Something that most likely should fall under a login manager of some form that directly working with the DRM subsystem and input subsystem. Windows login manager is split from shell under windows and its how the SAK under windows works is that it wakes up the login manager and takes the screen and input away from the shell.

Screencapture something most people don't pay attention to how it done. Today screencapture is not done by the CPU in most cases but is mostly done by the GPU. so windows you don't want screen captured you most likely want to use protected path stuff in GPU to say this buffer cannot be captured replace with blackbox.

[oiaohm]

If there was a protocol for screen capture that can be made INDEPENDENT of both X11 and Wayland, then I would agree with you.
What you have described seems to be a screen-capture protocol dependant on X11. But, the point of Wayland is to get rid of X11. So, your argument is not valid.

https://flatpak.github.io/xdg-desktop-portal/
The xdg-desktop-portal is dependent on dbus. Not X11 itself. Base to the pipewire implementations of this is dmabuf usage. This is interfacing with the GPU bipassing X11 or the wayland compositor. Information from the compositor or x11 server to bit implementing this interface is need for capturing individual windows.

OK, I agree that session locking does not need to strictly be a part of Wayland protocol. However, the session locking protocol must be implemented by a Wayland compositor, so such a protocol should exist (the compositor has to either hand over the display framebuffer to the login manager, or the compositor should display the login manager as a fullscreen application). The Wayland project team should have, at least, named the preferred protocol. If they didn't name it, then they should have specified it.

This is not the case. Think when you do a control+alt+f1 to change to terminal from X11 you are not using the X11 protocol here. Session locking does not need to be done in either X11 or Wayland protocols all that required for session locking is a TTY change and the keys to change out of the locked screen taken away until the screen is correctly unlocked.

Secure screen locking you are not going to depend on the wayland compositor or the X11 server. Wayland compositors are already implemented that you can run them on different TTYs. Remember windows shell that does the same thing as a Wayland compositor does not implement screen locking.

If the screen locker is not implemented by the Wayland compositor the only feature the wayland compositor needs is the means to basically change TTY on local usage.

Support for screen locker comes important not for wayland protocol but for Wayland compositors doing remote desktops.

https://gitlab.freedesktop.org/wayland/wayland-protocols/-/blob/main/staging/ext-session-lock/ext-session-lock-v1.xml

Yes there is a staging part of the wayland protocol that allows a wayland application to be a session lock to wayland compositor. But this would never been a secure attention key (SAK) or secure attention sequence (SAS) class screen locker.

[HellToupee]

If there was a protocol for screen capture that can be made INDEPENDENT of both X11 and Wayland, then I would agree with you.
What you have described seems to be a screen-capture protocol dependant on X11. But, the point of Wayland is to get rid of X11. So, your argument is not valid.

Ehh? He described the opposite X11 apps need the protocol to function sandboxed, in no way does that make the protocol dependant on X11, the point of wayland is not to try and do everything

[oiaohm]

Assume that a Wayland compositor is running a remote desktop session. Now you can't use an X11 protocol at all, because you can't easily connect to the compositor via a separate protocol. The compositor is on the client machine, and the screen-capturing application might be on the server machine.

Except that assume cannot work with the wayland protocol. Wayland protocol is strictly local protocol. So a compositor of some form has to be where application is running.

waypipe is still a compositor. Application attempts to screen capture with wayland it only going to screen capture what been rendered where it is.

Remote desktop with wayland would be like Weston-RDP where it wayland protocol from local application to Weston-RDP then RDP over network to user. Or like waypipe where the protocol is being compressed and modified lots to make it network effective.

Without screen-capturing being a part of Wayland, the screen-capturing applicaton must ask the user about the IP address of the Wayland compositor, the port, the password to connect, and it will not work at all if the Wayland compositor is behind a NAT or a firewall (so, screen-capturing cannot work in 99% of the cases).

You presumed it could work at all. Wayland Protocol being designed as a "local protocol" blocks using "Wayland protocol" for lots of remote things almost completely. Wayland protocol is going to be transformed locally into something else before being sent over network. Waypipe works for single applications due to special handling.

Something you missed is ssh connection can contain more than 1 socket. being transferred. Using socat it is possible to offer dbus over ssh at the same time as waypipe or weston-rdp.

Even over dbus over ssh due to dma-buf usage by the screen-capture this is not going to work well over network.

Xfcemint you had a basic mistake. There is a rule to wayland design.
The machine running wayland application must also have wayland compositor of some form running on same machine for the wayland application to have any wayland protocol stuff. This is because wayland protocol is "local protocol".

In the remote desktop case, you can't rely on ctrl-alt-F1, ctrl-alt-del, or anything similar.

This is also not true for lots of cases. RDP and VNC remote desktop clients you can remotely type ctrl-alt-f1 or ctrl-alt-del. Think virtual machines as well. These are not absolute limitations.

xfcemint this is why lets keep on adding features like what was in X11 to wayland protocol makes absolutely no sense at times. X11 protocol includes over network as part of it design. Wayland protocol by design is intentionally not over network.

Part of wayland design is that network and local are two different things.

Think about it lbx11 the client library x11 applications use have to include tcp/ip networking functions so that client applications can talk to remote X11 servers. Wayland protocol intentionally does not have this functionality removes applications from having to have tcp/ip stacks and other things.

[chuckula]

That's not true. I have a 75 Hz display and Chromium keeps up just fine on Wayland.

75Hz! Watch out!

1. I'm talking about actually high refresh rates. Like 144 Hz, which frankly isn't even that much anymore. 75Hz isn't a high refresh rate.
2. Given that you think 75 Hz is a "high refresh rate" something tells me you don't even know how to run Chromium in Wayland. Hint: The fact that your Ubuntu install says "wayland" on it doesn't mean Chromium is running in Wayland and unless you can quote me the proper Ozone command line flags, you aren't actually running it in Wayland, just X-windows in a Wayland session.
3. Go run the UFO Test and show me your "75 Hz" with an overlay showing you are actually running Chromium in Wayland via the command line flags shown above.
4. 5 seconds of Googling will show plenty of people who actually know what all this stuff is agree with me.

[royce]

I'm curious what's missing for you. I'm running Firefox on Wayland without issues for over a year. And I just checked, when I start Chromium, it also runs on Wayland.

Firefox has really shoddy surface handling, so popups, tooltips and the like are constantly breaking in different ways, and it's especially bad on mixed dpi setups.

[Vistaus]

75Hz! Watch out!

1. I'm talking about actually high refresh rates. Like 144 Hz, which frankly isn't even that much anymore. 75Hz isn't a high refresh rate.

No, you were talking about refresh rates higher than 60 Hz. 75 Hz *is* higher than 60 Hz.

I quote:
“It gets all kinds of glitches on high refresh rate monitors because it can't keep up with screen refresh rates of > 60Hz.”

[Weasel]

Ok, I take it back. If I have to explain to you why software like Xorg needs maintenance, then nobody should trust you with that job anyway.

Pretty sure you have no idea what you're talking about and try to appear smart.

You're probably going to wave the magic wand for smartasses with zero clue about programming called "Security exploits" or vulnerabilities. That's all you ever think about.

Seems Xorg is magic since it still gets fixes for them without anyone "maintaining" it (according to you)