Hi, > Hum.. Now, I encountered this situation that the common clienteles just use > tightvnc client, but want to change keymap dynamically. As you say, > the only way address this scenario is doing it on the server side. So, > do you think this patch series make sense and consider to accept it > in upstream? Thanks!
The alternatives are: * Try figure why they are using tightvnc. Do they simply don't know there are other vnc clients such as remote-viewer with much better keyboard support? Did they try other clients and want stick to tightvnc nevertheless? If so, what are the reasons? * Try add raw scancode extension support to tightvnc (or the http://tigervnc.org/ fork). I see server-side keymap switching as last ressort if all other approaches failed, simply because the manual keymap configuration needed on the server side is error-prone and a pretty bad user experience. cheers, Gerd
