"Touch Keyboard and Handwriting Panel Service" isn't running #11346

Closed
opened 2026-01-31 02:45:04 +00:00 by claunia · 36 comments
Owner

Originally created by @vefatica on GitHub (Nov 11, 2020).

How do I get rid of this?

image

Originally created by @vefatica on GitHub (Nov 11, 2020). How do I get rid of this? ![image](https://user-images.githubusercontent.com/61856645/98853954-e6d56000-2427-11eb-9774-b24aed7dc0f9.png)
Author
Owner

@DHowett commented on GitHub (Nov 11, 2020):

This message is self-evident.

@DHowett commented on GitHub (Nov 11, 2020): This message is self-evident.
Author
Owner

@vefatica commented on GitHub (Nov 11, 2020):

I don't care to turn on a service just to get rid of an annoying popup that says it's not on. It has no function and has never been on here. Is there another way?

@vefatica commented on GitHub (Nov 11, 2020): I don't care to turn on a service just to get rid of an annoying popup that says it's not on. It has no function and has never been on here. Is there another way?
Author
Owner

@DHowett commented on GitHub (Nov 11, 2020):

We've had approximately 500 users report that their keyboards don't work in Terminal, and in 98% of those cases it ended up being because they had this service disabled. Maybe it works for you without that service, but it turns out that it's an important part of the modern app infrastructure in Windows and shouldn't be disabled. It makes applications behave unpredictably.

@DHowett commented on GitHub (Nov 11, 2020): We've had approximately 500 users report that their keyboards don't work in Terminal, and in 98% of those cases it ended up being because they had this service disabled. Maybe it works for you without that service, but it turns out that it's an important part of the modern app infrastructure in Windows and shouldn't be disabled. It makes applications behave unpredictably.
Author
Owner

@vefatica commented on GitHub (Nov 11, 2020):

It has been disabled since this computer was new (16 months). There has never been an issue. I respectively request that you give users a way to leave that service disabled and avoid the popup.

@vefatica commented on GitHub (Nov 11, 2020): It has been disabled since this computer was new (16 months). There has never been an issue. I respectively request that you give users a way to leave that service disabled and avoid the popup.
Author
Owner

@DHowett commented on GitHub (Nov 11, 2020):

Nope. Sorry. Disabling random system services is not supported.

@DHowett commented on GitHub (Nov 11, 2020): Nope. Sorry. Disabling random system services is not supported.
Author
Owner

@DHowett commented on GitHub (Nov 11, 2020):

(If we add such an option, it will be titled iAmTheKindOfPersonWhoDisablesRandomSystemServicesAndAcceptThatThisIsNotASupportedConfigurationSoStopTellingMeAboutIt and it will delete the feedback link from the main menu.)

@DHowett commented on GitHub (Nov 11, 2020): (If we add such an option, it will be titled `iAmTheKindOfPersonWhoDisablesRandomSystemServicesAndAcceptThatThisIsNotASupportedConfigurationSoStopTellingMeAboutIt` and it will delete the feedback link from the main menu.)
Author
Owner

@vefatica commented on GitHub (Nov 11, 2020):

Nothing random about it. It's a service I don't need.

@vefatica commented on GitHub (Nov 11, 2020): Nothing random about it. It's a service I don't need.
Author
Owner

@zadjii-msft commented on GitHub (Nov 11, 2020):

Alright so this raises even more questions! We're under the impression that disabling that service will 100% of the time also break the keyboard input to the Terminal. We're also not 100% sure why it's needed to get input to the Terminal, but it definitely is. So the fact that you can have the service disabled, and have the Terminal still work fine is mind-boggling to me.

I'm gonna summon more folks from the input team to investigate. The last we talked with them, they were confident that the service shouldn't be disabled in any circumstance, and disabling it might break things randomly. If you're lucky and the Terminal wasn't broken by disabling that service, it doesn't mean you don't need it - it just means that something else down the line will mysteriously break.

@zadjii-msft commented on GitHub (Nov 11, 2020): Alright so this raises even more questions! We're under the impression that disabling that service will 100% of the time also break the keyboard input to the Terminal. We're also not 100% sure _why_ it's needed to get input to the Terminal, but it definitely is. So the fact that you can have the service disabled, and have the Terminal still work fine is mind-boggling to me. I'm gonna summon more folks from the input team to investigate. The last we talked with them, they were confident that the service shouldn't be disabled in any circumstance, and disabling it might break things randomly. If you're lucky and the Terminal _wasn't_ broken by disabling that service, it doesn't mean you don't need it - it just means that something else down the line will mysteriously break.
Author
Owner

@vefatica commented on GitHub (Nov 11, 2020):

Does it have anything to do with the actual physical keyboard? Mine is an oldie ... PS/2.

@vefatica commented on GitHub (Nov 11, 2020): Does it have anything to do with the actual physical keyboard? Mine is an oldie ... PS/2.
Author
Owner

@zadjii-msft commented on GitHub (Nov 11, 2020):

Surprisingly, the latest theory is that the real process we need is ctfmon.exe. @vefatica, is that process running for you? Apparently the service helps ensure that ctfmon is running and continues running, and you might just be lucky that ctfmon.exe is running without that service being enabled.

@zadjii-msft commented on GitHub (Nov 11, 2020): Surprisingly, the latest theory is that the _real_ process we need is `ctfmon.exe`. @vefatica, is that process running for you? Apparently the service helps ensure that `ctfmon` is running and continues running, and you might just be lucky that `ctfmon.exe` is running _without_ that service being enabled.
Author
Owner

@vefatica commented on GitHub (Nov 11, 2020):

Ctfmon.exe is not running.

@vefatica commented on GitHub (Nov 11, 2020): Ctfmon.exe is not running.
Author
Owner

@vefatica commented on GitHub (Nov 11, 2020):

I do have a task running that sounds related:

Folder: \Microsoft\Windows\TextServicesFramework
TaskName: MsCtfMonitor

When I try to stop it it doesn't stop and Last Error is 267014. SCHTASKS says it was started 2020-11-11 17:07:56. The only processes I have that were started at that time are these.

11/11 17:07:56.478 5852 0.016 7.1 unsecapp.exe
11/11 17:07:56.627 5936 0.531 25.0 sihost.exe
11/11 17:07:56.855 5556 6.688 119.6 explorer.exe

11/11 17:07:56.643 5972 0.281 28.5 WpnUserService_57c2c Windows Push Notifications User Service_57c2c
11/11 17:07:56.651 6008 0.063 18.6 FontCache3.0.0.0 Windows Presentation Foundation Font Cache 3.
11/11 17:07:56.879 5712 0.000 10.0 NcbService Network Connection Broker

@vefatica commented on GitHub (Nov 11, 2020): I do have a task running that sounds related: Folder: \Microsoft\Windows\TextServicesFramework TaskName: MsCtfMonitor When I try to stop it it doesn't stop and Last Error is 267014. SCHTASKS says it was started 2020-11-11 17:07:56. The only processes I have that were started at that time are these. 11/11 17:07:56.478 5852 0.016 7.1 unsecapp.exe 11/11 17:07:56.627 5936 0.531 25.0 sihost.exe 11/11 17:07:56.855 5556 6.688 119.6 explorer.exe 11/11 17:07:56.643 5972 0.281 28.5 WpnUserService_57c2c Windows Push Notifications User Service_57c2c 11/11 17:07:56.651 6008 0.063 18.6 FontCache3.0.0.0 Windows Presentation Foundation Font Cache 3. 11/11 17:07:56.879 5712 0.000 10.0 NcbService Network Connection Broker
Author
Owner

@vefatica commented on GitHub (Nov 11, 2020):

Actually that task does end; you can't see that in the Tasks GUI, but an instance of taskhostw.exe terminates. And Windows Terminal still works just fine.

@vefatica commented on GitHub (Nov 11, 2020): Actually that task does end; you can't see that in the Tasks GUI, but an instance of taskhostw.exe terminates. And Windows Terminal still works just fine.
Author
Owner

@ghost commented on GitHub (Nov 24, 2020):

Same. This popup is annoying and I've never had issues with keyboard input. Please give us an option to disable the popup.

@ghost commented on GitHub (Nov 24, 2020): Same. This popup is annoying and I've never had issues with keyboard input. Please give us an option to disable the popup.
Author
Owner

@cornem commented on GitHub (Nov 27, 2020):

Same here. The reason I have disabled this service is because I'm using a Wacom pen, and I don't need the onscreen keyboard to keep popping up. Windows Terminal has been working fine since I started using it when it was still in preview. This popup is rather annoying, because it's shown every time.

Could you consider:

  1. If there's a way to be more specific in checking which services are required. I would assume this isn't 100% accurate a.t.m., since the Terminal actually works great for me with this service disabled. Never had a problem.
  2. Add an option to disable the warning.
  3. Make the warning less obtrusive - maybe a 'snack'-like popup in the top right that disappears automatically after x seconds.
  4. Show the dialog only x times.

Personally I would prefer if you could prioritize option 1 or 3.

@cornem commented on GitHub (Nov 27, 2020): Same here. The reason I have disabled this service is because I'm using a Wacom pen, and I don't need the onscreen keyboard to keep popping up. Windows Terminal has been working fine since I started using it when it was still in preview. This popup is rather annoying, because it's shown every time. Could you consider: 1. If there's a way to be more specific in checking which services are required. I would assume this isn't 100% accurate a.t.m., since the Terminal actually works great for me with this service disabled. Never had a problem. 2. Add an option to disable the warning. 3. Make the warning less obtrusive - maybe a 'snack'-like popup in the top right that disappears automatically after `x` seconds. 4. Show the dialog only `x` times. Personally I would prefer if you could prioritize option 1 or 3.
Author
Owner

@piscisaureus commented on GitHub (Nov 27, 2020):

I would really appreciate an option to disable this warning too.

I disabled the specific service for a reason: enabling it adds noticeable keyboard lag in certain applications(*), which I find very uncomfortable to work with. This is happening on a 7 month old Surface Book 2, running an up-to-date version of Windows 10 pro (default channel).

Windows Terminal works fine without it. Disabling TabletInputService does prevent the on-screen keyboard from showing when the screen is detached, but the trade-off is well worth it: having the physical keyboard function properly is it is much more important to me.

(*): At least Chrome and VS Code are affected. I've done some investigation into this; a procmon trace shows that when the service is running, ctfmon.exe starts and exits on every keypress.

(My apologies for the repost from #7886, but it seems the discussion has moved to this thread.)

@piscisaureus commented on GitHub (Nov 27, 2020): I would really appreciate an option to disable this warning too. I disabled the specific service for a reason: enabling it adds noticeable keyboard lag in certain applications(*), which I find very uncomfortable to work with. This is happening on a 7 month old Surface Book 2, running an up-to-date version of Windows 10 pro (default channel). Windows Terminal works fine without it. Disabling `TabletInputService` _does_ prevent the on-screen keyboard from showing when the screen is detached, but the trade-off is well worth it: having the physical keyboard function properly is it is much more important to me. (*): At least Chrome and VS Code are affected. I've done some investigation into this; a `procmon` trace shows that when the service is running, `ctfmon.exe` starts and exits on every keypress. (My apologies for the repost from #7886, but it seems the discussion has moved to this thread.)
Author
Owner

@levicki commented on GitHub (Dec 24, 2020):

@DHowett I am the kind of person that not only disables, but also deletes system services I don't like (DiagTrack I am looking at you). Hardware is mine, you can't do with it as you please.

That aside, on my desktop system Windows Terminal works just fine without both TabletInputService and ctfmon.exe running.

Then again, I am using US English keyboard layout on a physical keyboard, and I don't have a Bluetooth keyboard or any kind of touch screen so YMMV.

Here is a good overview of what ctfmon.exe is used for. Perhaps it helps you figure out what kind of Windows Terminal users have issues when it is not started. My wild guess would be those who use one or more of Bluetooth keyboards, complex scripts (Chinese, Japanese, etc), touch screen (i.e. on-screen keyboard), or handwriting for text input.

@levicki commented on GitHub (Dec 24, 2020): @DHowett I am the kind of person that not only disables, but also deletes system services I don't like (DiagTrack I am looking at you). Hardware is mine, you can't do with it as you please. That aside, on my desktop system Windows Terminal works just fine without both TabletInputService and ctfmon.exe running. Then again, I am using US English keyboard layout on a physical keyboard, and I don't have a Bluetooth keyboard or any kind of touch screen so YMMV. Here is a good [overview](https://www.lifewire.com/what-is-ctfmon-4780519) of what ctfmon.exe is used for. Perhaps it helps you figure out what kind of Windows Terminal users have issues when it is not started. My wild guess would be those who use one or more of Bluetooth keyboards, complex scripts (Chinese, Japanese, etc), touch screen (i.e. on-screen keyboard), or handwriting for text input.
Author
Owner

@mdcclxv commented on GitHub (Jan 2, 2021):

Same boat here. I need an option to avoid the popup and keep the service disabled. InforBar is not acceptable as long as it has to be dismissed manually. Is still annoying.

@DHowett : "it turns out that it's an important part of the modern app infrastructure in Windows and shouldn't be disabled". That's simply not true. As long there is a single case that contradicts you, then your affirmation only holds true in a certain situation, which, obviously, doesn't apply to everyone. So, please be open minded and stop putting out "absolute truths".

@mdcclxv commented on GitHub (Jan 2, 2021): Same boat here. I need an option to avoid the popup and keep the service disabled. InforBar is not acceptable as long as it has to be dismissed manually. Is still annoying. @DHowett : "it turns out that it's an important part of the modern app infrastructure in Windows and shouldn't be disabled". That's simply not true. As long there is a single case that contradicts you, then your affirmation only holds true in a certain situation, which, obviously, doesn't apply to everyone. So, please be open minded and stop putting out "absolute truths".
Author
Owner

@mdcclxv commented on GitHub (Jan 3, 2021):

@zadjii-msft regarding your last comment on #8692 and to all others having the same attitude/opinion towards disabling services: I don't mean to be offensive in any way, but you need to stop worrying so much for others. We're not kindergarten children. If I decide to disable a service it's my decision and I assume it. Having an option to circumvent an annoying popup/InfoBar seems to me elementary and I don't see any harm in implementing it as long as you put the necessary warning on that option in the settings file. From that point it's the user's choice/risk. And that's how things should be. Otherwise we should stop selling kitchen knives out of the fear of people misusing them or hurting themselves. It really doesn't make sense. My two cents on this overprotective attitude.

@mdcclxv commented on GitHub (Jan 3, 2021): @zadjii-msft regarding your last comment on #8692 and to all others having the same attitude/opinion towards disabling services: I don't mean to be offensive in any way, but you need to stop worrying so much for others. We're not kindergarten children. If I decide to disable a service it's my decision and I assume it. Having an option to circumvent an annoying popup/InfoBar seems to me elementary and I don't see any harm in implementing it as long as you put the necessary warning on that option in the settings file. From that point it's the user's choice/risk. And that's how things should be. Otherwise we should stop selling kitchen knives out of the fear of people misusing them or hurting themselves. It really doesn't make sense. My two cents on this overprotective attitude.
Author
Owner

@DHowett commented on GitHub (Jan 3, 2021):

@mdcclxv You'll probably be surprised to learn that this isn't to protect users from themselves. Rather, it is because of this thread with 131 comments from users who universally experienced an input failure because of the exact scenario that pop-up documents.

image

The five users we've encountered who have disabled this service and inexplicably have a working input stack are in the extreme minority, and they can deal with it fairly trivially. We'll probably add a setting or something, but not after raising the hackles of power users who are certain they understand the operating system.

You have an overview from some source called "lifewire" as to what ctfmon.exe does, and we have the person who owns that executable explaining to us how the input stack works and why it's required for modern apps. I know which one I'm inclined to trust.

@DHowett commented on GitHub (Jan 3, 2021): @mdcclxv You'll probably be surprised to learn that this isn't to protect users from themselves. Rather, it is because of this thread with 131 comments from users who _universally_ experienced an input failure because of the exact scenario that pop-up documents. ![image](https://user-images.githubusercontent.com/189190/103488761-66e2cb00-4dc4-11eb-8532-9126be3781af.png) The five users we've encountered who have disabled this service and inexplicably have a working input stack are in the extreme minority, and they can _deal with it_ fairly trivially. We'll probably add a setting or something, but not after raising the hackles of power users who are certain they understand the operating system. You have an overview from some source called "lifewire" as to what ctfmon.exe does, and we have the person who owns that executable explaining to us how the input stack works and why it's required for modern apps. I know which one I'm inclined to trust.
Author
Owner

@mdcclxv commented on GitHub (Jan 3, 2021):

That setting involves a couple lines of code for reading it from the json file and an "if" around the popup code. It's 5 minutes of work and another 10 for testing. And no one is forced in using it. Are we really talking about the minority here or is it something else entirely? You already lost more time talking about it than you would have implementing it.
I'm not asking you to remove the popup, I'm asking you to allow me to remove it.

@mdcclxv commented on GitHub (Jan 3, 2021): That setting involves a couple lines of code for reading it from the json file and an "if" around the popup code. It's 5 minutes of work and another 10 for testing. _And no one is forced in using it_. Are we really talking about the minority here or is it something else entirely? You already lost more time talking about it than you would have implementing it. I'm not asking you to remove the popup, I'm asking you to allow **me** to remove it.
Author
Owner

@DHowett commented on GitHub (Jan 3, 2021):

We'd be happy to review such a pull request.

@DHowett commented on GitHub (Jan 3, 2021): We'd be happy to review such a pull request.
Author
Owner

@mdcclxv commented on GitHub (Jan 3, 2021):

That's just amazing! I'm sure you realize that it would take me waaay much more time than it would to you. I would have to install Visual Studio (and probably some extra build tools), then get familiar with the code so I would not break the design. That's a lot of work just because you're actually power-playing here. Nice! I'm getting another terminal.

@mdcclxv commented on GitHub (Jan 3, 2021): That's just amazing! I'm sure you realize that it would take me waaay much more time than it would to you. I would have to install Visual Studio (and probably some extra build tools), then get familiar with the code so I would not break the design. That's a lot of work just because you're actually power-playing here. Nice! I'm getting another terminal.
Author
Owner

@zadjii-msft commented on GitHub (Jan 4, 2021):

Alright everyone, we still want to get to the root cause of this. I'm tapping @ebadger in to try and investigate all y'all who do have ctfmon.exe not running and Terminal input working seemingly fine. Keep it on topic.

@zadjii-msft commented on GitHub (Jan 4, 2021): Alright everyone, we still want to get to the root cause of this. I'm tapping @ebadger in to try and investigate all y'all who do have `ctfmon.exe` **not running** and Terminal input working seemingly fine. Keep it on topic.
Author
Owner

@vefatica commented on GitHub (Jan 7, 2021):

With the upgrade to 20H2 a couple weeks ago, things have changed here. WT still works fine without ctfmon.exe or the service, but without ctfmon, typing after opening the start menu doesn't work. So for now, the service is enabled and it makes sure ctfmon is running.

But there is a new wrinkle ... TextInputHost.exe. Many actions will cause it to start and many won't. Some actions that cause TextInputHost.exe to start are

typing in Firefox's find dialog (Ctrl-F)
opening the start menu
any change of focus for which Windows Terminal is the recipient including switching tabs/panes
switching to and typing in, this message composition window

Things that don't cause it to start:

any editor
the Win-R dialog (Run)
any app in a console.

The only thing that seems to suffer if I kill TextInputHost.exe several times a second is the emoji picker and I've read that the emoji picker is TextInputHost.exe's raison d'être.

When I rename TextInputHost.exe's directory, everything I want works but the System event log gets a DCOM error entry every time it would start (which is often).

Does anyone know more about this thing, in particular, how to defeat it elegantly?

@vefatica commented on GitHub (Jan 7, 2021): With the upgrade to 20H2 a couple weeks ago, things have changed here. WT still works fine without ctfmon.exe or the service, but without ctfmon, typing after opening the start menu doesn't work. So for now, the service is enabled and it makes sure ctfmon is running. But there is a new wrinkle ... TextInputHost.exe. Many actions will cause it to start and many won't. Some actions that cause TextInputHost.exe to start are typing in Firefox's find dialog (Ctrl-F) opening the start menu any change of focus for which Windows Terminal is the recipient including switching tabs/panes switching to and typing in, this message composition window Things that don't cause it to start: any editor the Win-R dialog (Run) any app in a console. The only thing that seems to suffer if I kill TextInputHost.exe several times a second is the emoji picker and I've read that the emoji picker is TextInputHost.exe's raison d'être. When I rename TextInputHost.exe's directory, everything I want works but the System event log gets a DCOM error entry every time it _would_ start (which is often). Does anyone know more about this thing, in particular, how to defeat it elegantly?
Author
Owner

@DHowett commented on GitHub (Jan 7, 2021):

I am happy to discuss mitigating problems with stopping this service, and how Terminal can act better when your system is in an unsupported configuration. I will, however, delete content that advises users on how to damage their system configuration in this manner. Sorry.

@DHowett commented on GitHub (Jan 7, 2021): I am happy to discuss mitigating problems with stopping this service, and how Terminal can act better when your system is in an unsupported configuration. I _will_, however, delete content that advises users on how to damage their system configuration in this manner. Sorry.
Author
Owner

@levicki commented on GitHub (Jan 7, 2021):

@vefatica I suggest asking such questions on tenforums or mdl forums, not here. It is totally irrational to expect "help" of that kind from Microsoft developers.

@levicki commented on GitHub (Jan 7, 2021): @vefatica I suggest asking such questions on tenforums or mdl forums, not here. It is totally irrational to expect "help" of that kind from Microsoft developers.
Author
Owner

@gotthastan commented on GitHub (Aug 31, 2021):

I am happy to discuss mitigating problems with stopping this service, and how Terminal can act better when your system is in an unsupported configuration. I will, however, delete content that advises users on how to damage their system configuration in this manner. Sorry.

disabling this service is literally suggested as a performance improvement by MS in a VDI solution. why would i EVER need the tablet input service running on a vdi?

https://docs.microsoft.com/en-us/windows-server/remote/remote-desktop-services/rds-vdi-recommendations-2004#windows-optional-features-cleanup

look for "TabletInputService" on the page above.

saying it is unsupported is not exactly correct. the terminal should work with the service off in an optimized VDI configuration.

@gotthastan commented on GitHub (Aug 31, 2021): > I am happy to discuss mitigating problems with stopping this service, and how Terminal can act better when your system is in an unsupported configuration. I _will_, however, delete content that advises users on how to damage their system configuration in this manner. Sorry. disabling this service is literally suggested as a performance improvement by MS in a VDI solution. why would i EVER need the tablet input service running on a vdi? https://docs.microsoft.com/en-us/windows-server/remote/remote-desktop-services/rds-vdi-recommendations-2004#windows-optional-features-cleanup look for "TabletInputService" on the page above. saying it is unsupported is not exactly correct. the terminal should work with the service off in an optimized VDI configuration.
Author
Owner

@DHowett commented on GitHub (Aug 31, 2021):

That's good to know! Thanks!

That's a really actionable piece of feedback we can take to the input team.

@DHowett commented on GitHub (Aug 31, 2021): That's good to know! Thanks! That's a really actionable piece of feedback we can take to the input team.
Author
Owner

@cphurley82 commented on GitHub (Dec 29, 2021):

I'm unable to use Windows Terminal from my company supplied Azure Virtual Desktop due to this problem.

@cphurley82 commented on GitHub (Dec 29, 2021): I'm unable to use Windows Terminal from my company supplied Azure Virtual Desktop due to this problem.
Author
Owner

@JunkyXL86 commented on GitHub (Apr 13, 2022):

I am happy to discuss mitigating problems with stopping this service, and how Terminal can act better when your system is in an unsupported configuration. I will, however, delete content that advises users on how to damage their system configuration in this manner. Sorry.

disabling this service is literally suggested as a performance improvement by MS in a VDI solution. why would i EVER need the tablet input service running on a vdi?

https://docs.microsoft.com/en-us/windows-server/remote/remote-desktop-services/rds-vdi-recommendations-2004#windows-optional-features-cleanup

look for "TabletInputService" on the page above.

saying it is unsupported is not exactly correct. the terminal should work with the service off in an optimized VDI configuration.

Service definitively disabled on my VDI as well. Now I have to back up to PowerShell.

@JunkyXL86 commented on GitHub (Apr 13, 2022): > > I am happy to discuss mitigating problems with stopping this service, and how Terminal can act better when your system is in an unsupported configuration. I _will_, however, delete content that advises users on how to damage their system configuration in this manner. Sorry. > > disabling this service is literally suggested as a performance improvement by MS in a VDI solution. why would i EVER need the tablet input service running on a vdi? > > https://docs.microsoft.com/en-us/windows-server/remote/remote-desktop-services/rds-vdi-recommendations-2004#windows-optional-features-cleanup > > look for "TabletInputService" on the page above. > > saying it is unsupported is not exactly correct. the terminal should work with the service off in an optimized VDI configuration. Service definitively disabled on my VDI as well. Now I have to back up to PowerShell.
Author
Owner

@ebadger commented on GitHub (Apr 13, 2022):

Thanks for the doc link.

For AVD we're now testing configurations where this service is used to virtualize edit information across machine boundary to enable "like local" experiences via local input methods in the client OS. This enables features like voice typing, handwriting, IMEs, emoji / symbol picker, cloud clipboard, software input to work in these virtualized app scenarios.

Additionally, if you're virtualizing UWP apps (or Terminal) this could lead to basic functionality issues with keyboard input in those apps.

Thanks,

Eric

@ebadger commented on GitHub (Apr 13, 2022): Thanks for the doc link. For AVD we're now testing configurations where this service is used to virtualize edit information across machine boundary to enable "like local" experiences via local input methods in the client OS. This enables features like voice typing, handwriting, IMEs, emoji / symbol picker, cloud clipboard, software input to work in these virtualized app scenarios. Additionally, if you're virtualizing UWP apps (or Terminal) this could lead to basic functionality issues with keyboard input in those apps. Thanks, Eric
Author
Owner

@gotthastan commented on GitHub (Apr 13, 2022):

maybe don't call it TabletInputService and make the name more appropriate
for what it is doing? or separate the functionality into
separate services>?

.......

@gotthastan commented on GitHub (Apr 13, 2022): maybe don't call it TabletInputService and make the name more appropriate for what it is doing? or separate the functionality into separate services>? .......
Author
Owner

@ebadger commented on GitHub (Apr 13, 2022):

already done in the current release. new name is Text Input Management Service

@ebadger commented on GitHub (Apr 13, 2022): already done in the current release. new name is Text Input Management Service
Author
Owner

@julie777 commented on GitHub (Nov 10, 2022):

We've had approximately 500 users report that their keyboards don't work in Terminal, and in 98% of those cases it ended up being because they had this service disabled. Maybe it works for you without that service, but it turns out that it's an important part of the modern app infrastructure in Windows and shouldn't be disabled. It makes applications behave unpredictably.

Terminal was working just fine with the service disabled until Windows Update applied updates today and restarted. All my other Microsoft apps still work just fine. The answers given don't seem to account for all the details given.

image

@julie777 commented on GitHub (Nov 10, 2022): > We've had approximately 500 users report that their keyboards don't work in Terminal, and in 98% of those cases it ended up being because they had this service disabled. Maybe it works for you without that service, but it turns out that it's an important part of the modern app infrastructure in Windows and shouldn't be disabled. It makes applications behave unpredictably. Terminal was working just fine with the service disabled until Windows Update applied updates today and restarted. All my other Microsoft apps still work just fine. The answers given don't seem to account for all the details given. ![image](https://user-images.githubusercontent.com/5090005/200975388-5add2478-99bd-4362-b10b-94c02bdc4bec.png)
Author
Owner

@julie777 commented on GitHub (Nov 10, 2022):

I just started the service and restarted Terminal. It still doesn't recognize keyboard input

@julie777 commented on GitHub (Nov 10, 2022): I just started the service and restarted Terminal. It still doesn't recognize keyboard input
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#11346