STEPS TO REPRODUCE:
1. Launch the game in fullscreen mode

OBSERVED BEHAVIOUR:
The game launches without creating a window. Instead it just straight up takes over video, not allowing anything to display over it, not even when switching to another virtual desktop.

EXPECTATION:
The game should create a window, that can be minimised or tabbed out of, like any other graphical application.

ADDITIONAL NOTES:
When running on Wayland, the game doesn't even register keyboard input, which therefore goes to whatever application happens to be properly in focus. Only, you can't see said application, because VO won't let it render.
Workaround is running the game in windowed mode, in which case it properly creates a window that works like a window. This also fixes the Wayland issue.

Fastfetch:
kritomas@KRITOS-LEGION
----------------------
OS: Debian GNU/Linux forky/sid (forky) x86_64
Host: 82NW (Legion 5 15ACH6A)
Kernel: Linux 6.17.13+deb14-amd64
Uptime: 10 hours, 5 mins
Packages: 5036 (dpkg), 18 (flatpak)
Shell: bash 5.3.3
Display (eDP-2): 1920x1080 @ 1.09x in 16", 60 Hz [Built-in]
DE: KDE Plasma 6.5.4
WM: KWin (Wayland)
WM Theme: Breeze
Theme: Breeze (Dark) [Qt], Breeze-Dark [GTK2], Breeze [GTK3/4]
Icons: breeze-dark [Qt], breeze-dark [GTK2/3/4]
Font: Ubuntu (11pt) [Qt], Ubuntu (11pt) [GTK2/3/4]
Cursor: breeze (24px)
Terminal: konsole 25.4.2
CPU: AMD Ryzen 7 5800H (16) @ 4.46 GHz
GPU 1: AMD Radeon RX 6600M [Discrete]
GPU 2: AMD Radeon Vega Series / Radeon Vega Mobile Series [Integrated]
Memory: 6.90 GiB / 13.51 GiB (51%)
Swap: 430.12 MiB / 14.90 GiB (3%)
Disk (/): 97.39 GiB / 139.70 GiB (70%) - btrfs
Disk (/media/localdisk): 623.52 GiB / 776.91 GiB (80%) - btrfs
Local IP (wlp6s0): 10.0.1.37/24
Battery (L20C4PC1): 60% [AC Connected]
Locale: en_GB.UTF-8

Thanks for the report. We'll take a look. We're primarily an X11 / Xorg app, but I believe the last time we tested on Wayland their emulation stuff was working correctly (we generally test on the most-recent stable + long-term Ubuntu, which is currently still Xorg). A few questions:

