Announcement

Collapse
No announcement yet.

Two Features Wayland Will Have That X Doesn't

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

  • Two Features Wayland Will Have That X Doesn't

    Phoronix: Two Features Wayland Will Have That X Doesn't

    While the discussion surrounding the Wayland Display Server and Canonical's plans to deploy Ubuntu atop Wayland continue to be ongoing within our forums (here, here, and here) and elsewhere, some new technical capabilities and plans for Wayland have been discussed. Here's two features that Wayland is set to have that is not currently supported by the X.Org Server...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    So let me get this straight: a toy display server has a half-baked plan for hypothetical support for three features (device switching, explicit full-screen mode, and relative mouse input) when one is already solved in X (XInput2), one is easily solvable (add a full-screen mode extension), and one would be equally hard to solve in either environment? This doesn't seem like news.

    Comment


    • #3
      Originally posted by md1032 View Post
      So let me get this straight: a toy display server has a half-baked plan for hypothetical support for three features (device switching, explicit full-screen mode, and relative mouse input) when one is already solved in X (XInput2), one is easily solvable (add a full-screen mode extension), and one would be equally hard to solve in either environment? This doesn't seem like news.
      There are two kinds of people in the world, pessimist's and optimist's

      Comment


      • #4
        i know the pain in the ass, cant play any penumbra, openarena etc.. mouse is crazy... sometimes clicking doesnt work good..

        fast implement the wayland!

        Comment


        • #5
          I don't know what it's called, but the second feature sounds really cool. I hate launching games in Linux and then they default to Fullscreen and mess up the resolution when I exit back to X.org. But after the first run I usually get it set to run in a window, but for some games I'd like to do full screen but I can't.

          I've also had problems with the fact that I use two screens, and sometimes games try to span both screens. I think I solved that with some xorg.conf magic though.

          Comment


          • #6
            Originally posted by pvtcupcakes View Post
            I hate launching games in Linux and then they default to Fullscreen and mess up the resolution when I exit back to X.org. But after the first run I usually get it set to run in a window, but for some games I'd like to do full screen but I can't.
            I don't get why one needs to run a game "full screen". Just draw a window with the size of the desktop and use the fullscreen function of your windowmanager.
            No need for implementing fullscreen-window-managing-functions into the application.

            Comment


            • #7
              Finally a tangible set of features. It's what Wayland has been lacking so far, good marketing.

              Comment


              • #8
                Even worse is when an application requests full-screen in a resolution that your monitor doesn't support, and doesn't offer an easy way to select another resolution. Then you're stuck in the full-screen app (sometimes with no easy way to exit the app without getting the X server stuck in an unsupported resolution), possibly with other things open that you don't want to lose.

                I know, it's a configuration problem with Xorg. But it's a problem I had often with the nv driver (even/especially when auto-configured), and one that I still sometimes have with nouveau. Wayland could provide a good solution.

                If any of this could be done with Xorg, why hasn't it (a serious question)? Why did they go with quick hacks, or no solution at all? (the answer to that question, at least with regards to the full-screen app problem, would probably be that it's because Xorg isn't a compositor; it's a display server/api)

                Comment


                • #9
                  Originally posted by ChrisXY View Post
                  I don't get why one needs to run a game "full screen". Just draw a window with the size of the desktop and use the fullscreen function of your windowmanager.
                  No need for implementing fullscreen-window-managing-functions into the application.
                  This seems like the simple and correct method to support this. In KDE, setting these rules is exceptionally easy.

                  Comment


                  • #10
                    ...just enough that they know the screen sizes and layout. Either the compositor can run a special client with access to the modesetting interface or changing the resolution and/or screen layout could just be part of the compositor.
                    I don't like the idea of any application controlling the screen resolution at all under any circumstances. If the dumb game wants a different resolution, it should either be scaled or bordered. NEVER let a dumb game change the resolution.

                    Note: hack to prevent dumb game from changing the resolution: xrandr to delete all non-native modes.

                    Comment

                    Working...
                    X