Page 4 of 5 FirstFirst ... 2345 LastLast
Results 31 to 40 of 45

Thread: Stop grabbing my keyboard :(

  1. #31
    Join Date
    Oct 2007
    Location
    Under the bridge
    Posts
    2,146

    Default

    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.

  2. #32
    Join Date
    Jun 2010
    Location
    ฿ 16LDJ6Hrd1oN3nCoFL7BypHSEYL84ca1JR
    Posts
    1,052

    Default

    Quote 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.

  3. #33
    Join Date
    Jun 2010
    Location
    ฿ 16LDJ6Hrd1oN3nCoFL7BypHSEYL84ca1JR
    Posts
    1,052

    Default

    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.

  4. #34
    Join Date
    Sep 2008
    Posts
    40

    Default

    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

  5. #35
    Join Date
    Jan 2014
    Posts
    8

    Default

    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

  6. #36
    Join Date
    Nov 2011
    Posts
    11

    Default 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?

  7. #37
    Join Date
    Dec 2008
    Location
    Vermont
    Posts
    106

    Default

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

  8. #38
    Join Date
    Jun 2012
    Posts
    361

    Default

    Quote 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.

  9. #39
    Join Date
    Jun 2012
    Posts
    361

    Default

    Quote 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.

  10. #40
    Join Date
    Nov 2011
    Posts
    11

    Default

    Quote 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...

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •