A Call To Move Games Outside Of Linux Desktop Environments, Own Wayland/KMS Setup

[zanny]

How about instead of this KDE developers stop being lazy and write a proper desktop drawing handler that doesn't interfere with games.

Kwin already has everything you can get on Xorg and Wayland today by doing fullscreen compositor bypassing. This is about going beyond that.

Topically, if there is a way to intelligently only stop Kwin and running Wayland apps from trying to draw at all but still run in the user session so they can operate fine on separate VTs (albeit I'm still wondering how OBS is recording a different VT unless its reading from a driver buffer somewhere) then that VT could be spunup with some shim library that binds alt-tab and the meta key to VT switching back to the main desktop, and Kwin can intelligently recognize that VT and generate a dummy active window entry to switch back to it.

Thinking about it more, VTs are basically kernel display tabs. Having games run on their own makes a lot of sense in most use cases, as long as the UX of switching them becomes as intuitive of alt-tabbing today.

Wonder when we are going to get a phone OS built around that, each app in its own VT with app switching switching VTs. Sounds efficient if the wrappers are all shared.

[ruthan]

Its bad, very bad idea, lets do it like Windows till XP, its working 12 years. Its like run game in Dos mode in Windows - Dos is also without multitasking.. Just fix the bugs and improve whole graphics pipeline, if Wayland isnt solution, Linux GUI is still at the start of real maturity.

[liam]

Fullscreen doesn't mean that window management is irrelevant, at all. I still want notifications on my fullscreen windows, i want my key bindings for volume and screen brightness to keep working as i defined them in the compositor, i want to be able to minimize the window or to change the virtual desktop, i want to show the game on one screen and, say, my irc client on another one. You could make up many more examples, i think this suggestion would fit only for very restricted use cases.

If you move it to its own Wayland instance you could send messages over dbus.

[profoundWHALE]

So, if this is implemented, how much of a performance gain do we get? It might not be worth it.

Biggest benefit would be latency I think.

[unixfan2001]

Its bad, very bad idea, lets do it like Windows till XP, its working 12 years. Its like run game in Dos mode in Windows - Dos is also without multitasking.. Just fix the bugs and improve whole graphics pipeline, if Wayland isnt solution, Linux GUI is still at the start of real maturity.

I think you're confused here. This doesn't magically turn the Linux kernel into something that is unable to run with proper multitasking. Quite the contrary, the point is to free resources for the application running in the foreground.

It does actually make a lot of sense, provided it's done right. I'm afraid, though, there will be too many limitations for anyone but the average, non-tabbing/video recording gamer. While notifications could, potentially, be piped through a D-Bus interface and displayed by the game's Wayland session, screen recording and things like Teamspeak are a much harder problem. For screen recordings I'd imagine something like Xpra's internal Screenshot command, only for Wayland and fullscreen video, filling the void. The Wayland session itself could probably include that functionality.

[unixfan2001]

My point in saying it lost him a lot of credibility is that I have a hard time trusting the judgement of someone who comes up with that idea and doesn't realize the weaknesses in it (at least enough to acknowledge them) between starting to type and clicking submit.

It's not a matter of PR, it's a matter of me losing respect in Martin's ability to quickly recognize glaring flaws in solutions. It calls into question his ability to recognize less obvious flaws at all.

I'd argue that his constant moaning about CSDs is much worse. In fact that's where he lost the most credibility for me.
Rather than bitching and moaning, he should've presented a viable alternative (Server Side Decorations sure aren't) or help Ken Vermette with his DWD concept.

[justmy2cents]

I'd argue that his constant moaning about CSDs is much worse. In fact that's where he lost the most credibility for me.
Rather than bitching and moaning, he should've presented a viable alternative (Server Side Decorations sure aren't) or help Ken Vermette with his DWD concept.

true about CSD

especially when you take this KDE proposal (i don't know if Martin was involved, though) https://kver.wordpress.com/2014/10/2...w-decorations/ . instead of something simple, they proposed complete clusterfuck. this is like solving problem of moving pencil into a drawer by equipping it with custom made rocket propelled engine with custom made targeting system instead of grabbing it and simply put it where you want it

reading this proposal was the moment when i lost my whole concept of ever trying KDE in my life

[raster]

bad idea. adds complexity, breaks functionality, doesn't actually fix anything if you really think about it for a bit. bad bad bad bad idea. seriously. think about it for a bit. how does the game running on its own drm/kms screen STOP the compositor running now in the bg from waking up and handling client damage requests? sure compositor might not render, but it'll still wake up. this isn't solved. same for another wayland compositor.

the solution is if anything to pause any pid's u dont want interrupting your game. so send a SIGSTOP signal to "background process id's" that are not the game. very easy. now these procs are suspended and get zero cpu time by kernel until you SIGCONT them. the compositor can do this for any clients that would have windows (surfaces) obscured on the screen with a fullscreen game running. this is FAR simpler and ACTUALLY solves the problem. martin's suggestion, while well intentioned, does not.

[Revan]

Grabbing libinput exclusively is bad no matter how you put it. Any gamer needs to control the background applications somehow, like for example volume control is a must. Besides, what if I want clipboard functionality in my game? From my understanding this would be a nightmare to configure between Wayland sessions. A PC is not a console and that's what's great about it. The PC does not suffer from underpowered components so why treat it as if. Team speak or music playing in the background is something that most gamers do so why deny them this functionality?

[giucam]

Well proper game would respect the configuration defined in the environement and allow you to 'get out' of the 'game only mode', otherwise you'd have to reboot the computer to quit the game..

Proper games are not the problem. The problem is silly games not doing the right thing, and the system should be reliable even with those. I absolutely hate when i run a game in X and i cannot adjust the volume anymore, now with Wayland that's fixed. This proposal would bring that back, unless you're happy to switch VT everytime, which I'm not.

Then this is not a true fullscreen case, it's similar to a windowed mode (the desktop manager must manage the focus) so you cannot get rid of the CPU&memory usage of the desktop manager in this case.

That's still fullscreen. Fullscreen doesn't mean the window manager gives up all control, it just means an application uses the entirety of a screen (or many screens).