[BUG] AltGr still not working

[n0valis]

As in many other threads over the last 10 years I also came across this problem now.

Server Side LMDE6, Xtigervnc v1.12.0, locale de_DE.UTF-8:
X0tigervnc -display :0 -RawKeyboard -rfbport 5900 -passwordfile $pwfile -HostsFile $myhosts

Client Side Win11, RealVNC VNC Viewer, German Keyboard:
Every AltGr-Charater combination not showing

Response from X0tigervnc console at pressing AltGr:
XDesktop: Could not map key event to X11 key code

As sometimes suggested I tried -RawKeyboard as you can see but it makes no difference.
In VNC Viewer SendKeyEvents and SendspecialKeys is set to "true"

Switching to an english keyboard layout on the client side also has no effect.
Special characters like @ or [ ] or | which are invoked with AltGr on a german layout still don't show up.

Would be grate if this could be solved somehow.

Another "bug" is that the copy/paste fuction also doesn't work.

[CendioOssman]

Could you try using our client instead of RealVNC's? It might be a client issue.

In addition, please see if you could try the latest TigerVNC on the server. There could be bug fixes that affect your setup in the latest versions.

[n0valis]

With your client it works for the AltGr problem, not for the copy/paste problem.
It also changed the display resolution of the host system.
So this is probably it, it will only work if I use your client? Which is not really an option for me.

[CendioOssman]

We try to be compatible with all VNC clients. But we might not be able to compensate for bugs in them. And they might not support all the features we have. E.g. RealVNC does not support raw keyboard.

Could you please add the argument -Log *:stderr:100 to the X0tigervnc command line and let us know what it logs when you press the problematic keys with the RealVNC client.

I also missed which of our servers you were using. X0tigervnc unfortuantely doesn't support clipboard yet. See #529.

[n0valis]

I wouldn't call it a bug if a client doesn't support your features. More like an incompatibility. The question is what does the client send and what does the server make of it. Here is what I send with AltGr:

Log:

VNCSConnST:  Key pressed: 0xffe3 / 0x0
XDesktop:    37 down
VNCSConnST:  Key pressed: 0xffea / 0x0
 XDesktop:    Could not map key event to X11 key code
 VNCSConnST:  Key released: 0xffe3 / 0x0
 XDesktop:    37 up
 VNCSConnST:  Key released: 0xffea / 0x0
 XDesktop:    Could not map key event to X11 key code

and here how Ctrl Alt (left) looks like:

VNCSConnST:  Key pressed: 0xffe3 / 0x0
 XDesktop:    37 down
 VNCSConnST:  Key pressed: 0xffe3 / 0x0
 XDesktop:    37 down
 VNCSConnST:  Key pressed: 0xffe9 / 0x0
 XDesktop:    64 down
 VNCSConnST:  Key released: 0xffe9 / 0x0
 XDesktop:    64 up
Thu Jan 11 12:36:51 2024
 VNCSConnST:  Key released: 0xffe3 / 0x0
 XDesktop:    37 up

[CendioOssman]

Unfortunately, those logs show that RealVNC's client is not sending AltGr, but rather Ctrl+Alt. This is a common issue for Windows, but TigerVNC has no idea if this is a "real" Ctrl and Alt being pressed or not. So it has to trust the client. Assuming Ctrl+Alt means AltGr would likely break other clients.

The reason you get the warning from x0vncserver is that the loaded layout doesn't have a right Alt, since it has the AltGr key in that spot.

Xvnc has some magic that tries to make things work even if the client and server layout doesn't match, but that magic has not yet been ported to x0vncserver. Please follow #528 for that.

[n0valis]

I don't think that is correct. That's why I send you the (Left) Ctrl+Alt keys too. The first example is AltGr.
SO:
It is 0xffe3 (Control_L) + 0xffea (Alt_R) vs. 0xffe3 (Control_L)+ 0xffe9 (Alt_L)
With this it is clearly distinguishable.
Meaning, the server doesn't know 0xffea
XDesktop: Could not map key event to X11 key code

[CendioOssman]

But users are fully free to press the right Alt. We can't assume that it is really AltGr, as that is only the case for some layouts.

[n0valis]

So you go away now from saying "The reason you get the warning from x0vncserver is that the loaded layout doesn't have a right Alt, since it has the AltGr key in that spot." to "users are fully free to press the right Alt". With all due respect, but your arguments are getting a bit squishy.

It is not about right Alt. It is about the combination 0xffe3 (Control_L) + 0xffea (Alt_R)
which only pressed together equals AltGr. It should be possible to meet this.

[CendioOssman]

But how would we tell the difference between a client with a German layout pressing AltGr, and a client with an American layout pressing Control_L and Alt_R? We have no information about the client's layout, we only see the keys pressed.

[n0valis]

I don't know. I am no expert. Maybe if a locale is set in client settings you can evaluate that. RealVNC has such a parameter which can be set. But I don't know if that is of any value. You could also evaluate locale settings on the host system (Linux) and act accordingly. So if it is set to de_DE assume AltGr is pressed.

For Windows it is basically the same.
For Example: I have a keyboard shortcut here on my Windows system AltGr+x. But function also triggers if I press left Ctrl+Alt+x.
Maybe on Linux something similar can be achieved.
Maybe it'll be enough to just pass along Control_L and Alt_R.
At least "Could not map key event to X11 key code" could produce some meaningfull output. It indicates that at the moment Alt_R isn't even recognized which makes your question a bit questionable.

[CendioOssman]

I'm afraid the client doesn't share any such details with the server. VNC is very much designed around following the client layout. We might be able to add some hacks and guess when the client isn't truthful with us, but that would be very fragile and likely confusing in many cases.

What we've done to resolve this is adding "raw keyboard" mode, but it requires a compatible client, or trying to figure out how to get what the client is requesting even with a layout mismatch, but that feature is not in x0vncserver yet (#528).

I'm afraid your only realistic option presently is switching clients, or filing a bug with RealVNC and see if they can fix their client. No one is currently working on #528, and I'm not even sure if it will fully resolve this issue, as Ctrl+Alt is not the same thing as AltGr on Linux.

[CendioOssman]

We also have the RemapKeys setting. It's rarely used, and I'm not sure what the original purpose was. But it might be useful here. If you specify -RemapKeys 0xffea<>0xfe03 then you might get the switch you want.

[n0valis]

Ok I give up. I still don't see where RealVNC produces a bug and x0vncserver does not by not recognizing ALT_R.

And btw I use RealVNC client on several Raspi/Debian systems with tigervncserver and there is no such problem.
Same client, (slightly) different server. But still you blame the client. I don't know how tigervncserver and x0vncserver are connected or not, but you might want to have a look into their code to get this sorted out. It seems pretty straight forward to me. But maybe I am just naiive.

[n0valis]

update:
I tested on the Raspberries:
AltGr is sending Ctrl-ALt (left) and because of this it is working.
Those symbols like like @, €, ~, [ ] etc. are also normally accessible via Ctrl-Alt (left)
And that doesn't work either with X0vncserver, but it should