Announcement
Collapse
No announcement yet.
A Call To Move Games Outside Of Linux Desktop Environments, Own Wayland/KMS Setup
Collapse
X
-
What about run games in some ad hoc virtual machines? Virtual machine environment could be quite isolated from other events and settings on machines and only input which is send from virtual machines to physical OS system is simple 2D picture to be drawn..
-
Originally posted by unixfan2001 View Post
Been fixed way before Wayland. You just need an independent daemon listening for global keyboard events. Something like esekeyd or acpid.
Binding hotkeys to the display server has never been a particularly good design.
Leave a comment:
-
Originally posted by giucam View PostI absolutely hate when i run a game in X and i cannot adjust the volume anymore, now with Wayland that's fixed.
Binding hotkeys to the display server has never been a particularly good design.
Leave a comment:
-
Originally posted by renox View PostPlay with the words all you want, mgraesslin's proposal only work when the game is the only one managing ALL the screens.
Leave a comment:
-
Originally posted by giucam View PostThat'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).
So if you have one screen managed by the game and another managed by the DE then obviously you cannot get rid of the performance impact of the DE.
Leave a comment:
-
Originally posted by unixfan2001 View PostIt 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.
Unless the games run in their own wayland session as you say, so the wayland compositor they run in would draw them, but then what is the point? Isn't that what we have now?
Leave a comment:
-
Originally posted by renox View PostWell 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..
Originally posted by renox View PostThen 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.
Leave a comment:
-
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?
Leave a comment:
-
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.
Leave a comment:
-
Originally posted by unixfan2001 View Post
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
Leave a comment:
Leave a comment: