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

Custom backspace buttons on windows language don't work. #1463

Open
columna1 opened this issue Mar 15, 2018 · 14 comments
Open

Custom backspace buttons on windows language don't work. #1463

columna1 opened this issue Mar 15, 2018 · 14 comments
Assignees
Labels
area:input priority:2 Moderately important. Relied on by some users or impeding the usability of the framework

Comments

@columna1
Copy link
Contributor

columna1 commented Mar 15, 2018

#2216 posted here as it's a framework issue.

I use a keyboard layout called Colemak which maps the caps lock button to backspace. This backspace doesn't work for me using the windows language feature to switch layouts.

I haven't tried with other buttons mapped to backspace, just the caps lock button
To reproduce:
either create a new layout with msklc
https://forum.colemak.com/topic/870-hacked-msklc-to-enable-remapping-capslock/
or download and install the layout and switch to it from the language menu
https://forum.colemak.com/topic/1621-colemak-for-windows-with-capslock-to-backspace/
and then try to use the backspace.

@peppy peppy added this to the Candidate Issues milestone Mar 18, 2018
@FreezyLemon
Copy link
Contributor

See opentk/opentk#666. If I understand this correctly, OpenTK currently uses the physical key location (aka "scancodes") instead of what you set your OS to do with the key (aka windows "virtual key"), so it'll always see the physical keys like they would be used on a US QWERTY keyboard.

@peppy peppy removed this from the Candidate Issues milestone Mar 17, 2020
@yellowsink
Copy link

Occurs for me on Linux too.

@peppy
Copy link
Member

peppy commented Jan 4, 2022

We've actually done a lot of work surrounding key input and key codes, to the point I'd wager that the original issue has been fixed (needs confirmation).

@yellowsink can you give more details about your setup to cause issue?

@columna1
Copy link
Contributor Author

columna1 commented Jan 4, 2022

@ppy
I can confirm this is still an issue on windows and linux.
Tested with latest osu!lazer build 2021.1225.0-lazer under windows 11 with same repro as original post. Still same issue.
Can also confirm that this is an issue under arch linux as well. Under both xorg11 and wayland (which might be xwayland)
To reproduce: Set keyboard layout to colemak
Issue command:
setxkbmap us -variant colemak under x11
Under wayland it depends on the compositor but under swaywm you put this into your config file

input * {
	xkb_layout "us"
	xkb_variant "colemak"
}

Under all cases Capslock does not work as a backspace in osu!lazer where it does work most if not everywhere under the respective OS/environments

@peppy peppy added the priority:2 Moderately important. Relied on by some users or impeding the usability of the framework label Jan 4, 2022
@Susko3
Copy link
Member

Susko3 commented Jan 4, 2022

If you map Capslock in osu! keybind settings, does it show up as Capslock (Caps) or Backspace (BackSp)?

Please test on Windows and Linux, if possible.

@columna1
Copy link
Contributor Author

columna1 commented Jan 4, 2022

@Susko3
On linux it shows up as BACKSP (x11 vs wayland doesn't matter)
On windows it shows up as CAPS

@yellowsink
Copy link

yellowsink commented Jan 4, 2022

We've actually done a lot of work surrounding key input and key codes, to the point I'd wager that the original issue has been fixed (needs confirmation).

@yellowsink can you give more details about your setup to cause issue?

@columna1 has said pretty much all I was going to say. I am running i3wm, but have experienced this in sway too. Also I use Colemak as my primary layout - with the built in setxkbmap colemak us variant.

@Susko3
Copy link
Member

Susko3 commented Jan 5, 2022

On linux it shows up as BACKSP (x11 vs wayland doesn't matter)
On windows it shows up as CAPS

Done a bit of digging, and SDL currently doesn't play nice with remapped non-letter keys on windows. It simply ignores the keymap (relavent code).

We currently use scancodes to map keys, so caps lock key is always treated as caps lock internally in the framework.
Switching to keycodes would solve this (at least on Linux). But we must be careful, as keycodes can be any unicode character.

For most of the hotkeys it does make sense to use keycodes (eg. Ctrl+Z - every keyboard layout has a Z somewhere). But for others using a scancode makes more sense (eg. Ctrl++ - not every keyboard has a plus key, some have it in shifted state).

Using physical key position (scancodes) also makes sense for default bindings for gameplay osu!-side.
But again, Ctrl+D for direct might not always be a D key.

Not really sure what's the best way to proceed here.

Also relevant: ppy/osu#11143.

@bdach
Copy link
Collaborator

bdach commented Jan 5, 2022

Also relevant: #3950

@Susko3 Susko3 self-assigned this Jun 18, 2023
@Susko3
Copy link
Member

Susko3 commented Jun 18, 2023

@columna1 @yellowsink Could you test this again, but with extended logging enabled:

  1. Set envvar SDL_EVENT_LOGGING=1 (applies to linux and windows)
  2. Run the game
  3. Press caps lock (your backspace) a few times, do it while a textbox is focused and not focused
  4. Close the game and upload the full runtime.log (you should see some lines with SDL EVENT: SDL_KEYUP/KEYDOWN)

@columna1
Copy link
Contributor Author

columna1 commented Jun 18, 2023

@Susko3 Arch linux wayland (wlroots/labwc)
runtime.log

@Susko3
Copy link
Member

Susko3 commented Jun 19, 2023

Relevant log entry:

SDL EVENT: SDL_KEYDOWN (timestamp=17098 windowid=1 state=pressed repeat=false scancode=57 keycode=8 mod=0)

scancode=57 is SDL_SCANCODE_CAPSLOCK
keycode=8 is SDLK_BACKSPACE

Thanks, what I have in mind for the fix should work for you.

If you're able to, please also test on windows.

@columna1
Copy link
Contributor Author

If you're able to, please also test on windows.

I no longer have a dual boot/windows machine however I do have a windows 11 VM. and this is what I get:
runtime.log
Relevant lines seem to be:

2023-06-19 15:36:54 [verbose]: SDL application log [info]: SDL EVENT: SDL_KEYDOWN (timestamp=24591 windowid=1 state=pressed repeat=false scancode=57 keycode=1073741881 mod=8192)
2023-06-19 15:36:54 [verbose]: SDL application log [info]: SDL EVENT: SDL_KEYUP (timestamp=24651 windowid=1 state=released repeat=false scancode=57 keycode=1073741881 mod=8192)
2023-06-19 15:36:54 [verbose]: SDL application log [info]: SDL EVENT: SDL_KEYDOWN (timestamp=24736 windowid=1 state=pressed repeat=false scancode=57 keycode=1073741881 mod=0)
2023-06-19 15:36:54 [verbose]: SDL application log [info]: SDL EVENT: SDL_KEYUP (timestamp=24794 windowid=1 state=released repeat=false scancode=57 keycode=1073741881 mod=0)

I include 4 lines because it seems to flip the mod state as well

@Susko3
Copy link
Member

Susko3 commented Jun 19, 2023

Thanks for the logs, unfortunately this won't work on windows. I'll report to upstream. In the meantime, remapping with PowerToys Keyboard Manager will work.

scancode=57 is SDL_SCANCODE_CAPSLOCK
keycode=1073741881 is SDLK_CAPSLOCK

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area:input priority:2 Moderately important. Relied on by some users or impeding the usability of the framework
Projects
None yet
Development

No branches or pull requests

6 participants