Announcement

Collapse
No announcement yet.

Alt+TAB and fullscreen games

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

  • #16
    I have the same issue, so if you do find a solution please post it here, and I will do the same.

    Its annoying because the only game I play runs like poop with the open drivers, but I cant play and read the net (its a slow game) with the fglrx ones.


    Running as root sometimes shakes the problem, and it sometimes still exists, similar (although) not as bad as running it normally.

    Comment


    • #17
      ...well, you could try unrawing the keyboard. Alt-Sysrq-R

      not sure what result that will give you in a fullscreen gl app. have fun

      Comment


      • #18
        Originally posted by Ishayu View Post
        Okay, so I've always had this problem where it's impossible to alt+TAB out of fullscreen applications. Most applications that are native to Linux use SDL, which overrides it anyway, but Wine doesn't for example, so let's look at that.

        If I alt+TAB, all that happens is that the screen flickers a little bit, the game still overlays the screen but if I click anywhere, the OS behaves as if the window I wanted in front is in front, so clearly only a display issue.

        I had pretty much accepted this problem. It would never go away I thought.

        But then, today, magically, it went away.

        2 hours later, it came back.

        So now I want to ask what the hell I did. Maybe someone knows exactly how to make it work, persistantly? That would be great.

        Reason why I'm posting here?
        I use FGLRX, and I do not have this issue with the MESA-drivers. (They, however, just perform terrible. )
        In KDE make sure you have the "Show Desktop" widget in your tray (normally it's there during install). In the properties set shortcut to WINDOWS+D (META+D) combination. Now every time you want to get out of a game or full screen, just use this combination.

        Comment


        • #19
          i have the feeling that most people misunderstand the problem the op has.
          the issue with fglrx is that as soon as an opengl window has the same size as your screen resolution it seems to render directly into the output buffer without redirecting the window first
          the only fglrx driver that doesn't behave like this is 10.7
          you may want to try that one

          Comment


          • #20
            Originally posted by Pfanne View Post
            the only fglrx driver that doesn't behave like this is 10.7

            Out of interest does anyone know what the newest kernel and xorg version 10.7 will run on ?

            Its an annoying problem, that I want to get around, but I have a pretty new kernel and xorg so I need to research this before jumping in head first

            Comment


            • #21
              try a different window manager. A gnome bug is not a linux bug.

              Comment


              • #22
                Originally posted by energyman View Post
                try a different window manager. A gnome bug is not a linux bug.
                ++

                Additional suggestion: disable compiz or toggle its "unredirect fullscreen windows" option.

                Comment


                • #23
                  Originally posted by energyman View Post
                  try a different window manager. A gnome bug is not a linux bug.
                  i tried this with metacity, compiz, kwin and kwin with enabled compositing.
                  they all have the same behaviour.
                  though i tested this like half a year ago.

                  Comment


                  • #24
                    Originally posted by energyman View Post
                    try a different window manager. A gnome bug is not a linux bug.
                    Except it's not a GNOME bug! =)

                    I tried with GNOME, KDE, LXDE, Compiz, and even OpenBox.

                    They all exhibit the EXACT same behavior.

                    I also tried the sugestion to unredirect. It made no chance either.

                    Comment


                    • #25
                      It is problem of Xorg and OpenGL.
                      Application should never be able to override the key combination used to force it background. That simple.

                      RealNC is wrong. In WOS, applications do override alt-tab making impossible to switch, they do crash or unable to get back after switch, they do freeze the whole system grabing input controls in the process, so your only option is to reboot. And you have no access to tty unlike linux and GFX system is not separated, so youre screwed.

                      Running WINE as root is incredibly, incredibly stupid.

                      1) You have a subsystem that shares and emulates micro-flaws.
                      2) That runs closed source software.
                      3) That will have full access to your data.
                      4) And in case of root to system memory, root space, other users data.
                      5) That CAN very good run viruses.

                      You are screwed.
                      Sure way to "port" those 1 Million viruses to linux, including stormworm- and rootkit-like.

                      Never do this. Better boot WOS and wipe it off the separate drive after you are done.

                      Comment


                      • #26
                        Originally posted by crazycheese View Post
                        It is problem of Xorg and OpenGL.
                        Application should never be able to override the key combination used to force it background. That simple.

                        RealNC is wrong. In WOS, applications do override alt-tab making impossible to switch, they do crash or unable to get back after switch, they do freeze the whole system grabing input controls in the process, so your only option is to reboot. And you have no access to tty unlike linux and GFX system is not separated, so youre screwed.

                        Running WINE as root is incredibly, incredibly stupid.

                        1) You have a subsystem that shares and emulates micro-flaws.
                        2) That runs closed source software.
                        3) That will have full access to your data.
                        4) And in case of root to system memory, root space, other users data.
                        5) That CAN very good run viruses.

                        You are screwed.
                        Sure way to "port" those 1 Million viruses to linux, including stormworm- and rootkit-like.

                        Never do this. Better boot WOS and wipe it off the separate drive after you are done.
                        So what you're saying is...
                        When Unity/Wayland is out, this should be fixed? (I am an Ubuntu user)

                        Sure hope so! =P It's really annoying.

                        Comment


                        • #27
                          Since still people didn't get it:

                          What to do:
                          1) Start i.e. warcraft3 in wine with your full desktop resolution (I have set a virtual desktop for handling applications like a normal window).
                          2) Press alt+tab
                          -> After a short flicker another application will have the keyboard focus, but warcraft3 will still be in the foreground.
                          3) Change your workspace with i.e. ctrl+alt+right. warcraft3 will after a short flicker be displayed on this workspace in the front of all windows too.
                          4) Try minimizing it with the "show desktop" function of the window manager. After a short flicker your window manager thinks warcraft3 is minimized, but it is still displayed fullscreen on all workspaces.

                          With catalyst 10.10 no window can be put in front of a big window with 3d-content.
                          In earlier versions of catalyst it sometimes worked, as long as the window you wanted to place over it was not maximized or bigger as the desktop resolution. But sometimes it didn't work and sometimes X just froze.

                          Putting windows above 3d-fullscreen windows works with the proprietary nvidia driver, with xf86-video-ati and I think it also works with xf86-video-intel.

                          Someone in the archlinux irc suggested that it is because fglrx doesn't use dri2 properly but rather something like dri2.
                          From my Xorg.0.log I see
                          Code:
                          [ 24578.166] (II) Loading extension ATIFGLRXDRI
                          [ 24578.309] (II) AIGLX: Loaded and initialized /usr/lib/dri/fglrx_dri.so
                          So maybe he is right and the dri implementation of ATI is more dri-like instead of dri2-like.

                          It also says
                          Code:
                          [ 24576.794] (II) "dri" will be loaded by default.
                          [ 24576.794] (II) "dri2" will be loaded by default.
                          but that doesn't mean, that it is used, right?

                          Comment


                          • #28
                            Originally posted by bongmaster2
                            just run wine as root.no problem switching workspaces ort alttabbing then.
                            I tried that too (just for testing) and it didn't help. Now it was flickering all the time after alt-tabbing unti warcraft3 had the focus again.
                            Plus with wine as root there are some graphics glitches. In the warcraft3 menu there's for example the texture of the water missing.

                            Comment


                            • #29
                              Originally posted by ChrisXY View Post
                              Since still people didn't get it:..
                              Sorry, forget my comments, yes this is definitely Catalyst bug.
                              I was referring to standard window switch keycombo, but not forceful window overlapping. This is definitely bug.

                              Comment


                              • #30
                                I would like to edit my posts, but you know... So new post...

                                I had xfwm4 compositing on and with that it is impossible to get any window over a fullscreen 3d window. Without that compositing it works for "little" windows but the fullscreen window still flickers and sometimes hangs for a second when alt-tabbing. For "big" windows it still doesn't work.

                                Comment

                                Working...
                                X