Announcement

Collapse
No announcement yet.

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

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • ruthan
    replied
    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..

    Leave a comment:


  • giucam
    replied
    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.
    Ah sure, if the daemon goes behind X's back that works. In my experience however, that's not how they work in the X world, and an application grabbing all input breaks them.

    Leave a comment:


  • unixfan2001
    replied
    Originally posted by giucam View Post
    I absolutely hate when i run a game in X and i cannot adjust the volume anymore, now with Wayland that's fixed.
    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:


  • giucam
    replied
    Originally posted by renox View Post
    Play with the words all you want, mgraesslin's proposal only work when the game is the only one managing ALL the screens.
    I agree with that, and that's the problem. It is very inflexible and has many downsides, just to reduce the input delay by an unknown factor and to increase the FPS by another unknown factor. Until some numbers back this i see no upside at all compared to a well functioning wayland session.

    Leave a comment:


  • renox
    replied
    Originally posted by giucam View Post
    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).
    Play with the words all you want, mgraesslin's proposal only work when the game is the only one managing ALL the 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:


  • giucam
    replied
    Originally posted by unixfan2001 View Post
    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.
    You could send notifications to the game, if they implement the freedesktop DBus protocol, but the game would need to actually draw them, the notification bubble with the text. I don't see any game doing that.
    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:


  • giucam
    replied
    Originally posted by renox View Post
    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.

    Originally posted by renox View Post
    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).

    Leave a comment:


  • Revan
    replied
    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:


  • raster
    replied
    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:


  • justmy2cents
    replied
    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:

Working...
X