Controller inputs not working with Full Screen Experience.

[exochat16]

Microsoft launched fullscreen experience, which basically allows windows to be navigated entirely via controller. This is a must for a setup that cannot/shouldn't use touchscreen controls (I.E simulating a console like experience on PC).

Unfortantely, duo inputs do not function in fullscreen experience. The only working input currently is the xbox button, which allows quick navigation, but no input renders that function useless. Isolate Steam toggle has no effect. Duo also disables FSE inputs for all connected instances, including host.

[exochat16]

It appears that duo currently breaks FSE input even after removing it, requiring a fresh install/update of windows to repair it again.

[Black-Seraph]

Duo has no kernel sided component, and as such is limited to existing userspace Windows APIs.

If Windows doesn't want to give us control over something, we can't forcefully take it, and the goalpost keeps getting moved with every new Windows feature update, so update to the latest bleeding edge Windows builds at your own discretion.

There really isn't anything I can do about this.

You do mention the XBOX button though, which strongly hints at you using an XBOX gamepad, which means you're using the xinput driver.

XBOX gamepads differ from other gamepads by having their own dedicated input driver, which, unlike the regular HID input driver, doesn't support suspending.

It is strongly suggested to stick to regular HID gamepads where possible, for example Dual Sense gamepads, as they properly suspend and resume, which is required for HID isolation, or accept your limitations and disable HID isolation entirely.

The breakage you describe probably stems from Windows' VK translation layer, which Duo forcefully disables as it completely ignores Microsoft's own Session ID attribute.

[exochat16]

Understood, and thank you for taking the time to make a response. I subbed on the patreon, even though I cant use it yet I think this is an amazing resource and opens up a world of possibilities.

I say xbox but this is an aftermarket gamepad from Amazon. The button described functions like the Xbox button. Ive tried with a few different gamepads with no success either.

Any temporary suggestions? Can the windows VK transistion layer be re-enabled after Duo processes the session or must it remain disabled?

[Black-Seraph]

@exochat16 This description is a bit technical, but I hope you can follow me.

Windows has a few kernel objects one can instantiate to do a variety of things.

One of those object types is a session, a group of processes that share a common global context.

Another one is a terminal, which can be attached to a session, this is what links a user account to a set of processes, Windows currently supports 3 terminal types, service, console and remote terminals.

Another object type is a device object, there's one or more for every virtual or physical device attached to the system, and assigned to those device objects are device properties.

One of these device properties is the device session ID, which lets you configure which sessions are allowed to see and interact with a device.

This is the only way Windows allows us to bind devices to sessions, and its very limited.

And, worst of all, some parts of Windows ignore it entirely, one of those parts is the VK translation layer, which Windows uses internally to translate gamepad input into keyboard keys.

And, as you can see, FSE works with keyboard inputs internally... so, when Duo disables the VK translation layer, FSE stops receiving input, as its waiting for keyboard events, which originally were produced by translating gamepad input into keyboard events.

Given how Duo was designed way before FSE was a thing, and how few applications actually adopted the VK translation layer, it was a no-brainer to just disable it as part of the Duo setup and never look back.

The real issue however is that, with the VK layer enabled, many applications will experience gamepad bleed, which renders Duo useless for actual gaming use while it is enabled.

The best middle way out I see is to restore the default VK registry key whenever the Duo service stops, that doesn't fix the issue, but at least allows FSE to function while Duo is stopped.

I've added these changes to the 1.5.5 release candidate, which should alleviate the issue a little.

The real solution to all of this would be to write a kernel device filter driver though, but we have no way to actually sign one, and as such can't really ship one without the backing of a willing donor company.

[exochat16]

Thank you for the response!

If it helps, in my case controller bleed wouldnt be an issue, as i would use one device for keyboard + mouse (as a PC) and another with controller (as a console, assuming keyboard and mouse input doesn't bleed over like a controller would)

So a toggle option to keep VK enabled while in duo would work great for me.

I wouldnt mind being the guinea pig and reporting back for this. Which VK registry key does duo disable?

[Black-Seraph]

The proper solution for this would be to write a kernel driver to deal with all of this, or, a userspace verifier patch to generate in-software gamepad input while filtering out console session gamepad data.

The real issue with this is that several anticheat systems, and possibly antivirus tools, will scream at us.

I'm at a personal breaking point where I'm so close to just dropping the anticheat system concerns and going for a global userspace verifier patch implementation, as that would give us so many benefits in the long run.

[exochat16]

These days basically everything triggers an anti-virus warning. Your reputation and github visibility shouldn't concern anyone.

Can't speak for others on anticheat, but could always make a branch that distinguishes later releases as anti-cheat flagged and let the user decide. For me personally, I play mostly steamdeck games, which are also locked out of anticheat games.

If an industry Titan like Steam doesn't let anticheat hold them back that should say something, and if it makes it easier I'd go for it. But up to you and your audience.

[Black-Seraph]

@exochat16 I came to the same conclusion, but am a proponent of user choice, so it still bothers me whenever I'm forced to implement a fix one / break one change.

But yeah, it does look like Microsoft and the industry as a whole doesn't really give us a choice but to go all in or all out.

I'm currently looking into some undocumented functions I've found in ntdll.dll that seem to be virtual gamepad siblings of the already existing keyboard, mouse and pen input API, which would make for a near perfect implementation as those are isolated by default.

Time will tell which way we have to go though as I slowly reverse engineer more Windows components and get a better read on its inner workings.

[IdeeFX]

Hello,

I ran in the same issue as exochat16 where installing duo broke all controller support (with only xbox button still working). Of everything i tried (desintalling duo, updating gamepad frimware, reinstalling Vigembus) only a reinstall of windows fixed the issue which of course is not ideal. I am running latest version of windows 11.

I am not very tech savy so i didn't understand much of the exchange in this ticket but i got that the fix is not easy and/or the issue to pinpoint.

In the meantime, would it be possible to provide a workaround that wouldn't involve a windows reinstall ? As it is, i am too wary to install duo to try it out.

Thank you for your time.

[Black-Seraph]

@IdeeFX I haven't been able to navigate myself into a situation yet where Duo permanently breaks gamepad input, but if you can provider a 100% reproducible way of triggering such a situation I'd be happy to take it from there and debug it.

[exochat16]

@Black-Seraph This is something to do with the windows 11 fullscreen experience. If you enable the full screen experience in settings and turn on Duo you will see the issue.

My current work around is launching Kodi on startup of a new moonlight instance, then using that as my main navigation route to open everything else on my PC instead of fullscreen experience, but its not ideal as I loose out on all the good features of FSE.