Improve unknown keysym handling by reusing keycodes

[gujjwal00]

This is still a work in progress, but I am kinda stuck on how to handle Xvnc. Atleast x0vncserver works correctly. As proposed in #93 (comment), when all free keys has been used, it will start reusing the oldest key assigned by TigerVNC.

For Xvnc, I have tried a few things:

• Tried to compile common source files as part of Xvnc. But internal xserver header files don't seem to be compatible with C++. This also complicates the build process even more as the common header file needs to know if it is being compiled with Xvnc or x0vncserver.
• Tried to separate server specific parts to something like InputGlue.h. This can work, but becomes very clunky. Control flow will be Xvnc/x0vncserver => common code => glue code in Xvnc/x0vncserver => and back again.
• We could of course implement this separately in Xvnc & x0vncserver, without worrying too much about duplication. (I would still like to keep the custom key list in common to avoid having to implement a linked list in Xvnc.)

Issue: #93

[gujjwal00]

I have added separate implementations for x0vnceserver & xvnc.

Trying to share this piece of code creates too many problems because both servers are using different headers, different way of getting/updating keymaps, and different build systems.

[CendioOssman]

Sorry for the huge delay reviewing this.

I think this looks reasonable, but I haven't done any actual testing yet.

Clever using the naming to track our modified keys. :)
Have you checked that the naming resets when you modiify the keyboard layout using other tools?

[gujjwal00]

Re-based onto latest master branch.

Have you checked that the naming resets when you modiify the keyboard layout using other tools?

Yes, changing layout via setxkbmap will reset the naming. Basically, any operation which triggers reload of XKB configuration from disk will reset in-memory changes done by Tigervnc. Please note that in case of multi-layout configuration, fast layout switching via key shortcut doesn't reload the configuration from disk, it only changes the active group. But its not an issue here because Tigervnc only modifies unused keys.

[gujjwal00]

Also, only Xvnc assigns key name to added keys. x0vncserver simply updates the keysym. But if needed, same approach could be used in x0vncserver too.

[CendioOssman]

Finally got around to testing this. It works very well. Nice work! :)

Also, only Xvnc assigns key name to added keys. x0vncserver simply updates the keysym. But if needed, same approach could be used in x0vncserver too.

That would be nice if you have the time. It's not a blocker for this work, though, so I'll go ahead and merge what we have.