Announcement

Collapse
No announcement yet.

A Proposal To Fix The Full-Screen Linux Window Mess

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

  • #41
    Originally posted by mememe View Post
    But why should games have to call the window manager to change the resolution? What's wrong with _NET_WM_FULLSCREEN + xrandr?
    You don't have a "office" screen with native 1280x1024 at 75Hz for sure to ask that


    Funny thing is that i solved the problem with my Window$ program

    Comment


    • #42
      Originally posted by Gps4l View Post
      Reading this I get cynical.

      Can some one tell the kde team, that steam is coming to Linux ?

      Or is kde telling me: Hey if you wanna game, don't use kde ?

      I believe that the KDE devs selected second option....

      Comment


      • #43
        Originally posted by dfx. View Post
        the facts that:
        1) all displays are at their best settings
        2) guarantee that things from one side will not mess up things on the other under any circumstances
        are pretty damn hefty on their own.
        The first you can do anyway. The second is an advantage, though to be honest I'd rather a more general solution (i.e. applications started under X not dying if X crashes but reattaching to another display).

        Kasoroth: couldn't agree with you more about faster switching and allowing overlays in the game.

        Comment


        • #44
          Fail

          Well, I'm really fed up with games not handling display properly.

          I have two screens, both at the same resolution. Most games will mess with it for no reason - changing resolution, breaking my desktop by cloning the first screen (hilarious when the game ends up being on the second screen, right?) or turning off one of the screens entirely (at random, doesn't ask me which one I want to play on). Some games can't handle multimonitor at all - they end up centered on the two screens, one half on the left, one on the right... So what I've been doing is forcing games to 1680x1050 (or lower for recording with ffmpeg), forcefully disabling fullscreen and removing windows decorations. I can move them between screens, I can minimize them, they don't break things and I have no problems... performance be damned.

          So, never mess with screen resolutions. It should be a config option of the WM. Or something like 'Virtualize fullscreen windows'/'report fake screen parameters to fullscreen windows'. Also, I'd like to have a reliable way to switch from windows that are capturing input. It's no good to have a game on one screen and not being able to mess with things on the other screen. I need my teamspeak, skype, pidgin, etc. Don't make me exit out of the game for them. Ever. There needs to be a global shortcut for changing windows that no application can override.

          Last thing that's really missing on linux is *reliable* and *user friendly* way to record/stream games. For that to be possible at all, this fullscreen thing has to be resolved first.

          Comment


          • #45
            Originally posted by Peterix View Post
            I have two screens, both at the same resolution. Most games will mess with it for no reason - changing resolution, breaking my desktop by cloning the first screen (hilarious when the game ends up being on the second screen, right?) or turning off one of the screens entirely (at random, doesn't ask me which one I want to play on). Some games can't handle multimonitor at all - they end up centered on the two screens, one half on the left, one on the right...
            I do not know if any of these work, but there are some suggested workarounds listed here:
            When I run Amnesia: Dark Descent or Superbrothers: Sword & Sworcery, the games are stretched across both my monitors, like this: Limbo crashes on start-up: How can I solve these problems?


            Originally posted by Peterix View Post
            Last thing that's really missing on linux is *reliable* and *user friendly* way to record/stream games. For that to be possible at all, this fullscreen thing has to be resolved first.
            There is glc, which does a fairly nice job at capturing OpenGL games. And since I am not the first person in this thread to be pimping their own software, I will mention that I made a GUI front-end for glc to streamline some of it's complexities:

            Comment


            • #46
              Originally posted by Kasoroth View Post
              I would think that with all the video acceleration technology we have, upscaling or downscaling an image (with appropriate black bars for aspect ratio differences) wouldn't be too much of a performance problem. Video players have been handling full screen playback of arbitrary resolution sources on arbitrary resolution screens for a long time, and in my experience they tend to actually do a better job of scaling than most LCD monitors at non-native resolution.
              It is relatively trivial, the point is it's completely needless. Game designers usually want to maximize the frame rate as much as possible, and since you can avoid an upscale operation just by changing the resolutions (something other operating systems have been doing for awhile), there should at least be protocols set in place to correctly handle this if the application and WM want it. If there isn't, the eventually people will try and make a Wayland extension of some kind which they can call directly to bypass this limitation in Wayland's protocol. Then we'll end up with the same flaws we have today with applications directly setting the scene resolutions without setting it back if they crash (and not properly handling multi-monitor setups).

              I would actually prefer that programs not be able to change the real display resolution. ...
              That's cool, and ideally the WM would give you options concerning this. That's why I said it would only be a request the WM could choose to ignore (via upscaling the wl_surface), or handle it properly (by remembering previous resolution settings in case of a crash). Wayland is about simplifying and fixing the protocols, and this is obviously a sore spot for Linux gamers, so it's something Wayland should get right early on. A standard request protocol would allow for both ways to be done (you and I can both be happy) at the same time making the developers lives easier (they don't need to write upscale logic themselves, only request fullscreen).


              EDIT: Please disregard all that above.

              I just got conformation on the #wayland IRC channel, and Wayland does indeed work like I was hoping. Wayland provides a client request for mode/size/refresh-rate which the Compositor can choose to grant or ignore however it sees fit. Xrandr (and others) don't exist in wayland, so there's no danger of clients manually changing resolution. All applications have to do is create a wl_surface at a spefic size and request a resolution to match that. Looks like all my fears where for nothing. Awesome!
              Last edited by F i L; 25 October 2012, 06:43 PM.

              Comment


              • #47
                Originally posted by AJSB View Post
                You don't have a "office" screen with native 1280x1024 at 75Hz for sure to ask that


                Funny thing is that i solved the problem with my Window$ program
                No I have a TFT with 1920 x 1080 @ 60Hz native resolution. I also don't use Linux atm (missing it, but too lazy to install). What I still don't get is why it's not possible to just use XRandR + _NET_WM_FULLSCREEN. I think it makes more sense that the Xserver is responsible for changing the display resolution and the window manager is reponsible for dealing with windows. Maybe we should fix the issues with both instead of coming up with yet another hack.

                Comment


                • #48
                  Originally posted by F i L View Post
                  I just got conformation on the #wayland IRC channel, and Wayland does indeed work like I was hoping. Wayland provides a client request for mode/size/refresh-rate which the Compositor can choose to grant or ignore however it sees fit. Xrandr (and others) don't exist in wayland, so there's no danger of clients manually changing resolution. All applications have to do is create a wl_surface at a spefic size and request a resolution to match that. Looks like all my fears where for nothing. Awesome!
                  Yeah, we have a sketch on the public fullscreen request on the desktop shell:


                  That protocol doc does not say everything, the implementation still has lots of room to make decisions. For instance, one idea was, that when you alt+tab, the resolution does not change until you release the alt key, which makes choosing a window fluent. A resolution change could happen, when you move your focus from a normal app and raise a fullscreen app, or vice versa. Will it happen, depends on the hardware (is it supported nicely), compositor implementation (is it more performant than not changing resolution and doing something else), and user configuration (does user want the compositor to change resolutions ever? should it change resolutions of all fullscreen apps, not just those that really ask for it? etc.), and probably other things. Of course, if you don't change resolutions, the compositor has to do something else, that is still sensible. Ultimately all that should be configurable in compositor preferences. The protocol offers a way for an application to express the intent, and the compositor carries it out according to user preferences.

                  This fullscreen request is specifically for temporary resolution changes for fullscreen apps, so that the compositor can accommodate the particular fullscreen-wannabe window the best way it can. Since the resolution is tied to the window, a disappearing window (a crashing game) will immediately return the whole output to normality.

                  It is not the XRandr equivalent, which is for permanent (for this session) display configuration. For that we don't have an interface at all, yet.

                  Comment


                  • #49
                    Originally posted by mememe View Post
                    What I still don't get is why it's not possible to just use XRandR + _NET_WM_FULLSCREEN.
                    Did you read this thread? What would be possible if the WM would handle it instead of the app (without nasty hacks):
                    - Guaranteed multi-monitor compatibility.
                    - Fake resolution (scale up/down).
                    - Reset resolution back if the application crash.
                    And maybe more. The WM could even decide to paint the fullscreen window as desktop background image (up/downscaled if needed).

                    Comment


                    • #50
                      Originally posted by mememe View Post
                      No I have a TFT with 1920 x 1080 @ 60Hz native resolution. I also don't use Linux atm (missing it, but too lazy to install). What I still don't get is why it's not possible to just use XRandR + _NET_WM_FULLSCREEN. I think it makes more sense that the Xserver is responsible for changing the display resolution and the window manager is reponsible for dealing with windows. Maybe we should fix the issues with both instead of coming up with yet another hack.
                      Because having the WM know when/why a resolution change occurs means they can deal with it intelligently? Like, by saving current layout/widget state for restoration when the resolution goes back to normal.

                      EDIT: The Wayland approach sounds excellent (eventually).

                      Comment

                      Working...
                      X