How to stop keys from repeating when typing

[Daniel.Glasser]

I'd like you to try two things. First, disable key repeat in the GUI. Does that affect the problem? If so, how?

Second, switch X11 to use the old input drivers (requires creating a xorg.conf). If you don't know how to do this, please let me know and I'll find out the details.

I have key repeat disabled in the GUI now, and I need to shut down my VM and set the keyboard back to PS2.

I'm not 100% sure I know how to change the input driver under Ubuntu. I may have once known, but I'm old and my mind is a sieve. Details would be appreciated.

BTW: I have a pile of Sun type 4 and 5 keyboards in my closet, but (of course) I can't use them on my PC or Mac. VirtualBox doesn't run on the SPARCstation 1+, SPARCstation 2, SPARCstation 5, SPARCserver 10, or SPARC IPC, and though there is Linux available, it's ancient (these are not Ultras, the fastest is 75MHz, and the RAM capacity is laughable by today's standards.) At home, I have a few AT style keyboards with the control key where it belongs (Northgate), but I don't currently have any working DIN-5 to PS/2 micro-DIN adapters (I have two with broken or bent pins).

Thanks,
Daniel

[michaln]

I'm not 100% sure I know how to change the input driver under Ubuntu. I may have once known, but I'm old and my mind is a sieve. Details would be appreciated.

OK, I don't know the details myself but will find out.

BTW: I have a pile of Sun type 4 and 5 keyboards in my closet, but (of course) I can't use them on my PC or Mac.

Is this the sort of layout you're looking for?

That's a Sun Type 6 keyboard (USB). Probably needs some tweaking to get an OS to recognize the different layout, but it can definitely be hooked up to modern systems.

[Daniel.Glasser]

That's the layout... The Type 5 was not (to my knowledge) electrically or protocol-wise compatible with the PS/2 keyboard controller. Type 6 and 7 are newer, and I don't have any of those.

The position of the control key on those keyboards matches that of the DEC LK-201 layout (used on VT200, 300, and later terminals, VAXStations, DECStations, etc.), which is in turn based on DEC VT100 keyboard, and the VT52 keyboard before that. The caps-lock key was next to the control key. Caps lock was considered of lower utility, so it was moved out of the main rows in the later layouts. The original X windowing system keyboard model was based on the DEC keyboard layout because DEC donated a great deal of equipment to the project at MIT. If you look at most async ASCII serial terminals by DEC, ADS, Beehive, etc., the control key was the leftmost key on the home row. That's where it was on the Concept-100 terminals that were at CMU, where I first used Gosling's implementation of emacs in 1982.

When IBM came out with their first 102 key "enhanced" keyboards, the layout was quite similar to the LK-201 layout other than the top row function keys, removal of the "Compose" key, addition of an ALT key, and moving the CTRL key down to the right corner. This was many years after the LK-201 had been out in the wild. For a while, in the early to mid 1990s, both placements of the control key were common; some keyboards had a switch to select the layout. Eventually, the IBM layout, cloned by many vendors, became the default.

To me, the placement of "control" on the lower-left (and more recently, also the lower right) of the main array is inconvenient. The chord control-Q, for example, is actively painful when my carpal tunnel is acting up because of the wrist twist needed. I use both layouts fluently, but find that I'm more accurate and subject to less fatigue when using the "left-of-A" layout.

I'll look around to see if I can find a type-6 or type-7 keyboard at a reasonable price.

Thanks,
Daniel

PS: Back in 1996-97, I was working in an office where the Type 5 keyboards had the dip switches in the back to set the layout. A common practical joke was to change the switches to another national layout (we were in the USA). For example, setting a North American English layout to Canada/French was just subtle enough to drive the victim nuts, whereas switching it to Switzerland/French was more obvious.

[David P. Caldwell]

We are way over my head in terms of the keyboard stuff (and to be honest I skimmed the many, many useful and constructive-sounding postings since mine), but as I've continued modifying my workflow since my original problem report, I've noticed an additional case that may help to home in on the problem, although I don't know what to make of it.

