Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Breaks in video games #4

Open
azy2 opened this issue Jan 30, 2018 · 3 comments
Open

Breaks in video games #4

azy2 opened this issue Jan 30, 2018 · 3 comments

Comments

@azy2
Copy link

azy2 commented Jan 30, 2018

I use this program to swap esc and caps lock and left control with left alt:

uncap.exe 0x14:0x1B 0x1B:0x14 0xA2:0xA4 0xA4:0xA2

But inside of video games neither key works. Pressing neither caps lock nor esc brings up the menu.

At least in my case it would be okay if the program didn't work in video games, that is the keys performed their original function. But it seems to break the keys all together.

Any ideas about why that is or how to work around it? If you have any ideas I'll look into fixing it and make a pull request.

@pfeiferbit
Copy link

pfeiferbit commented Feb 4, 2018

Perhaps it would be possible for a new feature to allow us to define another keybinding with which we can toggle the other keybinds/swaps on and off.

People might forget pressing that key before starting a game but then ALT-TAB or CTRL-ALT-DELETE may allow you to go to the desktop where the uncap keybindings work normally.

Another very overcomplicated solution could be to define filters for process names/executable paths and when these processes are running (like csgo.exe) to temporarily disable the keybinds/swaps.

Other than that I don't really see a solution. Most games directly talk to the input device drivers themself and not use the abstraction provided by Windows. Of course this will conflict with uncap.

This issue is partly the reason for my uncap setup described here: #1 (comment)

@susam
Copy link
Owner

susam commented Feb 4, 2018

Thank you for reporting the issue in detail.

I understand that the command you have mentioned in this issue, i.e., uncap.exe 0x14:0x1B 0x1B:0x14 0xA2:0xA4 0xA4:0xA2 is supposed to perform the following key swaps:

  • Swap CAPS LOCK with ESC
  • Swap LEFT CONTROL with LEFT MENU (ALT).

Can you help me with the following information so that I can better understand how Uncap behaves in your environment and what could be causing the issue.

  • I understand that these key swaps made with Uncap works properly when you are not playing a video game but these key swaps do not work when a video game is the active application. Am I right?
  • In fact, when you are running the video game, the swapped keys don't function at all, i.e., when you press the Caps Lock key or the Escape key nothing happens. Am I right about this?
  • You have mentioned, "Pressing neither caps lock nor esc brings up the menu." What is the "menu" here that you are talking about? Is it a video game menu? If so, under normal circumstances without Uncap running, which key brings up this "menu" for you? Is it the Escape key that is supposed to bring up the video game menu?
  • Can you kill any Uncap process running in background (uncap -k), stop your video game, then run Uncap in debug mode (uncap -d), press caps lock once, then press escape once, and then copy the debug output presented by Uncap and provide it to me? This output will help me to ensure that Uncap is behaving as expected when the video game is not running.
  • Then kill Uncap again, run your video game now in order to reproduce the issue, run Uncap in debug mode (uncap -d), make your video game the active application, press caps lock once, then press escape once, and then copy the debug output presented by Uncap and provide it to me? This output will help me to understand how Uncap behaves differently when you are running the video game.

@pkubik
Copy link

pkubik commented Sep 22, 2020

The default behavior (change caps-lock to escape) seems to not work with SDL2 key events (and therefore likely indie games). The SDL2 does not detect any event upon pressing the Caps Lock key. Note - no event, not even a scancode is given. I've been using Rust bindings for SDL2 if that changes anything.

Other windowing libraries do not share this issue, e.g. winit-rs. Other solutions, such as AutoHotKey work both with SDL2 and other libraries. This is beyond my knowledge on the keyboard handling.

uncap.exe -d with Caps-Lock pressed 3 times:

KEYUP        0     0 128 -   -   -   -   UP   28  13 (RETURN)
KEYDOWN      0     0   0 -   -   -   -   -    58  20 (0x14)
KEYDOWN      0 35963  16 -   -   INJ -   -     0  27 (0x1B)
KEYUP        0     0 128 -   -   -   -   UP   58  20 (0x14)
KEYUP        0 35963 144 -   -   INJ -   UP    0  27 (0x1B)
KEYDOWN      0     0   0 -   -   -   -   -    58  20 (0x14)
KEYDOWN      0 35963  16 -   -   INJ -   -     0  27 (0x1B)
KEYUP        0     0 128 -   -   -   -   UP   58  20 (0x14)
KEYUP        0 35963 144 -   -   INJ -   UP    0  27 (0x1B)
KEYDOWN      0     0   0 -   -   -   -   -    58  20 (0x14)
KEYDOWN      0 35963  16 -   -   INJ -   -     0  27 (0x1B)
KEYUP        0     0 128 -   -   -   -   UP   58  20 (0x14)
KEYUP        0 35963 144 -   -   INJ -   UP    0  27 (0x1B)
KEYDOWN      0     0   0 -   -   -   -   -    29 162 (0xA2)
KEYDOWN      0     0   0 -   -   -   -   -    46  67 (C)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants