Announcement

Collapse
No announcement yet.

XWayland Lands RandR/Vidmode Emulation For Better Game Handling

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

  • #31
    Originally posted by 144Hz View Post
    There’s no such thing as “just Mutter”. Mutter represents a long list of developers and distributors who understand you only need one/few compositors.[/URL]
    Or, conversely, Mutter is the latest in a long line of examples of GNOME people refusing to work with KDE developers who were receptive to working together on a shared solution, then getting pissy when people don't flock to something that's objectively technically inferior.

    GNOME began as an "I'm going to build my own [...] with blackjack and hookers" response to KDE, because, at the time, Qt's license was less favourable. It took many years for GnomeVFS to not be a crashy, buggy, inferior knock-off of KIOSlaves. D-Bus, an example where both sides did come together on a common solution, draws far more from KDE 3.x's DCOP than GNOME 2.x's use of CORBA. etc. etc. etc. (In some cases, the NIHing was purely because they felt such an aversion to C++ that they felt it was better to rewrite something from scratch in C than to add a dependency on C++ code that KDE developers either did offer C bindings for or offered to write C bindings for.)

    GNOME developers have a long history of being unreasonable ideologues.
    Last edited by ssokolow; 13 October 2019, 04:02 AM.

    Comment


    • #32
      Originally posted by 144Hz View Post
      ssokolow Things just work (tm) on GTK/Mutter. It’s really hard to justify making things compatible with something as backwards as what you want. Development resources are better spent on further GTK/Mutter work.

      Compatibility is much harder than shared code. And then there’s all the hostility and fragmentation. Redhat paid for making Qt software somewhat tolerable on Mutter. And that’s as far as this will go.

      Compatibility is an endless money and developer sink.
      Ahh, so you're saying that GNOME is a waste of time and effort and we should all just learn to live with Windows's undesirable design decisions then.

      Comment


      • #33
        Originally posted by ssokolow View Post
        The whole point is to make permanent resolution changes a privileged operation so that applications can't abuse them the way X11 games did XRandR. (Most infamously, "game crash leaves resolution at 640x480 or whatever")
        I remember Quake 3 doing this in Windows too. I'm not intentionally trying to defend Wayland's extremely slow adoption, but it took Windows an extremely long time to fix this problem.

        I don't think it was ever fixed in XDDM and only in later versions of WDDM. I could be wrong. I tried searching, but couldn't find anything Google's memory is not what it used to be.

        Comment


        • #34
          Originally posted by Jabberwocky View Post

          I remember Quake 3 doing this in Windows too. I'm not intentionally trying to defend Wayland's extremely slow adoption, but it took Windows an extremely long time to fix this problem.

          I don't think it was ever fixed in XDDM and only in later versions of WDDM. I could be wrong. I tried searching, but couldn't find anything Google's memory is not what it used to be.
          Yeah. That's why Wayland scopes un-privileged fullscreening-related operations to the lifetime of a window.

          Screensaver suppression is another one that X11 apps never got right... though xdg-screensaver suspend <WindowID> was an attempt at retrofitting the proper API and I've mentioned the need to watch joysticks when calculating input idle on the Wayland thread that was talking about a gamepad protocol at the Wayland level.
          Last edited by ssokolow; 16 October 2019, 07:30 AM.

          Comment

          Working...
          X