I sometimes handle virtual-machines in VMware vCloud Director console or in Digital Ocean web console. Both work in browsers. I have also managed some RSA adapters on IBM servers which use Java plug-in in web-browser. The problem is, that often various key-presses(for example Ctrl+k)/characters(for example Shift+7) do not reach the (virtual) server or (virtual) server receives false keycodes and one needs to use onscreen keyboard in virtual server if this is available. I guess there is no workaround and it depends solely on the developer of this web-based console or even the operating system where browser runs?

  • Dunno if it will help, but there might be some useful information in Chrome's hterm/SSH app's README. With a Chrome browser you can open a tab/app in a separate window with More tools > Create application shortcuts and in the separate popouts that result the regularly intercepted browser shortcuts are passed through to the application. I dunno how/if that would apply to Firefox, though. – mikeserv Jun 29 '15 at 8:41
  • Have you tried echo -e and then designating the actual character that you want to send to the terminal? echo -e '\07' for sending an ascii bell to the terminal for example. This would simulate a CTRL-g – 111--- Jun 30 '15 at 20:12

The poor folks writing a web based terminal for a kvm/ip product are almost certainly not going to have an unqualified success. There are too many challenges in the way even if you ignore unicode issues and just focus on the american market. I am going to ignore the video/mouse issues as they are mostly solved (except for movies/games with high frame rates) and focus on the keyboard.

My first keyboard was ascii. It had 8 bit parallel ribbon cable that connected it to a z80 machine. This for the most part worked well, the z80 used ascii for everything and since the shift key does not have an ascii code it went on its merry way never knowing or caring if you pressed the shift key. The shift was solely the responsibility of the keyboard as was the control key (no alt or meta keys) and the fact that there was no difference between ctrl t and shift ctrl t bothered no one, it was the keyboard's responsibility to just send ascii. All of my early keyboards just sent ascii whether it be parallel or serial. This worked fine as long as you did not want to send an umlaut or anything else that could not be encoded in ascii.

Now the IBM PC was different it had the ability to change what character set it used. (I believe that this practice may have been in use somewhere else prior to this, but this was my first exposure to a keyboard that did not talk ascii.) The PC had a three layer keyboard model which is still in use to this day although slightly changed. It used scan codes, key codes, and character codes. the scan code is a pure hardware abstraction. The keys were numbered in layout order no relationship to any standard outside of IBM. and each key had a press code and a release code. These press and release codes were called scan codes. The scan codes were then mapped into keycodes (which release events used the same key code as press events but were handled differently) and to character codes Which was by default ascii, but could be changed if you needed european languages. These days unicode has mostly replaced ascii, but the layers are mostly unchanged if spread thinner as most windowing environments provide key events for keypresses that don't have character codes. Now the challenge is to undo all that and what the web browser puts in as well.

  • This is an awesome answer. I wanted to keep reading... – mikeserv Jul 10 '15 at 4:49
  • I was going to write more , but I got interrupted. – hildred Jul 10 '15 at 5:37
  • hildred... I had interpreted the above comment to indicate there was more yet to come...? Was I wrong? That would be disappointing. – mikeserv Jul 12 '15 at 1:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.