Arrow and space keys don’t work in version 8.4.2

[hpb]

Updated to NoMachine 8.4.2 for iOS under iOS 16.3.1.  Logged onto Raspberry Pi.  In the terminal program, arrow keys and space key doesn’t work.  By “don’t work” I mean that hitting them doesn’t do anything.  In fact, when trying to add a new connection in NoMachine, space bar does not work when trying to add the name of a new connection.

[Tor]

Hi! What is your iOS device model? Do you use the virtual keyboard, or an hardware keyboard connected to the device through bluetooth?

[hpb]

I am using an iPad Air (5th generation) with an Apple Magic keyboard.  This keyboard connects to the iPad through three connectors on the back of the iPad.  Space and arrow do work with the virtual keyboard, but that is not nearly as convenient as using the Magic keyboard and exactly why I bought the Magic keyboard.

[Tor]

Perfectly clear, thanks. We’re doing some checks in our labs, I’ll update this thread soon.

[NebulaBC]

I’m also experiencing this issue. Space works for me, but arrows and all non-character input keys don’t work. I’m on an iPad 10 with a Logitech Combo Touch (pretty much a clone of the apple keyboard, so there shouldn’t be any difference software side)

My guess at why these issues are happening would probably be because NoMachine isn’t just taking direct keyboard inputs and forwarding them, but instead it’s trying to bring up the on screen keyboard and then that’s turning into the text input mode for a physical keyboard (it even shows the autocorrect/password bar). I’m kind of disappointed that the keyboard support isn’t better in the latest version, but hopefully that can be remedied with a future update.

[Tor]

We identified the issue and rolled out a new version for an internal testing, so far everything is working as expected. We’re implementing other changes too, so I don’t expect a new version to be published before next week.

@hpb can you confirm the ‘space’ works correctly with other 3rd party apps, please? Compared to other keys, the ‘space’ is received as-is and there is nothing special to do to forward it.

@NebulaBC the problem is a bit more complex, caused by an internal condition clearing out a bit in a mask, and bypassing the definition of the key commands needed by the responder object. I’m sorry we didn’t notice it during our tests.

There is a workaround you could try. The bug is not triggered if you avoid to activate input fields before the client connects to the remote desktop, so store username and password in the connection and don’t tap any input fields until you see the desktop. Let me know if this helps (on one of our devices the workaround didn’t… work around! 🙂 We’re still analyzing the reason).

[cj1171]

@NebulaBC noticed the same behavior with my Combo Touch attached.

[Author]

Posts