-
Notifications
You must be signed in to change notification settings - Fork 677
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Proposal: Add option to disable Xinput control on UWP Apps #1495
Comments
I see your point, that would be a viable solution for some people. However the problem I outline here is "Assuming that the user is not using his xinput device for something else its a bad User Experience, so this UWP auto map should be OPTIONAL" This only further perpetuates the stigma of UWP Apps not being as popular, its because of the little things you know? If this Mapping was System wide it could potentially be useful, however it is useless, since it only allows control for a tiny amount of the whole system. Whats the point of being able to control the StartMenu and The settings App, but you cannot navigate Windows Explorer? Either go All In or All out, and since it is not All In this feature should be optional since it Is incomplete. |
Yeah, I know. Microsoft is really bad at this. That's why many of their ideas fail at the entry level into the market. CE, Vista, 8.x (phone too), Silverlight, DUI, WinFS, and much more. |
To Windows team, UWP is the next application model after Win32. It's incomplete, yes... still in development, yes... Even for those reasons, they are not going to put a system wide settings to disable other input modals. WinUI can do it, if they want too, but if it does, it'll be a developers' choice for the app and not the users' choice for the whole system! You could find a registry setting or a feature flag so that you can disable them via the mapping app but that's just what the devs of the mapping apps need to do.
I feel you. It's the only thing I just REALLY HATE about M$FT. The commitment is just not there. we'll see if CShell based OS variants change any of these behaviors in coming years. |
The UWP version of Explorer is controller compatible. The old Win 32 version of Explorer isn't. It takes time to replace things. |
The worst part is that it doesn't just iterate XInput devices, which are typically better behaved, but it also seems to apply to DirectInput devices enumerated. This is a pain for me because my HOTAS throttle and sliders seem to control the navigation meaning I have to carefully center everything before returning to Windows, it gets even worse if I unplug the device the scrolling will go crazy and I will have to use keyboard shortcuts to reboot Windows. If this behavior is acceptable to be forced onto me and other users that I have seen with similiar bug reports just so a small number of users can control their menu's with their gamepad without giving the rest of us the option, then that pretty much encompasses everything wrong with MS. |
This only enforces my point. I'm not here to hate on Windows or Microsoft, I just want to help improve the products I use daily. This issue is not an open invite to random opinions, it's a formal proposal directed to the Windows UI Development team. It is their job to take it in consideration or not. @shaheedmalik start your own issue discussion thread. If this does not affect you please get out. @JoshWobbles Your last comment is not related to this proposal, please open your own issue. |
@joaodforce It all supports the proposal to be able to disable controller navigation, which if I am not mistaken is what you are asking for. But if you feel segregating votes for the feature just because our reason for wanting it is the best way to go, then ok. |
I wish we wouldn't need a proposal for something like this, it's basic UX. |
Unfortunately, this isn't something done by the XAML UI framework, so this GitHub isn't the correct place to track this feature proposal. Game controllers being promoted up to a form of keyboard input in UWP apps is done by a lower level of the input stack - XAML responds to these events, but the promotion, and thus ability to disable it system-wide, happens beneath us. The team that does own this part of the stack is not on GitHub, so I have filed an internal tracking issue with them. There isn't currently a way for you to track progress on that - but if you file a Feedback Hub report and send me the link, I can attach that Feedback Hub report to the internal issue. As far as I understand this, that would give you some (limited) visibility into progress. |
Is there any progress yet? Removing this crap shouldn't be that hard... (sorry for my language but it has been 7 months now and nothing happened..) |
@Austin-Lamb sorry I forgot to link it, I created an issue on the Feedback Hub https://aka.ms/AA91eep Nothing happened yet though... |
Speaking up here for the input team here, with apologies for not responding earlier. We have a process for WinUI to route input and composition issues over to us, but it looks like this one predated getting that process up and running. We're looking into what mitigation we could provide; it looks like a fairly simple thing to do, with this caveat: it would require an OS-level change, so it would have to be included in a future version of the OS, rather than an updated WinUI3 package. We'll keep this issue updated when we have line of sight on more details (e.g., a preview build to try out.) Just to be clear: the mitigation would likely be a session-wide (all apps) opt-in/opt-out. Default behavior would be to opt in, but users would have some way to opt out, ideally a full-fledged input setting. Apps would not be able to change this behavior programmatically. Let us know how that sounds? |
can you get yoru controllers device id and add it to the registry above and try it? then unpair and reboot (make sure to make a backup before you change anything that way you can restore. id be interested if it worked. just create the key and see if it works. |
Yeah this shit is not yet being pushed for mainline w10 |
This is the solution that has worked for me. Download the cab file "Microsoft - Game Devices, Other hardware - XBOX 360 Controller For Windows" Use 7-Zip to extract the cab file.
Open "control panel" and search for and navigate to "device manager". In "device manager", if you have an Xinput controller plugged in, when you scroll down you will Right click on "Xbox 360 Controller for Windows" and select "Update Driver Software". Click on "Browse my computer for driver software". Click on "Let me pick from a list of device drivers on my computer". Click on "Have Disk..." in the lower right corner of the window. Click on "Browse..." and navigate into the extracted folder from earlier that contains the driver. Select the "xusb21.inf" file then click "Open". Click "OK". Click "Next" then the driver should install. You will be asked to "restart your computer". You should be all set. Hopefully this will work for you. |
Is there still not a way to just entirely cripple UWP recognition of controllers? |
was HKLM\SOFTWARE\Microsoft\Input\Settings\ControllerProcessor\ControllerToVKMapping\ removed on Windows 11 22h2? |
Can't find the registry value nor any option to disable this. behavior. Happens 100% of the time on my computer when I unplug the controller, even if no button is being pressed when it is unplugged. Makes windows unusable until I reset the system using the power button. Guess I will install the old 2009 driver and see if VectorJons fix works. I wonder what causes this on only some users.. It's insane that this even happens. |
Does this fix not work for Xbox Elite Series 2? It tells me the 2009 driver is not compatible with my device. I have tried so many fixes for this issue at this point... I use my controller as a mouse because I have a disability which makes it difficult to use a regular mouse, so this issue is particularly frustrating to me as I'm using my controller all the time. |
@Gavin-Gomel-Dunn |
How is this not fixed on Windows 10 yet? Useless |
Windows seems to generate key events with VK Codes of 0xC3 to 0xDA when you use a controller on a UWP application. Since there is still no way to officially disable this in Windows 10, I ended up just making a small application to add a Low Level Keyboard Hook and remove key events with those codes. |
To anyone still having this issue in windows 10 for apps like controller companion, THIS worked. To summarize for basic layman googlers in need of help: If you aren't sure if you are looking at the correct device, unplug any other controllers that are plugged in, go to the properties of the device you suspect to be the correct controller, go to the "details" tab, and select "is connected" It should say "true" every device that isn't the the one that's plugged is should say "false". Hope this helps! |
its not really nonsense if you used it to disable xinput for your own device. also, below my original post with the registry entries, i also suggested for someone to fill in their own device id and test it. congrats, youre the first to change it and come back here to confirm that it works for other devices than just the ds4. i do not have other controllers i can test with. all i have is a v1 ds4. so thanks for that! but thanks for the feedback. please send an email thanking the original developer that helped come up with this. |
I don't know if it's unique to 360 controllers or Xbox Series X/S controllers (what I'm using), but the compatible IDs section is blank for me whether I'm using the wireless adapter or directly connected via USB such that I'm not even able to attempt this. |
Anyone know the status on this? It seems like one of the most popular issues on here yet it's been open for 4 years and no one's taken the time to add a ticker box in the control panel to just let us disable this. I'm trying to create my own Xinput navigation and the forced windows controls make it impossible. I can't rely on complicated registry edits even if they do work because I can't expect users to go through that process to get a script working. What am I supposed to do? |
From reading most of the replies to this thread, it seems there are some 3rd party tools and workarounds that can get around this problem. Even though having an oficial 1st party solution would be ideal the maintainers of this repo made it clear that this GH Issue is not the place to get this issue resolved, even thought there has been a clear history of changes in old versions of windows because of this thread. I recommend everyone that is still facing this issue to make your voice heard on the Windows Feedback Hub. |
LOL
Can't even access it anymore, so much for that. |
HKLM\SOFTWARE\Microsoft\Input\Settings\ControllerProcessor\ControllerToVKMapping |
It does. |
This works for me. I only run it after the xbox controller bugs out and I get the phantom "up" input in all UWP apps, which prevents you from typing or doing anything in the start menu. |
I finally found this after months of suffering phantom inputs in the Start Menu app and Settings apps. Makes the Windows desktop almost completely unusable, even if you already have a nice solution like Gopher or Xpadder. A controller is 0% usable on the Windows desktop by itself. You need apps like Gopher, Steam, or Xpadder. But they conflict with Windows' "half-baked controller support" that is UWP controller support. So it's just a virus - I say instead of offering a way to toggle the controller in UWP, just rip this crap out. But I know that won't happen, so PLEASE at least offer a way to turn it off! For users sake!! |
Nope didn't happen in 5 years so there is no chance they would give us a feature toggle now. Since Windows 7 it became clear, that M$ does not develop Windows for consumers, but for ad-companies. |
I was using But I recently updated to 19045.4651 and this registry setting no longer has any effect. I've had to resort to unplugging my controller (from USB port). (If you need to know why I have to unplug the controller, let me know, but it's a hardware issue not related to this registry key directly.) So was there a regression? |
I can confirm a regression on this in the 10.0.22621 Build 22621 |
Proposal: Add option to disable Xinput control on UWP Apps
Summary
Later Windows 10 builds, automatically use Xinput devices to control UWP Apps, and some parts of the Windows UI. However this approach proves to be troublesome, because assuming the device is not being used results in terrible experiences.
Rationale
Scope
Important Notes
This issue has been brought up before many time, following bellow are some examples
https://steamcommunity.com/app/367670/discussions/0/2828702373004583436/?ctp=3
MicrosoftDocs/windows-dev-docs#1882
MicrosoftDocs/windows-dev-docs#622
https://answers.microsoft.com/en-us/windows/forum/all/how-do-i-completely-disable-xbox-controller/b4f63e59-f1a1-4b75-9525-c39c94468a66?auth=1
https://superuser.com/questions/1173133/disable-xbox-one-controller-in-uwp-apps-like-windows-store
The text was updated successfully, but these errors were encountered: