search

xenia-project / xenia

Xbox 360 Emulator Research Project
https://xenia.jp
Other
8.3k stars 1.14k forks source link

[Feature Request] Re-add the keyboard passthrough function. #2027

Open Hasster1 opened 2 years ago

Hasster1 commented 2 years ago

Yeah, i know that it was implemented in canary builds, but since February of this year, it's gone from canary. So here i am, making an issue about it, because nobody else would.

Triang3l commented 2 years ago

The problem with anything related to the input at this point is that our current input architecture is a conflicting mess, all the things like the SDL backend, faking the controller with the keyboard, were added in a very hacky way on top of what was likely originally supposed to be a simple XInput proxy that was just enough to get something to work with controller input.

Anything that involves managing the connection of the input devices simply can't be implemented cleanly and in a way that won't make the current system even more fragile with the current state of the input architecture.

The proper design would include being able to build the four guest "controllers" from host components, that would consist of the API and the exact host device exposed by that API. This includes the gamepad (XInput, SDL2, xe::ui::VirtualKey keyboard bindings), the keyboard (XInput for the keyboard connected to a real Xbox 360 gamepad, xe::ui::VirtualKey passthrough that should also be incompatible with the bindings), the speaker of the headset, the microphone of the headset. For easier configuration, it should also be possible to have "linked" components provided by one API, so, if the user enables this behavior for the guest controller slot, that slot would automatically use the keyboard and the headset implementations provided by the API that also handles the gamepad they're physically connected to on the host — specifically for XInput, which exposes the physical Xbox 360 controller as a whole.

Basically, we need a concept of a "host device" provided by a host API, and that device should be able to implement the various (to simplify implementing linked host components) interfaces physically supported by it (gamepad, keyboard, headset input/output).

ca5dx commented 2 years ago

Can no longer use the Saints Row developer console with this option removed, needs reimplementation.

Wastelander121 commented 1 year ago

+1 Can no longer use Arkham City or Origin's debug console without keyboard passthrough.

diamante0018 commented 1 year ago

Without this, I would be unable to use the in-game console on any development build of Call of Duty games which takes away one of the most fun things to do when using Xenia for the purposes of running exclusive builds that were never officially released to the public.

AdrianCassar commented 1 year ago

This feature is currently a PR on canary it can be found here.

I have tested it with COD4 and it works, but for MW2 and MW3 dev builds the characters are not inputted into the dev console, the PR needs improving. However, I got the dev console semi-working with MW3 by creating a mod.

diamante0018 commented 1 year ago

This feature is currently a PR on canary it can be found here.

I have tested it with COD4 and it works, but for MW2 and MW3 dev builds the characters are not inputted into the dev console, the PR needs improving. However, I got the dev console semi-working with MW3 by creating a mod.

On MW2 and MW3 they introduced a dvar "con_monkeytoy" which even on debug build where the console would be available it's impossible to open it. This theory could be confirmed by going through the .cfg file where the game store the saved values of these settings (dvar, which used to be called cvar in Quake III). When the dvar is disabled the console should open, that's how it works on release PC builds, but there are no publicly available debug builds for PC to test this theory definitely.