video: Prefer Wayland over X11 #4306
Conversation
|
It looks like there is no way to programmatically set the icon of a Wayland window; I found no mentions of an icon API in the wayland-protocols repository. Someone else will have to figure out a Wayland protocol extension for that API. |
This should probably just be the display size (which the Wayland backend does report, afaik). Is the problem multi-monitor?
Just pass these requests to GetDisplayBounds and add a FIXME for needing a protocol for now. I suspect this will also be a good candidate for libdecoration to supply, since we basically need to know what Gnome, etc specific reservations are being taken.
We can't do these? Really?!
Fwiw, I don't think these work on X11 at the moment if you have an OpenGL window, which is about the same as saying I don't think these work on X11.
My current desire is to remove the shape API in 2.1. Just leave it unimplemented for Wayland. |
Yeah, the only missing part here is providing x/y geometry to the VideoDisplay. As far as w/h are concerned this technically works already.
SDL_video.c does this for us already, so nothing to worry about here!
For RaiseWindow I thought I saw some murmurs about there being a protocol for process-local raising or some such thing, but yeah, I guess it's along the same lines as SetWindowInputFocus where that's Not Okay(TM), but like... yeah, come on, man. HideWindow I think we just need to set the opaque region to empty, or something like that? I know this is doable somehow considering we can start with a hidden window and show it later (as FNA does), but I wasn't sure what the recommended technique was here (Wayland example code is frustratingly sparse).
Fair enough - I happened to come across the wlr protocol while looking at text input, but I have zero use cases for this so I wouldn't even know where to start with it. Maybe this will be useful for idTech-style brightness settings or something, I'm 100% clueless here.
Got it, will cut that from the list! |
|
Took care of GetDisplayBounds and SetWindowModalFor, and fixed up a couple other things while I was at it: #4309 We uh, need to talk about HideWindow though. I found this in the zxdg-shell spec: You probably read that like I did and went "wait, to hide it we... destroy it?" And yes, the stable spec basically says the same thing: Oh, okay, so it's just named kind of weird, it's an unmap call. But this is a problem because we create these objects in CreateWindow, and pretty much depend on its existence throughout waylandwindow.c (and twice in waylandevents.c). This means we pretty much have to fold all that Create work into ShowWindow, then fold all the Destroy work into HideWindow, then fix up the whole driver to consider the idea that yes, we have the protocol, but not the window object, at least for that moment. Much like GammaRamp I don't have any active use case for this other than "I want to keep the window hidden until we've loaded and are ready to draw," so this may be a refactor for someone else to deal with. |
|
Does destroying the window object cause the EGL surface to be lost? |
Not that I could tell, I believe the wl_surface and EGL surface are still valid, they just won't have an xdg-toplevel mapped to the compositor. I would definitely test this idea though. |
|
Managed to figure out GetDisplayDPI as well, another really easy one that I should have seen the first time around. |
|
The Wayland gamma protocol depends on the gamma ramp size which is likely to be not equal to 256. X11's XVidMode gamma functions (which the X11 backend does not use) also uses different gamma ramp sizes depending on the display. Same goes for the XRandR gamma API. And the KMSDRM backend optionally can support gamma ramp sizes higher than 256 but uses the legacy gamma setting functions so it is hard-limited to 256. SDL really needs a internal function to convert between gamma ramps of different sizes. Edit: Cocoa backend converts the gamma ramp values to floats before passing them CGSetDisplayTransferByTable which is documented to internally interpolate the gamma ramp values to match the display hardware. That looks useful for a gamma ramp size convert function on SDL's side. |
|
Figured out HideWindow in #4319. The rearranging of things was easier than I expected once I realized why the protocol was blowing up in my face when calling ShowWindow a second time. |
|
The last feature that doesn't require a new protocol has been merged... I'm still a bit antsy about the bug found in #4319 but I'm hoping it's just that we're doing something new and not wrong, seeing that similar toolkits were doing similar techniques. At this point unless we want to start pitching new protocols this is as feature-complete as it's going to get, we're now in the bugfixing stage while the libdecor developers do their thing. |
|
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/blob/main/staging/xdg-activation/xdg-activation-v1.xml |
|
Added to the OP. I assume this protocol doesn't set input focus though, right? I'm guessing SetWindowInputFocus will probably get thrown out with stuff like SetWindowPosition, but I wasn't 100% sure if both Raise and SetInputFocus were being looked at. |
|
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/41 |
|
Looks like it does what we want, but it also looks like it'll be a while before that's finalized. Will add it to the list just in case! |
|
Just realized that "staging" took the place of "unstable" for Wayland protocols, and 1.21 includes the staged activation protocol. Implementations are early though, so if someone has early access to a working implementation you're probably the only one that can write and test this right now. Would be cool to have for 2.0.16 though! |
They still have 19 days. :) |
flibitijibibo
force-pushed
the
only-took-9-years
branch
from
106561e to
6a17bf0
Compare
flibitijibibo
force-pushed
the
only-took-9-years
branch
from
6a17bf0 to
e501122
Compare
|
Quick update on this since 2.0.16 is still in the works: The KDE components for xdg-activation have been merged upstream, and the wlroots patch has been reviewed as of today and |
|
Opened #4413 in the hopes that someone with the right environment can test it - it's a very small patch compared to some of the other Wayland features but it requires the very latest KWin or wlroots to run (mutter's patch is still under review). |
Please don't. This protocol is privileged and shouldn't be used by regular clients. The main use-case is the "night light" feature. |
Phew, that's what I figured - removing this from the list! |
|
RaiseWindow support is in, thanks to the various desktop developers for helping us out! At this point we now have implementations for every function where a protocol exists - any more features will require creating or contributing to new protocols. There is still the concern of #4360 not working, but we have our own built-in IME support working with the caveat that the text input rectangle won't work in windowed mode (it's fine in fullscreen mode thanks to convenient window placement). This is about as good as it's going to get for 2.0.16, meaning we can focus on removing deprecated stuff and fixing bugs for the whole 2.0.18 cycle while libdecor support continues to develop. |
flibitijibibo
force-pushed
the
only-took-9-years
branch
from
e501122 to
ab9acd6
Compare
|
I've been doing a lot of testing this week with games big and small, and so far everything has held up very well - for Vulkan in particular I would go as far as saying this driver is now production ready on desktops with server decorations! You can see some samples here and here. OpenGL is still annoying because of some holes in EGL and that loathsome infinite wait in SwapBuffers. I decided to try and pitch some extensions to fix these problems: https://gitlab.freedesktop.org/mesa/mesa/-/issues/4932 https://gitlab.freedesktop.org/mesa/mesa/-/issues/4933 Once these are solved I'd put the "production ready" stamp on OpenGL as well. |
|
Another update... I'm helping out with a new Wayland protocol designed by Joshua Ashton and implemented in wlroots by Simon Ser to better support suspended surfaces: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/99 I don't expect SDL to have any new code for this, it will just make vkAcquireNextImageKHR and eglSwapBuffers work in a way that prevents it from deadlocking forever. A timeout is still a good idea but this will be much better for supporting surfaces that are obscured. |
|
NVIDIA's 470 driver beta is now available: https://www.nvidia.com/download/driverResults.aspx/176525/en-us I ran it on my NV lab box and can confirm that it actually works very well already. While this opens the door for X applications working on Wayland NV, it does confirm my worries that a ton of people will be running SDL applications via Xwayland really really soon, which for first-person games is extremely bad news because the mousewarp emulation is, as you might expect, really crappy and stuttery (and I don't blame desktop developers for not caring about it). At least for my catalog, making our way to switching the default is now officially urgent rather than just maybe urgent. In addition to finally getting to try Xwayland for the first time, NVIDIA testers are encouraged to try SDL_VIDEODRIVER=wayland to make sure that we're ready for NVIDIA's 470 release when using native Wayland applications. |
Sway does not warp the cursor to the application surface at all when it is resized and relative mode is active, which allows mouse to click into the background and cause the cursor to be able to move again should the cursor reappear. This is a problem for applications like DosBox which do resize their windows. |
This is a compositor bug: swaywm/sway#6070 |
flibitijibibo
force-pushed
the
only-took-9-years
branch
from
3b98897 to
7ada534
Compare
flibitijibibo
changed the title
I see it happening in LabWC 0.4.0 too. |
|
It seems like even with EGL_EXT_present_opaque there's still something wrong with alpha and OpenGL. The short version: dhewm3 (sometimes) blends to the default framebuffer with Now the weird thing is, that this also happens on Wayland even if the context should have 8 alpha bits ( Do you have any idea if this is expected behavior (that would be bad)? If not, who is to blame - SDL or Mesa or Gnome's wayland implementation or who else? |
|
I would expect this issue to be in Mesa, it should be picking an XRGB8 surface so those bits should exist somewhere... |
|
Is the alpha chan supposed to contain valid bits that are used for alpha blending if it's indeed XRGB instead of ARGB? |
|
It should - as the name suggests, we just want to present opaque, we still want the surface to be a 32-bit image with valid information in all channels. |
|
I'm pretty sure that there's something wrong on Mesas side. I've opened a bug report: https://gitlab.freedesktop.org/mesa/mesa/-/issues/5886 |
|
On the subject of external reports, I've tried to report everything we've found throughout development to close all the
The rest have already been mentioned above (i.e. dhewm3's present_opaque report, event queue overflow proposal) or they already got back to us and either fixed the problem or proved that it was really us. This leaves us with exactly two issues that aren't mentioned in the OP:
Unless you're Valve, NVIDIA, or a maintainer of the projects mentioned above, all eyes should be on the second issue. The sooner that's fixed, the sooner we can say "okay, this is done and locked in, desktops/drivers can look at the latest revision and know that it will likely be what ships as the default in the very near future." |
|
A commit has been pushed that hopefully fixes the second issue, but we're still waiting on feedback... either way it was agreed that we should be able to iron out the final issues for 2.0.22, so here we go! |
|
Do you know if EGL_EXT_present_opaque at least works with other games (than Doom3) that need it, like Portal2? |
|
Yes, my tests included Portal 2, Left 4 Dead 2, Unity, FNA, and a few custom engines from my catalog of games. |
|
Ok, good to know, so Doom3 really is special.. I can work around the issue in dhewm3: https://github.com/dhewm/dhewm3/blob/test-alpha/neo/renderer/tr_backend.cpp#L532-L594 I hope Mesa eventually fixes the issue; the way it's implemented now, SDL probably could've done the same without an extension (using a visual without alpha while pretending in I even wonder if SDL could implement a workaround like I do in dhewm3 (blend a window-sized quad with color (0, 0, 0, 1) before |
|
Yeah, the faux-backbuffer idea is something I threw around in FNA3D for a bit but it's not easy to wedge into call streams unless you control the whole stream (i.e. people like to glBindFramebuffer(0) a LOT). I did try and fuss with the attrib flags as well and came up with nothing... you can trick the application most of the time, but like Doom3 there's always somebody who really expects to get what they asked for. Pretty much the only sure fix was to address it one layer below us (either in the EGL implementation or the compositors, and since Vulkan already has a composite alpha flag EGL seemed like the right idea). |
Ok, that's a problem of course
Yeah, applications that actually need the alpha chan are screwed with that approach, but so far, so they are with the EGL extension. Also I wonder if my approach of making the alpha channel opaque at the end of the frame (with blending or whatever) can break applications, in case anyone reads from the front buffer in the next frame? No idea if that's a thing. So we'll have to hope that Mesa fixes it eventually (and that they won't pretend it works like expected) |
|
I would check the Mesa commit that introduces the extension; it should work similar to the Vulkan WSI implementation which explicitly has this as a feature, so if anything is different there should be a direct reference to show how it's supposed to be done. If there's a Vulkan renderer for Doom 3 somewhere I would check that as well. |
|
NVIDIA 510.47.03 fixes native Wayland Vulkan support. Interestingly, NV Vulkan has the same opacity issues that EGL does. EGL I get since the extension isn't supported yet, but I'm surprised that Vulkan doesn't conform to VkCompositeAlphaFlagsKHR. |
For some reason Wayland thought it would be clever to be the only windowing system that (non-optionally) uses the alpha chan of the window's default OpenGL framebuffer for window transparency. This always caused glitches with dhewm3, as Doom3 uses that alpha-chan for blending tricks (with GL_DST_ALPHA) - especially visible in the main menu or when the flashlight is on. So far the workaround has been r_waylandcompat which requests an OpenGL context/visual without alpha chan (0 alpha bits), but that also causes glitches. There's an EGL extension that's supposed to fix this issue (EGL_EXT_present_opaque), and newer SDL2 versions use it (when using the wayland backend) - but unfortunately the Mesa implementation is broken (seems to provide a visual without alpha channel even if one was requested), see https://gitlab.freedesktop.org/mesa/mesa/-/issues/5886 and libsdl-org/SDL#4306 (comment) for the corresponding SDL2 discussion To work around this issue, dhewm3 now disables the use of that EGL extension and (optionally) makes sure the alpha channel is opaque at the end of the frame. This behavior is controlled with the r_fillWindowAlphaChan CVar: If it's 1, this always is done (regardless if wayland is used or not), if it's 0 it's not done (even on wayland), if it's -1 (the default) it's only done if the SDL "video driver" is wayland (this could be easily enhanced later in case other windowing systems have the same issue) r_waylandcompat has been removed (it never worked properly anyway), so now the window always has an alpha chan
That was https://gitlab.freedesktop.org/mesa/mesa/-/commit/9aee7855d2ddf47169270d5d1e3e92ff6e5f65c2 and https://gitlab.freedesktop.org/mesa/mesa/-/commit/9aee7855d2ddf47169270d5d1e3e92ff6e5f65c2#b91f29c819033a507b2cac556bea4f5aecd8893d_178_178 indeed looks like they just use 8 alpha bits internally, if I interpret that code correctly.
I wasn't able to find the code for that Vulkan extension in Mesa - the bit it set somewhere, but I didn't see it being read to act on it (I didn't spend terribly much time on it though).
The only one I'm aware of is based on Doom3BFG which has a much more modern (OpenGL 3) renderer that IIRC uses FBOs internally so it shouldn't have this problem. I committed a workaround to dhewm3 (that fills the alpha chan at the end of each frame) to make sure it continues working with SDL2 versions that use wayland by default: dhewm/dhewm3@699779e |
For some reason Wayland thought it would be clever to be the only windowing system that (non-optionally) uses the alpha chan of the window's default OpenGL framebuffer for window transparency. This always caused glitches with dhewm3, as Doom3 uses that alpha-chan for blending tricks (with GL_DST_ALPHA) - especially visible in the main menu or when the flashlight is on. So far the workaround has been r_waylandcompat which requests an OpenGL context/visual without alpha chan (0 alpha bits), but that also causes glitches. There's an EGL extension that's supposed to fix this issue (EGL_EXT_present_opaque), and newer SDL2 versions use it (when using the wayland backend) - but unfortunately the Mesa implementation is broken (seems to provide a visual without alpha channel even if one was requested), see https://gitlab.freedesktop.org/mesa/mesa/-/issues/5886 and libsdl-org/SDL#4306 (comment) for the corresponding SDL2 discussion To work around this issue, dhewm3 now disables the use of that EGL extension and (optionally) makes sure the alpha channel is opaque at the end of the frame. This behavior is controlled with the r_fillWindowAlphaChan CVar: If it's 1, this always is done (regardless if wayland is used or not), if it's 0 it's not done (even on wayland), if it's -1 (the default) it's only done if the SDL "video driver" is wayland (this could be easily enhanced later in case other windowing systems have the same issue) r_waylandcompat has been removed (it never worked properly anyway), so now the window always has an alpha chan
This is a
draftpatch that will (at last) prioritize the Wayland video driver over X11. This is here purely for internal testing only and is NOT meant for wider community testing; to test SDL Wayland support you should setSDL_VIDEODRIVER=waylandinstead.Click here for the SDL Wayland bug tracker.
The Big List of Annoying Things That Aren't SDL's Fault:
The Big List of EGL Stuff That Might Be a Problem:
This Big List of Things in X11 That Wayland Might Also Want but It's Not a Huge Deal:
Known Issues:
Fixes #2710. Fixes #4988.