I just upgraded my laptop to a Microsoft Surface Pro 6 running Windows 10, and after lots of back and forth with Microsoft support, finally discovered that my Keyman installation is what is causing my on-screen touch keyboard to malfunction. When Keyman is installed, the Microsoft on-screen touch keyboard will disappear after inputting one letter (this is the case in tablet mode and console mode, for any software, program, or browser). After running a bunch of diagnostics, I tried uninstalling Keyman, and it worked perfectly again. Then I reinstalled the latest version 12 (released 11/28/19), and it once again stopped working. Uninstalled it - worked again. This is a bug that should be fixed please, otherwise I can’t use Keyman on my work laptop. Thanks!
I could reconstruct the same behaviour on my surfacebook. The only thing is, that you don’t need to uninstall keyman. Just closing it is enough to make the touch keyboard function normally again.
Can you tell me what keyboard you are trying to use?
It’s the built-in touch screen keyboard in Microsoft 10. When I remove my physical keyboard (Type Cover), the computer detects that and offers a touch-screen keyboard to use on screen.
I am currently travelling and don’t have access to a touch screen computer to test this issue. I will investigate on my return in a week or so and let you know what I find.
Does the issue arise only when a Keyman keyboard is selected, or even when the Keyman keyboard is inactive (e.g. when using a Windows keyboard layout)?
I can reproduce this with the onscreen touch keyboard in Windows 10 (a right-click on the Windows keyboard indicator shows an option to “Show touch keyboard button”. Clicking the new touch keyboard button opens a onscreen keyboard).
When Keyman 12 is running and click on any button on the onscreen “touch” keyboard it’ll close the onscreen keyboard, regardless what keyboard layout (Keyman or Windows keyboard layout) is selected.
After I exit Keyman 12 I can click any button on the onscreen keyboard and it stays open.
Okay, I have finally arrived home and have access to my touch-screen laptop. I have reproduced this problem.
This relates to the serialization guarantee (warning: technical blog post) that Keyman provides. From a technical perspective, what happens is that Keyman intercepts each keystroke and reissues it to ensure that key events arrive in a specific order when additional key events from Keyman are interleaved into the key event queue. But when Keyman reissues the key event, the touch keyboard thinks it is coming from hardware and closes!
There are two workarounds for now.
Workaround #1: Exit Keyman when using the touch layout
This works but is obviously awkward if you need to use Keyman!
Workaround #2: Disable the serialization guarantee
This may mean that some key events arrive out of order when using Keyman, particularly if you type fast. However, I have tested this and it does avoid the conflict with the touch keyboard.
- Start Registry Editor (regedit.exe)
- Navigate to
- Select Edit/New/Key and name the key
- Select the new
Debugkey, and select Edit/New/DWORD value and name the value
Flag_ShouldSerializeInput. It will be created with the default value
- Exit and restart Keyman (you may need to restart Windows).
I have documented this issue for full resolution in a future update of Keyman.
Well, I wish I had seen this report back in December when I was tearing my hair out over this. Yhis issue took me several days to sort out on my own. I was nearly ready to reset my machine when I realized the touch keyboard worked fine on a new user account (without KM running). Since Keyman wasn’t in use, I didn’t suspect it for a long time.
I just reinstalled KM to see if the problem resumed, and to write up a bug report. It did resume, and then I found this. I’ll try the registry edit, as I use the on-screen keyboard a bit more often than Keyman.
Why is Keyman receiving [and sending] anything at all if a Keyman keyboard is not enabled and the daemon is just idling? Isn’t that a security flaw?
Sorry you’ve experienced this issue as well. It’s on my agenda to address it next week.
I don’t see how it could be a security flaw, but the basic situation is that the low level keyboard hook which deals with out-of-order key events is not aware of which keyboard is currently active. The resolution will be to add that extra bit of complexity to enable that code path only when a Keyman keyboard is active. Sadly, this means that the touch keyboard will not work with Keyman anyway unless we find some way to detect when a keystroke comes from it rather than from the hardware keyboard (this may be possible; I haven’t yet investigated), and disable the out-of-order management in that case.
Thanks. I just decided to leave Keyman off on windows startup, that will work for my use case.
I guess that this is one more reason to explore getting the touch keyboards working natively on desktop. A mobile-style responsive touch keyboard would be much nicer than the current OSK.