It is not the "host OS" that is activating the problem (and I saw someone concluded this already somehow), it seems to be the Mac OS X keyboard.

If I remote-control (using Chrome Remote Desktop) a guest running on VirtualBox under a Windows host using a Mac OS X machine to operate Chrome Remote Desktop, I can also reproduce the problem. I'm able to reproduce it outside the original stuff (Java, NetBeans); I just typed Control-T on the Mac OS X keyboard and on the FreeBSD guest on the Windows 7 host it opened about 25 Chrome tabs (CTRL-T is the FreeBSD shortcut for "Open New Tab" in Google Chrome).

Sorry I dropped out of the discussion; I had to switch to a different configuration to do my work and have hence been unable to gather additional test cases (until now).

-- David P. Caldwell

[michaln]

It is not the "host OS" that is activating the problem (and I saw someone concluded this already somehow), it seems to be the Mac OS X keyboard.

That is possible, although the Mac keyboard isn't really all that different... unless there's something unusual about that particular Mac?

If I remote-control (using Chrome Remote Desktop) a guest running on VirtualBox under a Windows host using a Mac OS X machine to operate Chrome Remote Desktop, I can also reproduce the problem. I'm able to reproduce it outside the original stuff (Java, NetBeans); I just typed Control-T on the Mac OS X keyboard and on the FreeBSD guest on the Windows 7 host it opened about 25 Chrome tabs (CTRL-T is the FreeBSD shortcut for "Open New Tab" in Google Chrome).

Okay, a couple of questions:

- Was this a one-time occurrence or is this reproducible?
- If I understood correctly, the T key repeated more than it should, but it did not actually get "stuck"?

Here's one possible explanation... remoting over a network may introduce additional latencies (congested network, dropped packets, whatever). Many X11 based GUIs these days emulate key repeat (rather than letting the keyboard do it) and have rather aggressive settings, with a low delay and a high repeat rate. If the network packet containing the key release got delayed for a short while, that could easily cause undesired key repeats. This is really just a theory -- right now I don't have enough evidence

Sorry I dropped out of the discussion; I had to switch to a different configuration to do my work and have hence been unable to gather additional test cases (until now).

No problem!

[michaln]

That's the layout... The Type 5 was not (to my knowledge) electrically or protocol-wise compatible with the PS/2 keyboard controller. Type 6 and 7 are newer, and I don't have any of those.

I don't think I've ever seen a Type 5 or older. The Type 6 keyboard is just plain USB. The only unusual feature of the Sun USB keyboards that I know of is that they report the keyboard layout. "Standard" keyboards don't do that and the user must configure the layout.

The original X windowing system keyboard model was based on the DEC keyboard layout because DEC donated a great deal of equipment to the project at MIT. If you look at most async ASCII serial terminals by DEC, ADS, Beehive, etc., the control key was the leftmost key on the home row. That's where it was on the Concept-100 terminals that were at CMU, where I first used Gosling's implementation of emacs in 1982.

That was probably when Gosling was still at UC Berkeley? That's quite a history there. I don't think I ever used a real VT-100, just various emulations.

PS: Back in 1996-97, I was working in an office where the Type 5 keyboards had the dip switches in the back to set the layout. A common practical joke was to change the switches to another national layout (we were in the USA). For example, setting a North American English layout to Canada/French was just subtle enough to drive the victim nuts, whereas switching it to Switzerland/French was more obvious.

On IBM keyboards, practical jokers swapped around the key caps... for non-touch typists, that was quite a challenge

Okay, here's how to change the X11 keyboard driver in Ubuntu 13.04:

1) Install the old input driver:

Code: Select all

sudo apt-get install xserver-xorg-input-kbd

This is rather important or you may find yourself with a non-functioning keyboard otherwise (happened to me).

2) Create /etc/X11/xorg.conf which no longer exists by default:

Code: Select all

Section "ServerFlags"
	Option	"AutoAddDevices" "false"
EndSection

Section "ServerLayout"
	Identifier  "test config"
	InputDevice "Keyboard0" "CoreKeyboard"
EndSection

