Some keys not working properly in debug session

[Torsten Kupke]

Hi,

I'm a software developer using Qt Creator under Ubuntu. Since the recent
upgrade to Ubuntu 22.04 and installing TVNC 3.1 I have the problem,
that, when debugging my code with gdb in Qt Creator, that some keys
don't work as usual. For some details see
https://forum.qt.io/topic/153654/some-keys-not-working-properly-in-debug-session!
Now I detected, that this only happens, when working from home (under
Windows 10) using the TVNC client 3.1 (which is Java). When I work
locally on my workstation, also with the Java TVNC client 3.1 connected
to the same TVNC server running locally, all keys work as desired. What
could be the reason for this problem, and is it fixable in any way?

BR

tkansgar

[DRC]

TurboVNC 3.1 introduced server-side key mapping, whereby the viewer
sends raw scan codes to the server and the server translates those into
X11 keysyms based on the key map that is active in the TurboVNC
session.  Thus, the key map in the TurboVNC session now matters, and the
key map on the client no longer matters.  Make sure that the correct key
map is set in the TurboVNC session.

[Torsten Kupke]

Hi DRC,

but how could a wrong key mapping be responsible for the fact, that only
each second pressing of F10 is passed to the debugger, and that I have
to click into the window to make F5 or Shift+F11 working (although the
cursor is blinking there already), when I had pressed F10 before? That
seems to be not logical. Can I do something to clarify this? Is it
possible to log the scan codes and the translated keysyms on server side?

BR

tkansgar

[DRC]

It's really hard to track all of the relevant information across
multiple simultaneous bug reports from multiple people on a mailing
list.  In the future, if you have multiple issues to report, it would be
better to file GitHub issues for each.  In particular, the other thread
regarding bump scrolling provided a critical piece of information for
this thread, which is that you were previously using the native Windows
TurboVNC Viewer.  Thus, this issue isn't a function of the server-side
key mapping feature that was introduced in TurboVNC 3.1.  It's a
function of the unified Java TurboVNC Viewer that was introduced in
TurboVNC 3.0.  More specifically, at some point Windows 10 apparently
started hijacking the F10 key for its own purposes.  I'm not sure when
that happened, because I certainly tested all possible keystrokes quite
thoroughly when I integrated/implemented the server-side key mapping
feature.  So it must be a recent thing. I am investigating how to work
around it.

Your report here
https://forum.qt.io/topic/153654/some-keys-not-working-properly-in-debug-session
is not entirely accurate.  It seems as if F10 is the only actual issue. 
F5 and Shift-F11 work fine in isolation.  They only stop working because
F10 changes the window focus.

DRC

[DRC]

Should be fixed in the latest pre-release builds:

https://turbovnc.org/DeveloperInfo/PreReleases

This was a similar issue to

https://github.com/TurboVNC/turbovnc/issues/349

Apparently Windows 10 started hijacking F10 for the same purpose as left
Alt at some point.  Note that Windows 10 has done that sort of thing
before.  The 1903 update started hijacking Ctrl-Alt-Shift-F without
notice or documentation, then the 20H2 update stopped doing it
(https://github.com/TurboVNC/turbovnc/issues/193.)  At least they
bothered to document their use of the keystroke this time
(https://support.microsoft.com/en-us/windows/keyboard-shortcuts-in-apps-139014e7-177b-d1f3-eb2e-7298b2599a34),
but I swear that F10 wasn't used by Windows as of a year ago.

DRC

[Torsten Kupke]

Great! Will this fix be in the next official release of TurboVNC? Then I
would wait for it.

I didn't notice yet, that my Windows grabs F10. I really thought, that
the issue happens inside the TVNC session.

Many thanks again for your valuable work!

[DRC]

Of course I would not push a commit to a Stable Active branch of our
GitHub repository unless I intended to eventually release it. (Please
refer to this article https://turbovnc.org/DeveloperInfo/Versioning for
more information on how our git branches correspond to TurboVNC release
series.)

However, if you report a bug, then it is your responsibility to test the
proposed fix ASAP so that I have independent verification that the bug
is fixed from the point of view of the reporter. This needs to happen
*before* the proposed fix is officially released.  Otherwise, I could
release the proposed fix, but maybe for whatever reason it doesn't fix
the issue from your point of view.  (That has happened before.)

[Torsten Kupke]

Ok, ok, I didn't want to force you to provide a new official release
with this fix. It was only, because I normally reluctantly use any
prerelease versions for working. But now I did it to be able to give you
feedback.

Short answer: Yes, the issue is fixed in this version!

Long answer: Before installing the prerelease I verified, that Windows
transfers the focus to some element of the local window, when pressing
F10 (which I could not notice in fullscreen mode). More precisely, when
pressing F10 without fullscreen mode, the first reaction happened inside
the TVNC session. But directly after this reaction pressing a key like
cursor-down was handled by the Windows system menu normally accessed
through the icon in the upper left window corner. So, yes, I could
reproduce, what you detected. After installing TurboVNC 3.1.1 (the
prerelease) this behaviour is gone. Each pressing of F10 (or
cursor-down) leads to an expected reaction inside the TVNC session. So I
now think of keeping this version, until you publish a new official
release. And no, I don't want to force you to do this soon. Sorry for
this misunderstanding!

[DRC]

I would never do an official release for one bug fix unless it was
really critical.  However, the 3.1.1 release is overdue, and there are
already enough bug fixes to justify it.  Thus, I am trying to resolve
all outstanding issues in preparation for it.

Thank you for testing.