Virtual keybord cursor gets stuck in 0.26

[Tasosgemah]

Sometimes when i enter the virtual keyboard and move the arrow/cursor with the analog stick to select which key to press, the arrow/cursor gets stuck and doesn't move left or right (but still moves up and down). As if it hits an invisible barrier.

It's completely random. I think it happens mostly when i'm pushing the analog all way through.

This didn't happen in version 0.25.

[PoloniumRain]

I reported this in #159. It's been a problem since way before 0.25, but for me it mostly happens when moving up and down.

At first i thought maybe it had something to do with analog stick sensitivity, where each stick was interfering with each other, but even if i increase the DBP analog deadzones setting to 40% it still happens. But i've found a way to reliably replicate the problem (for me at least)...

1. Get the on-screen keyboard up.
2. Immediately move the right analog stick up. It's need to be moved exactly upwards, not slightly to the side.

[Aidorin0]

I'm also facing this issue, but only in PC, in Android it works fine (I'm using 0.9.7 in both PC and Android). The walkaround I found to 'fix' it in PC is to move the arrow/cursor with the two sticks of my controller at the same time and in the same direction. Then the cursor does not get stuck. So... the issue seems related to a conflict between one stick moving but not the other stick. The walkaround 'fix' works fine, but it would be nice a better solution.

Being said the above, I also must say that I love this core and that it works really fine.

[PoloniumRain]

I've finally found the cause of this problem...

@schellingb It's related to the analog stick deadzone. At first i thought it couldn't be this because changing the deadzone setting in the DOSBox Pure core settings didn't fix this issue, but that's because the core deadzone setting is not being applied to the on-screen keyboard cursor. You can test this by setting the core deadzone to the maximum 40%, but still the most tiny stick movement will move the cursor, so the core deadzone setting is obviously not being applied to the cursor (EDIT: The deadzone setting actually works in 0.9.7 but no longer works in 0.9.8).

But RetroArch has its own deadzone setting (Settings > Input > Analog Deadzone). If you also set this to 0.4 (40%) the cursor will no longer get stuck.

So i think by default the cursor needs to have something like a 10% deadzone setting, and then if the core deadzone setting is higher than this, then that will be applied to the cursor instead. This would also stop the cursor from moving on it's own with controllers that have particularly bad stick drift.

But you can still make the cursor get stuck if you just move it around the screen and quickly flick the second stick (in any direction). So to entirely fix this, the cursor should ignore multiple inputs so it only works with one stick at a time.

[schellingb]

If RetroArch has a deadzone setting, does the core still need one?

[PoloniumRain]

The problem with the RA deadzone setting is that it's disabled by default. I think most people will forget to enable it and have no idea that this issue is deadzone related anyway.

And i much prefer how you implemented the deadzone setting because it allows for more fine control in 5% increments, where as RA only has 10% increments. For most of my controllers 5% is ideal.

[schellingb]

The dead zone setting getting applied to movement for the cursor of the on-screen keyboard. This has not changed in 0.9.8.

[PoloniumRain]

You're right and the problem was because i was using the D3D11 video setting in RetroArch. I then tried GL and the deadzone setting worked, but then i switched back to D3D11 and.... it now works. Wtf?

No idea how to replicate this problem... I know it wasn't the DOSBox-pure.opt file that was stopping the deadzone from working, and it works with a separate clean RA install as well. So i'm pretty sure it's not a DBP related problem. I suppose this issue can be closed?