- Are you using the hardware-attached keyboard? Or is it a Bluetooth or similar wireless device? (I do see it's a Legion 5 laptop).

- Are you using the open-source AMDGPU driver, or the historical DRM driver? (I see it's a Debian kernel, but it doesn't hurt to confirm).

The DRM driver was recently dropped, but not until 6.19 (newer than your 6.17). I'm not sure which driver the Vega family was using prior to that.

We certainly don't want the game to run without functional keyboard input. That's terrible.

But, in terms of whether "Window mode" is preferable as a "default" or not, it's a bit more nuanced of an issue. I'm not up-to-date with the latest of architectural changes on Linux, but I can say: We are not a regular "graphical application", like Blender or GIMP. Taking exclusive control of the display can be important for performance-sensitive cases like this; plus it's often a necessity for Variable Refresh Rate support, HDR support, or anything where the application needs direct access to display (without an intermediary graphical layer "calling the shots" and often taking scheduling priority on the driver and CPU).

Operating in a "window" can be quite limiting to a game's capabilities, although it depends on the specifics of the OS platform, driver, API implementation and so on.

Furthermore, we're moving towards "default-to-Vulkan" on all platforms, which inherently comes with our taking exclusive control of the GPU at a very low-level. The game will still support Windowed mode in Vulkan, but I doubt that will be our default.

It's also worth noting that over the last 23+ years of our publicly supporting a native Linux game, the degree of compatibility and the fluctuation of different systems (GPU drivers, kernel versions, X11 systems, various dependencies) has been quite erratic and.. challenging to adapt to. The shift to Wayland has certainly not made this any easier.

Linux can be a bit of a "moving target" for game developers. Anyway, we appreciate the bug report, and we'll see what we can do.

Alt + Enter

It is the builtin keyboard.

Pretty sure I am on AMDGPU / mesa, something like that.

Exclusive control is great and all, but it should still at least let me tab out (it won't let me do that even with a functional keyboard on an X11 session). On a related note, the game should at least register a window or something with the DE, something i can click on my panel which would bring me back into the game (or yeah just alt tab back in).

Tell you what, aren't regular fullscreen windows for exclusive control? Or at least they tend to freeze all things video when running on my integrated GPU (which also handles DE), when the app managing them also freezes. That sounds like exclusive control to me.

I am running VO on both the Xorg and Wayland systems. I can confirm the Wayland-related fullscreen and keyboard issues as they were described. The fullscreen "window" ignores the desktop environment and moves across desktops as you switch them. The keyboard input is not captured by the VO client and is sent to another background target instead. For example, if you start the client from a terminal and try to type your password, nothing will happen in the client, but when you terminate it, you will find whatever you typed in the terminal.

My workaround is to run VO in windowed mode while using KDE Plasma to set Special Window/Application Settings, where I emulate fullscreen mode. The result is perfect as far as I can tell. I add properties like "Fullscreen," "Keep above other windows," "Skip taskbar," and set them to "Apply initially."

Another Wayland-related problem is that the application on an inactive desktop becomes somewhat paused. This is a general Wayland issue not caused by the VO client itself.

Exclusive control is great and all, but it should still at least let me tab out (it won't let me do that even with a functional keyboard on an X11 session).

It's important to remember that this is likely a Wayland X11 emulation problem, not an application issue. As far as I'm aware, the game isn't doing anything wrong; it has been successfully used across a variety of X11 servers since 2002.

We will take a look at this, and try to come up with a workaround (probably detecting Wayland and using Window-mode for new runtimes), but please appreciate that this issue is probably not of our making.

The whole point of having "open standards" and applications being made standards-compliant is that issues like this should fundamentally not exist. If an X11 application has been functional for 24 years, and then abruptly doesn't work under XWayland, what does that tell you?

I'm all for having "progress" towards more advanced interfaces and evolving towards better APIs. But that shouldn't preclude the on-going functionality of existing software that remains standards-compliant.

Independent software developers do not have the resources to be frequently chasing breaking changes across platforms, and this is becoming an increasing problem (not just with Linux).

Another Wayland-related problem is that the application on an inactive desktop becomes somewhat paused. This is a general Wayland issue not caused by the VO client itself.

I mean, I suspect all of this is a "Wayland issue" and not caused by the VO client? But.. yes:

I recall running into this a couple of years ago, and it also appears to be a fundamental issue; it causes the game client to be unable to maintain clock synchronization with the game server, as the phase locked loop goes out of sync while it's paused in the background. This causes some Linux players to try "tasking-back-in" and playing the game with wildly desynched clients, which are then trying to quickly re-stabilize after they're "tasked-back-to". Synchronization is a rolling average based on network traffic, and people tend to task-out when they're in an empty sector, so there isn't much traffic to resynchronize anything.

I came up with some hacky protocol workarounds to try to detect and forcibly improving the duration of the sync issues, but it seems a bit silly that that was needed, given that it's (again) a major departure from decades of X11 application norms.

If you'd like to learn more, there's seemingly a rather intense thread on the Wayland forums, where apparently some people from Valve and other game-related devs tried to explain the issue (basically that all games react "very badly" to having their framerates suddenly forced to 1hz / 1fps, because so much of game internals are clocked on frame synchronization), and eventually got this response from one of the Wayland devs:

"I don't give a fuck what you think is normal behavior for games. You get certain guarantees with wayland. Deal with it. If clients decide to do exactly what they do on windows or X11 they won't work correctly."

So, that's.. fun? (this dev was apparently banned a couple of years later).

Basically "they won't work correctly" because someone at Wayland decided what is For The Greater Good of All Mankind. And we, the application developers, have to "figure this all out" later when users start to complain. Awesome.

This background-app problem has continued to be an issue in 2024 with other games. I'm not at all up-to-date on the current state of this, or whether Valve has reached some kind of inroads solution for Proton and other cases.

My overall point here is that we're absolutely going to do our best to mitigate issues for our players. But, developing for these systems can sometimes be "painful"; and that isn't our fault.

Urgh, yeah I know of the rather "spicy" Wayland threads. Kinda wild that everyone wants to deprecate X11, with the Wayland development like that.

Anyway, misunderstanding here:

> Exclusive control is great and all, but it should still at least let me tab out (it won't let me do that even with a functional keyboard on an X11 session).

> It's important to remember that this is likely a Wayland X11 emulation problem, not an application issue. As far as I'm aware, the game isn't doing anything wrong; it has been successfully used across a variety of X11 servers since 2002.

By X11 session I meant literally an X11 session; no Wayland in the way causing a mess. it won't let me tab out on either X11 nor Wayland. The fastfetch says Wayland, since that's what I normally use, but I did try Plasma X11 too, and it still wouldn't let me tab out.

By X11 session I meant literally an X11 session; no Wayland in the way causing a mess. it won't let me tab out on either X11 nor Wayland. The fastfetch says Wayland, since that's what I normally use, but I did try Plasma X11 too, and it still wouldn't let me tab out.

Thanks for the clarification, we'll take a look. We last tested on then-current default Ubuntu LTS (24, I think), using Xorg and probably Gnome, with the proprietary NVIDIA drivers. I don't remember if we tried tasking out with alt-tab or not. I'm not familiar with Plasma X11.

At one point in time you could run VO fullscreen in a single desktop, and then use the window manager to switch desktops and that worked properly. I don't know why that would have stopped working, but.. as the above illustrates, there are a lot of things I don't know about the fluctuations present in Linux (and sometimes in specific implementations or distributions).

My larger comment about "this is likely a Wayland X11 emulation problem" was directed more at the "no keyboard on startup" thing, which Infinitis was responding to, and the general over-arching number of problems that tend to appear under Wayland.

Incarnate, I agree with everything that has been said here. Unfortunately, Wayland will be forced upon us, and it seems to be more of an ideological battle than anything else.

Everything you need, as well as what Incarnate described in his last post and more, is entirely possible under KDE Plasma and it doesn't matter whether you're using Xorg or Wayland. You simply need to configure the application behaviour to meet your expectations. I understand that it might not be the way you want to go, but it should at least be noted here for others.

"At one point in time, you could run video output fullscreen... I don't know why that would have stopped working" — I remember that was the point in time when I started using my custom application setup in KDE.

Pausing ... it can be probably "solved" by, for instance, switching vsync off in the client. This leads to other consequences, such as increased system load, higher energy consumption, and the fans spinning up. This remains an issue for me, but I have not put much time to resolving it yet. Many people experience this problem with various games, and the forums are full of related discussions.

Pausing ... it can be probably "solved" by, for instance, switching vsync off in the client. This leads to other consequences, such as increased system load, higher energy consumption, and the fans spinning up.

The game has had a default frame-limiter for a long time, even if vsync is disabled, which should prevent excessive power usage. I think it currently defaults to 120fps, but you can set it to whatever you like.

But, I'm not sure vsync would impact the client's behaviour in the background on Wayland? This is probably something we can manually work around, because our entire app is threaded, so we can likely "detect" that a low framerate is being forced and just disable the renderer entirely.

The bummer is that all this weird specialty code takes time to develop and test (and maintain), all because of the random (and evolving) inconsistencies between platforms. It sucks a lot of energy out of what might be considered "game development".

Anyway.. we'll see what we can do, as always..