Section "InputDevice"
	Identifier  "Keyboard0"
	Driver      "kbd"
	Option      "XkbRules" "xorg"
	Option      "XkbModel" "pc105"
	Option      "XkbLayout" "us"
EndSection

This probably isn't the minimal xorg.conf required, but did the trick for me. Note that this may also influence mouse behavior.

3) Log out and back on; this triggers a X11 restart and forces the changes to be picked up.

With the old keyboard driver, I do not see keystrokes being dropped when I push a batch of keystrokes to the VM with VBoxManage. So I'm curious to know what that will do for you.

[David P. Caldwell]

If I remote-control (using Chrome Remote Desktop) a guest running on VirtualBox under a Windows host using a Mac OS X machine to operate Chrome Remote Desktop, I can also reproduce the problem. I'm able to reproduce it outside the original stuff (Java, NetBeans); I just typed Control-T on the Mac OS X keyboard and on the FreeBSD guest on the Windows 7 host it opened about 25 Chrome tabs (CTRL-T is the FreeBSD shortcut for "Open New Tab" in Google Chrome).

Okay, a couple of questions:

- Was this a one-time occurrence or is this reproducible?

I believe it has happened more than once (I vaguely recall a previous problem like this a few weeks ago, but it fell off my radar), but I would not yet call it "reproducible" -- i.e., I don't know how to quickly cause it to happen. (I have also not tried very hard as I am not using the remote control configuration frequently.)

- If I understood correctly, the T key repeated more than it should, but it did not actually get "stuck"?

Correct.

Here's one possible explanation... remoting over a network may introduce additional latencies (congested network, dropped packets, whatever). Many X11 based GUIs these days emulate key repeat (rather than letting the keyboard do it) and have rather aggressive settings, with a low delay and a high repeat rate. If the network packet containing the key release got delayed for a short while, that could easily cause undesired key repeats. This is really just a theory -- right now I don't have enough evidence

As I mentioned earlier, I'm in over my head, but my instinct is that this theory is not correct, and here's why: the behavior I saw (extremely rapid, or possibly instantaneous, key duplication, but not stuck) is exactly the same as the behavior I got using the same Mac as the host for the VM. So:

1. I have, for a long time, run FreeBSD VMs on a Windows host, without seeing the problem,
2. I was running a similarly-configured FreeBSD VM on the Mac OS X host that was essentially unusable because of the key-repeat problem, so I have abandoned it for now,
3. Yesterday I was able to reproduce behavior very similar to the behavior I had on the Mac, which I have never had on the Windows machine, by using the Mac to remote control the Windows machine.

The problem, as I've seen it, has always been that when I am typing, some keys will repeat a bunch of times. (So I will type phrases like "The quiiiiiiiiiiick brown fox jumped over tttttttttttttttttthe lazy dog..."). So opening 25 Chrome tabs with a single keystroke is consistent with my problem.

Still, as you said, it's only once that I am sure about and recall clearly. But it smells right to me. (And obviously still could be wrong; it could have an unrelated cause like the one you suggest.)

