AltGr sending Control_L + Alt_L from client, on a Microsoft Azure VM #1856
Comments
|
AltGr is unfortunately very buggy on Windows. So my guess would be that you are not getting a proper emulation of the Windows behaviour in that Windows VM. How are you accessing the Windows VM? Microsoft's RDP client? A client debug log would be helpful: https://github.com/TigerVNC/tigervnc/wiki/Debug-Logs#client-1 |
|
Hi CendioOssman, The attached logfile was with a session with the following keystrokes: |
|
Oh, I violated some syntax, so it did not come out right: Between each keystroke I hit the return-key, the keys I hit were AltGr + backslash, got nothing, then F12 +backslash, got backslash and the terminal was confused. Last I hit the left Alt-key. |
The TightVNC- and RealVNC-viewers are working OK. Does this mean that they internally translate things differently from how the TigerVNC-viewer does it or do, when they are in use, other keycodes/keysyms come out? Back when collecting a viewer-log for #1818 the RealVNC viewer log showed no keystrokes, as far as I could tell. I will make a log with TightVNC and see if that shows something on keytrokes. |
|
I failed to create a logfile with the TightVNC viewer. The executable has an option -logpath but I wasn't able to get it tp produce a logfile. I created a new logfile from the RealVNC-viewer but like in my previous attempt, I'm not seeng any keytrokes at all in that log. Attaching it here. |
|
The stuff in #1847 and subsequently #1852 looks interesting. If going back to the keyboard-setting used at the time of my submitting #1818 the fix for VK_PACKET may make it work. (with the German keyboard set in Azure I don't see VK_PACKET but I do with the keyboard set to Auto) Unfortunately I don't know how to build from source-code so I'd have to wait for this to get into an update. |
|
Looking at the RealVNCvncviewer.log, two sets of entries like this may explain why that log contains no keystroke info at all: |
Thank you. Unfortunately, the log does show a buggy behaviour from the RDP client you are using. It is not sending AltGr the same way that a "real" Windows machine does. To fix this, we would need to figure out some way to detect this broken behaviour. Nothing obvious in the log on how to do that, though. And it might not be possible. Someone with access to such a system would need to analyse the events more deeply and see if there are any hints. Have you reported this issue to Microsoft/Azure?
They likely use the crude method we also used to have. Unfortunately, that method breaks other use cases. Like pressing Ctrl and AltGr at the same time.
Was this with debug settings, as documented here: |
No, it was with the settings described in the original link above, *:file:100. Seeing some potential in a possible fix to #1847 , I will close this issue and wait for that fix to end up in a new executable. (and just use RealVNC-viewer for now) In parallel I'll try and find some other key than the F12 to use with xmodmap to generate ISO_Level3_Shift. I have not reported to uSoft Azure, thinking they, like IT-support, will suggest to use another viewer instead. |
Author of #1852 here. Figuring out how to build indeed took the majority of the time. I contributed an easier way to build in #1854. If you want to try that, you'd have to merge both PRs locally. |
@MBD62 If you can download keyboa and run |
I have attached four textfiles collected. Two using the RealVNC-viewer and two using the TigerVNC-viewer. One pair with The Azure web-interface keyboard-setting to German and the second pair with that setting to Auto. |
|
Thank you. IIUC, you have collected all four files in the Azure web interface, while running In the German layout cases it looks like you type Based on the above, I would guess that #1852 could solve this in Auto mode. With the German setting however, we need a different workaround. @CendioOssman Three things stands out in the Azure case:
|
@svenssonaxel : Correct, I was mainly trying to type the backslash, (AltGr + ß.) Speaking of FunctionKeys: At an earlier stage I had re-defined my F12 using xmodmap in Linux, to be used instead of AltGr, and that worked fine. (well, not for my muscle-memory so I cheated and went back to the RealVNC-viewer) Last time I tried doing that again though, it was not impressed, there I had probably just made some mistake since it had worked OK before. That would generally suggest that at least F12 does something also in the Azure web-interface. (aka SessionDesktop in Azure-lingo) |
@svenssonaxel : Thanks a lot. I tried the new executable with Azure's Auto-mode and that combo is now on par with the German KB-setting in Azure: Looks like everything works except the AltGr-stuff. (needless to say, new executable + German KB-setting in Azure still behaves the same way) |
|
@MBD62 I have two solution attempts, could you please test them to see if AltGr works? Hopefully it should work in both Auto and German mode. It would also be nice if you could get me a debug printout using this build, in both modes: |
OK, thx. *-debugger-3.exe log-files are attached. Ran with "-Log *:file:100" and renamed the files for identification. |
|
@MBD62 Thank you, please do likewise for this one: |
|
@svenssonaxel thanks. |
|
@MBD62 Attempted a fix, will also produce a log: vncviewer-1856-solution-attempt-5.exe.gz |
@svenssonaxel thanks. |
|
@MBD62 Yeah, it might seem a little complicated because I can't debug myself. Bear with me, please, we're getting close now! |
@svenssonaxel Hm, you need to bear with me and not the other way around;-) You are the one doing the work, which I kindly appreciate. Either way, this looks like a breakthrough: The öäß did not materialize properly with German Azure KB-setting but they do in the Auto-setting. And yes,the backslash works with both settings, as well as the other AltGr-characters. (the attached logfiles still only have the same keystrokes as the earlier files, simply for consistency) I'll start using this version for viewing from now on and see how it plays. I would not bother trying to fix the behavior with the German KB-setting: Having Auto working seems like a better prospect for other keyboards anyway, French or Italian, for example. |
|
Good to hear it partly works now. I've detected a problem releasing AltGr, perhaps that is responsible for no öäß with german setting? Try this one: I'd also like you to try a cleaned up version, without logging. Functionality in your use case should be equivalent: |
|
@svenssonaxel The vncviewer-1856-solution-attempt-7.exe looks like it's doing the same thing as vncviewer-1856-solution-attempt-6.exe did. ( öäß incorrectly interpreted) For me personally, getting it to work with the German KB-setting is not important at all but in case you want to fix that too, I'm of course happy to test out any further attempts. |
|
@svenssonaxel Logfile with German KB-setting is attached, thanks. (in retrospect, I'll test this version with keyboard set to Auto as well, for completeness, I'd update the comment or add a new one only in case of trouble with the Auto setting, while almost certain there won't be any, after a test we will know) Comment edited: KB-setting Auto still works, as expected. |
|
@MBD62 I take it german characters work now? But the log looks like backslash broke instead? Please try this one: Please try to type the string |
@svenssonaxel Unlike previous attempts at German: I did not get any wrong characters displayed, but possible the last few did just not come out. |
@svenssonaxel Thanks. First of all, my apologies for mistyping your string a couple of times in the Attempt10info.txt files. I hope there aren't too many errors which I did not notice. The data shown in the Attempt9info.txt should be OK. If I need to re-do the trial with the 10, let me know. While again collecting the info with the attempt-9-executable, I think I noticed what you were saying, while typing the \ happily shows but it looks like the system does not see all, perhaps it sees every second keystroke or something. |
|
@svenssonaxel I tried .\vncviewer-1856-solution-attempt-7.exe again, German keyboard-setting. CAUTION: In this data ALL characters are typed 10x, not only the , also also ö, ä and : |
|
From |
|
@svenssonaxel What I'm seeing in a few different programs (and mainly also in the Terminal) says something different I think. I'll try and walk through this more methodically tomorrow morning, and attempt to summarize what I'm seeing. This is what it looks like to me though, all with the German keyboard-setting, not Auto:
Plse bear with me, I'll try to come up with a reasonably clean summary tomorrow morning, thanks. |
|
@MBD62 Intriguing, I begin to suspect server-side issues here. From what I can tell in the logs, both german mode, both attempt 9 and 10 send german characters in the same way. Backslash however is different: In attempt 10 it's sent as XK_ISO_Level3_Shift down, XK_backslash down, XK_backslash up, XK_ISO_Level3_Shift up. This seems correct to me, but your server apparently can't handle it. On the other hand in attempt 9 it's sent as XK_ISO_Level3_Shift down, XK_ssharp down, XK_ssharp up, XK_ISO_Level3_Shift up, which should not produce backslash. Perhaps it'd be worth comparing attempt10 with realvnc and get a server-side log from xev for both. |
@svenssonaxel Regarding ISO_Level3_Shift I beg to disagree, or perhaps/probably I'm just not able to cleanly make sense of the directions up/down properly: As I used xmodmap to redefine my F12-key, ISO_Level3_Shift is what I asked for, which is what I believe any receiving program would expect AltGr to actually generate. (A current workaround is to use xmodmap -e "keycode 96 = ISO_Level3_Shift NoSymbol ISO_Level3_Shift" , for example. ) That xmodmap statement makes F12 work as a replacement for AltGr. (but my thumb keeps gravitating downwards, not upwards...) As for comparing with RealVNC: Despite more than one attempt, I've never been able to make RealVNC to place any keystrokes at all in the log, the log from RealVNC does contain some error-messages that to the layman in me suggests that these try to tell me that no keystrokes are recorded. Again, I'm trying to re-visit this tomorrow morning, thanks. |
|
@MBD62 I think we agree on ISO_Level3_Shift, so let me clarify: Both attempt 9 and 10 seem to detect AltGr correctly and send it as ISO_Level3_Shift. I think we agree this is what vncviewer should do? However, when AltGr is held down and you press the ß key, that's supposed to generate keysym XK_backslash. Here, attempt 10 does it correctly while attempt 9 instead generates ß. I would therefore expect attempt 10 to correctly reproduce characters requiring AltGr while attempt 9 not. You report the opposite with 9 working and 10 not. I'm not asking for a client-side log with realvnc. What I'd be interested in, is the output from I'd also be interested in the output of Take your time, no rush! |
I'm starting the viewer in PowerShell to ensure I'm not just clicking the wrong icon, this seems strange. A file with the xmodmap output is attached. Further trials will be done but will come in chunks as I'm unable to carve out a large enough block to try everying in a single go. |
|
@svenssonaxel Some textfiles will be uploaded, hopefully the filenames make sense. Three sets of three files each were captured, two with attempt-10 and one with the RealVNC-viewer. (=REAL in the filenames) The two sets of TigerVNC-viewer files were captured with keyboard set to Auto and to German, the RealVNC-files only with German kb-setting. Each set contains files where I (tried to;-) type the string "aBcÄÖäöß\aBcÄÖäöß\ßa" On a side-note: Just to try something "perhaps more neutral", I proved that a Libre-Office Writer window also receives all the AltGr-characters cleanly in RealVNC and receives nothing with attempt-10. Unless you suggest otherwise, my next step will be to repeat that exercise with attempt-9. |
|
@svenssonaxel trials with attempt-9, TigerVNC-viewer with German and Auto keyboard settings. |
Describe the bug
It looks to me like the TigerVNC viewer sends something different when pressing AltGr than the RealVNC viewer does. (German keyboard)
To Reproduce
Steps to reproduce the behavior:
To reproduce this, a setup with an Azure Windows-VM used for accessing an Azure Linux-VM would be necessary. If trials need to be made, I'd of course be happy to assist but can't grant access to our VMs. The hope is that someone who understands the code, particularly around keyboard-mapping, can figure out what may be going wrong.
Expected behavior
Pressing Alt Gr would be recognized as "ISO_Level3_Shift"
Screenshots
Client (please complete the following information):
Server (please complete the following information):
Additional context
As described in #1818 , typing in general started working when setting the keyboard to "German" instead of "Auto" in the Azure settings. However, anything involving Alt Gr still types nothing. A RealVNC viewer and a TightVNC viewer both work fine in the same setup.
Output of xev in the Linux-session and the Viewer log-file in Windows both agree with the fact that pressing Alt Gr sends Control_L + Alt_L (keycode 37 (keycode 37 (keysym 0xffe3, Control_L) and keycode 64 (keysym 0xffe9, Alt_L). Pressing the left Alt-key sends the same, just without the Control_L: keycode 64 (keysym 0xffe9, Alt_L) The keycode/keysym combos are the same in the Windows viewer logfile as are shown by xev. (suggesting that, for some reason, the viewer is sending the wrong thing?)
A current workaround is to use xmodmap -e "keycode 96 = ISO_Level3_Shift NoSymbol ISO_Level3_Shift" , for example. On my keyboard I then hold down to type the characters requiring Alt Gr. When others use the same VM, who have perhaps Italian or French keyboards, it would have to be figured out what they may have for useable keys to apply xmodmap on so that is suboptimal.
I tried setting the server to use the rawkeyboard option but that does not change the behavior.
Another workaround, of course, could be to use one of the other viewers, but the combo Tiger server and Tiger viewer has its advantages.... Curiously enough, #1715 and #1751 both seem to describe the opposite problem, TigerVNC viewer working fine but other viewers failing.
Any ideas?
thx in advance + best regards / Mats
The text was updated successfully, but these errors were encountered: