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

  • unixfan2001
    replied
    Originally posted by ssokolow View Post

    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.

    Leave a comment:


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

    Leave a comment:


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

    Leave a comment:


  • liam
    replied
    Originally posted by giucam View Post

    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.

    Leave a comment:


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

    Leave a comment:


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

    Leave a comment:


  • tebruno99
    replied
    How about instead of this KDE developers stop being lazy and write a proper desktop drawing handler that doesn't interfere with games. This is the most disturbing turn of events in the Linux desktop development. Rather than do detection that the desktop shouldn't draw and doing drawing correctly they want to just say, push this somewhere else so my code can remain greedy.

    Laziness, which is fine. The developers spend their hard earned free time doing this work. The part that bothers me is the claim that this is the right way to do it instead of admitting to being obsessed with eye candy and not wanting to give up control.

    Leave a comment:


  • Luke_Wolf
    replied
    Originally posted by ssokolow View Post

    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.
    This isn't the first time he's shown a lack of being in touch with how the gaming world works. As far as I can tell he's not actually a gamer at all and so he's approaching this from the perspective of being a developer of a compositor and desktop environment as opposed to from the perspective of a gamer and thus his priority is on performance I certainly agree with the comments on his blog that breaking alt-tab, with the rationale that it's okay because hey Xorg breaks Alt-tab, is just lame, and I don't think a host-key is really an acceptable solution

    Leave a comment:


  • fscan
    replied
    Originally posted by ssokolow View Post

    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.
    +1

    i mean - WTF-. i don't even know where to start ....

    Leave a comment:


  • jrch2k8
    replied
    Originally posted by sarmad View Post
    So, if this is implemented, how much of a performance gain do we get? It might not be worth it.
    is not how much performance you gain but how much performance you won't lose and that may vary a lot depending the hardware capabilities and the render quality and how nasty is the hit of the compositor rendering offscreen when there is a fullscreen app running on foreground. so maybe a lot maybe few fps maybe null depending the compositor/hardware/game combo

    Leave a comment:

Working...
X