BizHawk icon indicating copy to clipboard operation
BizHawk copied to clipboard

Don't send key release events with modifiers

Open Morilli opened this issue 2 years ago • 8 comments

This would close #3327. As I've written in that issue thread, the main problem seems to be the fact that key release events were sent with their respective modifier, aka when holding e.g. Ctrl+C and releasing C, a Release:Ctrl+C event would be generated which also happned to release the Ctrl key, even though that was still pressed.

The comments and code which I've removed seem to imply that this functionality was (more or less) intended and had a use case, although in my testing I couldn't figure out an issue with removing it; @zeromus do you recall the specific reason this code was needed?

Morilli avatar Oct 02 '22 08:10 Morilli

Without even thinking about it or checking the code, it seems obvious to me that inputs and bindings connected to e.g. Ctrl+C need to receive a PRESS and RELEASE both or else they'll malfunction. "Release:Ctrl+C event would be generated which also happened to release the Ctrl key" sounds like a bug to be solved directly.

zeromus avatar Oct 02 '22 18:10 zeromus

Hm, you're probably right about that. I couldn't find the exact place where that input event was handled though.

Morilli avatar Oct 03 '22 03:10 Morilli

I believe https://github.com/TASEmulators/BizHawk/blob/5c59e6d9c4d56583f5818fbacc24f01d579f78ac/src/BizHawk.Client.Common/input/InputCoalescerControllers.cs#L30-L34 would be the cause of this issue.

CasualPokePlayer avatar Oct 04 '22 02:10 CasualPokePlayer

commit 726f1f3f112e9b8947f1b35ea659717604bfdd31 seems considerably different, where it had this before; unclear why a MOVE CODE commit had to be a CHANGE ALGORITHM commit also at the same time

var releases = Buttons.Where((kvp) => kvp.Key.Contains("+") && kvp.Key.EndsWith(ie.LogicalButton.Button)).ToArray();
foreach (var kvp in releases)
	Buttons[kvp.Key] = false;

zeromus avatar Oct 04 '22 03:10 zeromus

You're comparing different code blocks; the matching block before the move is: https://github.com/TASEmulators/BizHawk/blob/25da1153b69a25ba9bac21ccf394a8f439640536/src/BizHawk.Client.EmuHawk/Input/Input.cs#L43-L51 And after: https://github.com/TASEmulators/BizHawk/blob/5c59e6d9c4d56583f5818fbacc24f01d579f78ac/src/BizHawk.Client.Common/input/InputCoalescerControllers.cs#L32-L33

YoshiRulz avatar Oct 04 '22 03:10 YoshiRulz

Another thing I guess to note (logging events enqueued here https://github.com/TASEmulators/BizHawk/blob/aa708992e93b35d936035d8956cc679c18f32392/src/BizHawk.Client.EmuHawk/Input/Input.cs#L292 on c547a20f8e747fcdf70a678f12e733a54b36c3d2):

Doing hold Ctrl hold M spam unpress/press M

Press:Ctrl
Press:Ctrl+M
Release:Ctrl+M
Press:Ctrl+M
Release:Ctrl+M

Doing hold Ctrl hold M spam unpress/press Ctrl

Press:Ctrl
Press:Ctrl+M
Release:Ctrl
Press:Ctrl
Release:Ctrl

Something seems wrong here.

CasualPokePlayer avatar Oct 04 '22 04:10 CasualPokePlayer

The first log doesn't cause Ctrl to be released. So the original problem isn't happening. Thats strange...

The second log seems wrong.. ctrl+M should be released... but that's the only problem I see.

zeromus avatar Oct 04 '22 06:10 zeromus

The first log would have the "original problem" (or well #3327) since the ProcessSubsets will eventually interpret that as unpressing both Ctrl and M. The second would probably not have any issues per se. But it does seem to indicate the logic this PR touches doesn't seem to function correctly entirely anyways.

CasualPokePlayer avatar Oct 04 '22 08:10 CasualPokePlayer

Not sure if directly related, but I wanted to understand the logic further: What should happen in the case that Ctrl is held and M is pressed? I get that a Ctrl+M event is generated, and I believe this also counts as a press for M alone, right? Or is this dependent on whether a hotkey is registered for Ctrl+M or not?

Morilli avatar Oct 13 '22 10:10 Morilli

Okay, how about this current logic? It should behave correctly in all scenarios, even ones which weren't handled correctly (I hope) before.

For example, for Hold Ctrl, Hold E, Release Ctrl, E will still count as pressed, but Ctrl+E won't, whereas it did before. Similarly, for Hold Ctrl, Hold E, Release E, Ctrl will still count as pressed while Ctrl+E will not.

Morilli avatar Oct 18 '22 17:10 Morilli

Testing this, Hold Ctrl+Z -> Release Ctrl -> Hold Ctrl results in only Z recognized as pressed.

CasualPokePlayer avatar Nov 24 '22 23:11 CasualPokePlayer

Testing this, Hold Ctrl+Z -> Release Ctrl -> Hold Ctrl results in only Z recognized as pressed.

That is intentional; after all, holding Z and pressing Ctrl does currently not consider Ctrl+Z as pressed either.

Morilli avatar Nov 24 '22 23:11 Morilli

Ah, testing it further and it seems Ctrl and Z are at least consider pressed, but not Ctrl+Z. I guess practically it doesn't matter so much.

CasualPokePlayer avatar Nov 25 '22 00:11 CasualPokePlayer

Holding Shift then holding Z still results in keybinds for Shift alone being released.

YoshiRulz avatar Nov 25 '22 06:11 YoshiRulz

Holding Shift then holding Z still results in keybinds for Shift alone being released.

I can't replicate this in my testing, where are you seeing this?

Morilli avatar Nov 25 '22 07:11 Morilli

~~https://youtu.be/4j6s4_dHiQo~~ NEVERMIND I FORGOR U+D DISALLOWED I expect

keydown Shift
#=> U
keydown Z
#=> UDL

but see

keydown Shift
#=> U
keydown Z
#=> DL

YoshiRulz avatar Nov 25 '22 08:11 YoshiRulz