Announcement

Collapse
No announcement yet.

Stop grabbing my keyboard :(

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

  • #31
    Holy necro Batman, you dug out a 5-year old thread just to post that?

    That said, developers who cannot get this right in 2014 should be driven out of the game market. This should have been a non-issue since the introduction of libXi (half a decade ago), and SDL2 now.

    Comment


    • #32
      Originally posted by BlackStar View Post
      Holy necro Batman, you dug out a 5-year old thread just to post that?
      Oops, right, 5 years, not 3.

      But as it's still the exact same issue, why not?

      Of course it should be a non-issue. With SDL2 there's even this very nice scaling of "fullscreen" applications with lesser resolution to the actual resolution that never changes the actual display resolution. This is how it should have been done years ago.

      Comment


      • #33
        It's this obsession over this one thing, altering the configuration the user has chosen for his display, that I don't get at all.

        I had played The book of Unwritten Tales on my laptop display a bit after I set the resolution to 1920x1080.

        Now I have connected an external display and started this game again. Can anyone guess what happened?

        The external display kept at 1920x1080 while the game started on the laptop screen AND CHANGED THE FUCKING RESOLUTION TO 1024x768. WHY

        Also I received one of those
        Code:
        (EE) Backtrace:
        (EE) 0: /usr/bin/X (xorg_backtrace+0x48) [0x584ae8]
        (EE) 1: /usr/bin/X (mieqEnqueue+0x22b) [0x566b7b]
        (EE) 2: /usr/bin/X (QueueKeyboardEvents+0x52) [0x44c662]
        (EE) 3: /usr/bin/X (xf86PostKeyboardEvent+0x44) [0x483064]
        (EE) 4: /usr/lib/xorg/modules/input/evdev_drv.so (0x7f2a3625d000+0x5599) [0x7f2a36262599]
        (EE) 5: /usr/bin/X (0x400000+0x72f68) [0x472f68]
        (EE) 6: /usr/bin/X (0x400000+0x9b530) [0x49b530]
        (EE) 7: /usr/lib/libpthread.so.0 (0x7f2a43c66000+0xf870) [0x7f2a43c75870]
        (EE) 8: /usr/lib/libc.so.6 (ioctl+0x7) [0x7f2a42995e27]
        (EE) 9: /usr/lib/libdrm.so.2 (drmIoctl+0x34) [0x7f2a43a5d9d4]
        (EE) 10: /usr/lib/xorg/modules/drivers/intel_drv.so (0x7f2a3e51b000+0x5fea7) [0x7f2a3e57aea7]
        (EE) 11: /usr/bin/X (xf86CrtcSetModeTransform+0x12b) [0x4aa9eb]
        (EE) 12: /usr/bin/X (0x400000+0xb3e16) [0x4b3e16]
        (EE) 13: /usr/bin/X (RRReplaceScanoutPixmap+0x120) [0x4efcd0]
        (EE) 14: /usr/bin/X (DRI2UpdatePrime+0x1ae) [0x55602e]
        (EE) 15: /usr/lib/xorg/modules/drivers/radeon_drv.so (0x7f2a3de8e000+0x4190e) [0x7f2a3decf90e]
        (EE) 16: /usr/bin/X (0x400000+0x1556ab) [0x5556ab]
        (EE) 17: /usr/bin/X (DRI2SwapBuffers+0x1d1) [0x556b41]
        (EE) 18: /usr/bin/X (0x400000+0x1582d3) [0x5582d3]
        (EE) 19: /usr/bin/X (0x400000+0x35d1e) [0x435d1e]
        (EE) 20: /usr/bin/X (0x400000+0x39b2a) [0x439b2a]
        (EE) 21: /usr/lib/libc.so.6 (__libc_start_main+0xf5) [0x7f2a428d9b05]
        (EE) 22: /usr/bin/X (0x400000+0x250ce) [0x4250ce]
        I realize that this probably comes from my drivers being git snapshots, but there is xf86CrtcSetModeTransform in the stacktrace so it still may be related.

        Comment


        • #34
          Since this thread has been resurrected...

          Found this problem in 0AD, too. Had volume turned down for background music (stopped before starting the game) but media shortcuts wouldn't work in game, nor would alt+tab. Related ticket: http://trac.wildfiregames.com/ticket/965

          Comment


          • #35
            Few days ago I did it in Supertuxkart - run game using window manager fullscreen.

            It's not so easy like some people say. There were some issues. For example Gnome sometimes creates fullscreen window which is smaller than display. Actually it creates fullscreen window, but it says that it's smaller ;p And for example on Unity I can't open window as not-resizable because in such case it's opened in windowed mode - also I dunno why.

            I tested it on three desktop environments. And how many window managers we have on linux? Twenty? Or more?

            It's really much easier to use three commands:
            XSetInputFocus(display, window, RevertToParent, CurrentTime);
            XGrabKeyboard(display, window, True, GrabModeAsync, GrabModeAsync, CurrentTime);
            XGrabPointer(display, window, True, ButtonPressMask, GrabModeAsync, GrabModeAsync, window, None, CurrentTime);

            and to be sure that everything works properly.

            Even in Half-life 2 - it's really easy to disable fullscreen using window manager (flag + F or other shortcut) and resize it. In such case game will crash or will draw some strange things ;p

            Comment


            • #36
              Digging the thread again....

              Well, I have tried a lot of Linux native games in the last month, many of them obtained in various bundles. A lot of them froze at some time while running. Some of them froze just by using Alt+tab (whithot releasing the keyboard grab, of course). And when that happens, my dekstop is usually gone. When a game locks up, Ctrl+Alt+Fn often doesn't work, so I can't do anything from my machine. If I ssh from another computer to it, sometimes killing the game process brings desktop back, but more often the screen just stays black/scrambled/whatever, no matter what process I kill and sudo reboot is the only option (or reset button, as last solution).

              Last few hours I have searched the net for a general solution to this, but without luck. Most of the solutions are game or library (SDL) specific, hacks and don't work in general way.

              Why is it that ONE badly behaving window/application can bring down the whole X and all other applications that I'm running? Where is that famous Linux memory/buffer/whatnot inter-process protection in this case? When I started to use Linux I thought that its graphics stack wouldn't allow something like this to happend (contrary to Windows at that time), but, boy, was I wrong... And nothing changed in years regarding that issue.

              Is it possible to just disable keyboard grab functionality altogether on X? Assign a dummy function to it or something?

              Comment


              • #37
                The Magic SysRq key combinations are your friend, as is google.

                Comment


                • #38
                  Originally posted by Dragonlord View Post
                  In what kind of dream world are you living? In windows it's one of the main problems that you can't alt-tab out of a game. Either you can't get out of it or once you do you can't get safely back into it. Under Linux this is a lot less of a problem. If I want to I can totally override a hotkey of an application in Linux which I can't in windows.
                  It works a LOT better as of Vista. I'd say it works the first dozen or so time you use it, but if you abuse it a ton, games will tend to eventually crash. But its better then it was in XP, when the odds of it working were somewhere between slim and none.

                  Comment


                  • #39
                    Originally posted by zzarko View Post
                    Well, I have tried a lot of Linux native games in the last month, many of them obtained in various bundles. A lot of them froze at some time while running. Some of them froze just by using Alt+tab (whithot releasing the keyboard grab, of course). And when that happens, my dekstop is usually gone. When a game locks up, Ctrl+Alt+Fn often doesn't work, so I can't do anything from my machine. If I ssh from another computer to it, sometimes killing the game process brings desktop back, but more often the screen just stays black/scrambled/whatever, no matter what process I kill and sudo reboot is the only option (or reset button, as last solution).

                    Last few hours I have searched the net for a general solution to this, but without luck. Most of the solutions are game or library (SDL) specific, hacks and don't work in general way.

                    Why is it that ONE badly behaving window/application can bring down the whole X and all other applications that I'm running? Where is that famous Linux memory/buffer/whatnot inter-process protection in this case? When I started to use Linux I thought that its graphics stack wouldn't allow something like this to happend (contrary to Windows at that time), but, boy, was I wrong... And nothing changed in years regarding that issue.

                    Is it possible to just disable keyboard grab functionality altogether on X? Assign a dummy function to it or something?
                    The way something like this is handled in a Windows app is that, unless overloaded by the app, certain key combinations are guaranteed to work. Alt-F4 invokes Quit(), Alt-Tab invokes Minimize(), and so on. And if not touched by the dev, these methods simply invoke the Win API and do what they are supposed to do in a coherent manner that's common to all apps. The fact the app may not have a floating X or _ button at the top of it is irrelevant so far as the actual behavior is concerned. On Windows, something like this is an afterthought; we don't concern ourselves with it.

                    Comment


                    • #40
                      Originally posted by phred14 View Post
                      The Magic SysRq key combinations are your friend, as is google.
                      I know about those, but I wanted something to regain control of computer, not to just reboot it. I have found some xdotool keypresses that can be executed over ssh:
                      Code:
                      DISPLAY=:0 xdotool key XF86Ungrab
                      DISPLAY=:0 xdotool key XF86ClearGrab
                      DISPLAY=:0 xdotool key Ctrl+Alt+F1
                      I'll try them next time the game locks up...

                      Comment

                      Working...
                      X