As you mention in a portion I did not quote (paraphrase: "maybe it's this Mac"), perhaps there is something unusual about some (new? particular model?) Mac notebook keyboards? This might explain why the problem does not seem widespread but is debilitating to some users like me. I have a customer-issued, very recent Macbook Pro (in About this Mac it says "Macbook Pro, Retina, 15-inch, Early 2013") but there is no obvious information about the keyboard under System Report | Hardware (and as I am new to the Mac world, I don't really know where to look).

-- David P. Caldwell.

[Daniel.Glasser]

This probably isn't the minimal xorg.conf required, but did the trick for me. Note that this may also influence mouse behavior.

Unfortunately, this renders the mouse almost unusable. The vertical position of the displayed pointer is off by quite a bit (roughly correct at the upper scan, off by more and more as you move the pointer down the screen), and offset from left-to-right by some hard to work out distance. Perhaps I need to change the mouse input method to something other than USB tablet. I'll experiment.

Edit:
I'm afraid that that setting the mouse to PS/2 was worse than leaving it at USB Tablet. Not sure how to solve the mouse pointer issues, and not sure that I can get the problem to happen when the mouse is unusable.

[michaln]

As you mention in a portion I did not quote (paraphrase: "maybe it's this Mac"), perhaps there is something unusual about some (new? particular model?) Mac notebook keyboards? This might explain why the problem does not seem widespread but is debilitating to some users like me. I have a customer-issued, very recent Macbook Pro (in About this Mac it says "Macbook Pro, Retina, 15-inch, Early 2013") but there is no obvious information about the keyboard under System Report | Hardware (and as I am new to the Mac world, I don't really know where to look).

I wouldn't think it's the keyboard hardware... although... hmm. You have the key repeat problem only with VMs, right? Any chance you could try an external USB or wireless keyboard to check if the key repeat behavior persists?

In general I suspect there are multiple unrelated causes that happen to have the same symptoms. And all of those are pretty rare. Very annoying.

[michaln]

Unfortunately, this renders the mouse almost unusable. The vertical position of the displayed pointer is off by quite a bit (roughly correct at the upper scan, off by more and more as you move the pointer down the screen), and offset from left-to-right by some hard to work out distance. Perhaps I need to change the mouse input method to something other than USB tablet. I'll experiment.

Yes, this is a sad problem with older X11 versions. For some bizarre reason, unlike Windows or OS X, these versions assume that an absolute pointing device must be a touchpad, and convert the absolute movement to relative. The result is not good. I don't know if this can be worked around.

I'm not sure why PS/2 mouse emulation should be unusable though? Can you elaborate please? Note that with PS/2 mouse, the pointer has to be captured to work inside the VM and released again to work on the host. An unfortunate limitation of a relative pointing device.

[Daniel.Glasser]

I'm not sure why PS/2 mouse emulation should be unusable though? Can you elaborate please? Note that with PS/2 mouse, the pointer has to be captured to work inside the VM and released again to work on the host. An unfortunate limitation of a relative pointing device.

There is no locator pointer visible within the guest desktop window while the mouse is captured.

[michaln]

There is no locator pointer visible within the guest desktop window while the mouse is captured.

Hmm. Do you have the Guest Additions installed in the VM? Asking because that will not impact the keyboard behavior in any way, but it will affect the mouse.

[Daniel.Glasser]

There is no locator pointer visible within the guest desktop window while the mouse is captured.

Hmm. Do you have the Guest Additions installed in the VM? Asking because that will not impact the keyboard behavior in any way, but it will affect the mouse.

I do have the latest according to "Help/Check for updates...".
There may be some setting that prevents the locator cursor from being displayed so that the host windowing system's locator cursor will not be shadowed by a second cursor image, but I don't know how to control that.

[Lynnwood]

I've been trying to find solution to this issue because it makes virtual box un-usable for me. I'm trying to create Ubuntu 14.04 VM but I can't even log into my vm because i can't get it to enter my user & pw correctly. I've turned off repeat keys completely on my host machine but it doesn't help. I've tried different keyboard configurations when installing ubuntu but that doesn't help. No matter how slowly or carefully i tried to enter keystrokes, they randomly repeat 2 or more times. I try to delete 1 character and it deletes 4. I hit return and it registered 2 or 3 returns. Consequently, i can't log in no matter how simple and short i make my pw. I'm giving up and deleting virtual box until this gets sorted out.

[livelogic]

I am experiencing the same issue: when i type in the VM i often (not always) get repeating keys... very annoying!
I only have little information to add to this thread but i thought it was worth trying

I feel this issue is related to typing speed. It only comes up when i use the VM with my notebook (internal keyboard) and strike keys quickly.
I observed this is mostly happening when i press ENTER or BACKSPACE keys while typing fast, but it happens with other keys too. Pressing the same keys 'slowly' doesn't trigger the issue.
Interestingly, i could not reproduce the issue when running the same VM on a desktop PC (same VB version), where the keyboard is connected via USB.
BTW, configuring the keyboard as PS/2 and USB makes no difference.

The setup is a Win 7/64 host, WinXP guest, VirtualBox latest version (4.3.20) and Guest Additions loaded.