Ctrl+o not working with ctrl and caps swapped

[lfpraca]

Type

Other

Bug description

In one of these 3 commits: 298989f, e68ba63, a9ba16a a change was made that made Ctrl+o stop working if the Ctrl and Caps Lock keys are swapped. Before these 3 commits, the behaviour was as expected, the physical Caps Lock key mapped to the Ctrl key registered as the Ctrl key in osu!, but it seems to not be registered in the game at all after these commits, neither as Ctrl or Caps Lock.

Additional information: In the logs there is an additional tablet error that is just due to the wacom kernel module being active. This is not an issue at all and has no relation to this issue I am filing.

Screenshots or videos

No response

Version

a9ba16a

Logs

database.log
input.log
network.log
performance.log
runtime.log

[peppy]

Please add any more information to the discussion thread (#23893). There's no need to make further issues at this point.

[lfpraca]

I understand if this issue is too niche to be looked at at this point, but it is definitely an issue. I built the game commit by commit to try to figure out the problem, due to the build failing on some commits, I could only narrow it down to 3, not one in particular. But this allowed me to confirm that this problem is somewhere within the game itself. The game files, the system configuration, everything else is exactly the same both when it did and when it did not work.

If it is indeed the case that this is not important enough right now, I would appreciate if you could point me in some direction in the codebase where something like this could be handled so that I can try to fix it myself and submit a PR

[bdach]

@lfpraca I assume you're testing with setxkbmap -option "ctrl:swapcaps", yes?

The commits you provide as suspect make no sense. The actual point of regression seems to be 3df0eea. Which contained a framework bump, which contained an SDL2 bump, which is most likely to be the cause of the issue you're experiencing here. And the PR that "broke" it is likely to be libsdl-org/SDL#7552.

That said, upstream is not necessarily at fault here, and in fact the new behaviour is more likely to be correct with what scancodes are supposed to be. The actual root of the problem here is closer to ppy/osu-framework#5790.

[lfpraca]

1. Yes, this is correct.

2. I've been doing some more digging and it is indeed something that came from osu.Framework.

I don't really understand how this can be possible but locally, the change from version 2023.513.0 to 2023.521.0 happened in commit 298989f , even though there is no change at all in osu.Game.csproj on this commit when inspecting in GitHub.

3. If I understand your last point correctly, I think you mean that it would be more correct for the keys to be unswitched. I do understand that but the behaviour, as of now, is that Caps Lock works normally while Ctrl doesn't work at all.

Anyway, I will wait for a new version to be released with the changes in this pull request. In the event that it is something else, now I have better idea of where to look. Thank you for the response.

[bdach]

If I understand your last point correctly, I think you mean that it would be more correct for the keys to be unswitched

That is not quite what I said. It is more correct for SDL to not switch scan codes of modifiers around, since the point of scan codes is to identify this one concrete physical key that is being pressed (rather than what the key means). For what you want to achieve, we're using scan codes incorrectly in the game, which is supposed to get resolved with the pull request that I linked.