Эмуляция XBox-контроллера для геймпадов без аппаратной поддержки XInput.

В текущих реалия ПК-гейминга, современные игры поддерживают только XInput-совместимые геймпады, и только некоторые игры поддерживают DirectInput-устройства, и то, в основном применительно только к одному контроллеру — DUALSHOCK 4. Также стандарт DirectInput используется в различных гоночных и авиа-симуляторах, для работы игровых рулей и штурвалов.

реклама

Что такое XInput? XInput — это API, который позволяет приложениям получать данные от контроллера Xbox (или любого другого контроллера с аппаратной поддержкой XInput). Подробнее можно почитать тут.

А что же делать юзеру, если у него в арсенале оказался геймпад без аппаратной поддержки XInput, DirectInput-совместимый? Выкидывать геймпад? Продавать и покупать XInput-совместимый? Нет, это совершенно необязательно, потому что существуют различные варианты эмуляции XInput для DirectInput Only геймпада. Вот эти варианты мы сегодня и рассмотрим.

Сразу оговорюсь, эмуляторов DS4Windows и InputMapper, предназначенных для DUALSHOCK 4, в этой статье не будет. Для DUALSHOCK 4 существует отдельная статья в блоге, DUALSHOCK 4 в реалиях ПК, где эта тема раскрыта достаточно широко.

реклама

Вариант номер один — эмулятор x360ce.

Изначально эмулятор появился под названием «XBOX360 Controller Emulator v3.0 by Racer_S». Был он, мягко говоря, сыроват, пока его дальнейшим развитием не занялся пользователь с ником virus, обитающий тогда на сайте www.tocaedit.com. В дальнейшем всё это дело переросло в проект x360ce и существует по сей день.

Что представляет из себя x360ce эмулятор? Это кастомные библиотеки:

реклама

плюс файл с настройками:

x360ce.ini конфигурируете вы самостоятельно, конкретно под свой геймпад, с помощью утилиты из комплекта. После чего x360ce.ini и dll-файлы (как правило достаточно одного dll-файла — xinput1_3.dll) подбрасываются в папку с целевой игрой:

реклама

Настроек много и они не универсальные. Эмуляция может работать, а может и не работать, зависит от игры и подобранных настроек. Для 64-битных приложений, нужно использовать 64-битную версию библиотек. Если для вашего DirectInput-геймпада в системе не установлен драйвер с поддержкой вибрации, вибрации не будет и через эмулятор. x360ce не работает с UWP-приложениями.

x360ce-эмулятор был отличным решением несколько лет назад, но сейчас есть варианты поинтереснее. Впрочем, иногда он спасает.

Скачать x360ce можно тут.

Вариант номер два — XOutput эмулятор.

В XOutput принцип работы уже более продвинутый. При установке этого эмулятора, в систему ставится virtual bus driver (SCP драйвер-враппер, который также используют утилиты DS4Windows и InputMapper, для эмуляции XInput на геймпадах DUALSHOCK 4):

Но в отличие от заточенных под один геймпад DS4Windows и InputMapper, этот эмулятор всеяден и готов работать с любыми DirectInput геймпадами:

После настройки и активации эмуляции в системе (помимо нашего DirectInput геймпада) должен появиться XBox 360 геймпад:

Чтобы скрыть DirectInput сущность нашего геймпада от системы и игр, следует воспользоваться режимом «Exclusivity»:

должно стать так:

. по идее должно стать. Эмулятор достаточно капризный, в том, что касается эксклюзивного режима. Особенно на последних версиях Windows 10. Т.е. может и не работать.

Вибрации через эмулятор, даже если она поддерживается вашим геймпадом, и в систему установлен родной forcefeedback драйвер для DirectInput устройства, не будет:

У этого эмулятора есть неоспоримые преимущества перед x360ce: он работает в UWP-приложениях, он не требует никаких сторонних DLL-библиотек в папке с игрой, он легко включается и выключается, его можно добавить в автозагрузку, он работает с 32-битными и 64-битными приложениями.

Скачать эмулятор можно тут.

Также существует новая ветка разработки XOutput. Тут для полноценной работы потребуется другой пакет драйверов (вместо SCP) — ViGEm Bus:

Суть та же, но тут работа над софтом и драйвером идёт активнее.

Вот вам необходимые ссылки по новой версии XOutput:

И наконец вариант номер три — эмуляция XInput через Steam.

Steam поддерживает большое количество геймпадов «из коробки», т.е. не требуется дополнительных телодвижений для того, чтобы Steam распознал ваш геймпад, а точнее правильно определил раскладку кнопок и прочее.

Но нет ничего страшного, если ваш DirectInput-геймпад незнаком стиму.

Для того, чтобы для вашего DirectInput-друга, в играх из библиотеки Steam (или добавленных туда вручную), заработала эмуляция XInput (и прочие плюшки), нужно проделать следующие шаги.

Подключить геймпад к ПК, запустить Steam и перейти в режим Big Picture:

Перейти в пункт меню с настройками контроллера:

поставить галочку на «пользовательские настройки обычного геймпада»:

выбрать внизу, в обнаруженных контроллерах, ваш геймпад и настроить его в соответствии с подсказками на экране:

нажать «сохранить» и дать имя вашему геймпаду:

Всё. Теперь ваш геймпад поддерживается в Steam, и для него доступны все настройки для любой игры из библиотеки:

В играх (из библиотеки Steam) ваш геймпад будет определяться, как XBox 360 контроллер. Чтобы произвести дополнительные настройки по конкретной игре, нужно вызвать в процессе игры оверлейный экран Steam (кнопкой GUIDE) или комбинацией клавиш и произвести все необходимые манипуляции.

Scp virtual bus driver windows 10

nefarius released this Apr 10, 2016

Back-to-the-roots-Edition

First things first; this release breaks compatibility with older ones, please follow these instructions of you upgrade:

1. Make sure the ScpToolkit Clean Wipe Utility is selected in the setup:
   
2. Don’t run the Driver Installer at the end of the setup, finish instead:
   
3. Launch the ScpToolkit Clean Wipe Utility and hit the button:
   
4. Fire up the ScpToolkit Driver Installer afterwards and follow its instructions.

Now, for the stuff fixed:

• Every issue linked in this milestone
• Switched back from libusbK to WinUSB driver
• Added customized and signed WinUSB driver
• Updated ScpVBus.sys driver
• Signed everything
• Can’t remember
• Disabled update notification if no new version was found

nefarius released this Jan 10, 2016

• Fixed issue #140
• Removed misleading error message when disconnecting a pad

nefarius released this Jan 9, 2016

First-of-2016-release 🙂

• Added automatic updater
  
  
• Fixed some issues where controller inputs won’t get forwarded properly
• Added more error handling and logging in bus driver communication
• Fixed some issues in experimental Profiler where profiles wouldn’t get loaded properly
• Updated 3rd party libraries to latest versions
• Added switch to Settings Manager to toggle between synchronous and asynchronous HID Report processing

nefarius released this Dec 31, 2015

Last-of-this-year-edition 🙂

• Added settings switch for skipping occupied XInput slots
• Added settings switch for fully unplugging the virtual Xbox 360 controller device
• Added settings switch for disabling VBus events (for testing purposes only)
• Fixed some thread synchronization issues
• Added startup exception logging for Driver Installer
• Simplified XInput1_3.dll configuration and loading for PCSX2
• Fixed typos in Driver Installer
• Increased ScpMonitor main window width to display re-arranged lines
• Re-implemented driver guard
• Re-implemented storing profiles using an embedded NoSQL database
• Increased speed of connecting controllers via Bluetooth
• Disabled Service check box in driver installer since it’s an essential core component
• Some minor code clean-up and refactoring type names
• Implemented TaskQueue to speed up HID report parsing
• Fixed Tray App Windows visibility in Windows Task Switcher
• Added service start command to setup when finished installing
• Replaced ScpTimer with Rx pattern
• Fixed locking wrong object in Rumble methods (both DS3 and DS4)
• Fixed DS4 light bar colors and animation displaying only white when charging

Scp Virtual Bus Driver not signed on Windows 10 x64 build 14316 #266

Comments

psyke83 commented Apr 13, 2016

OS: Windows 10 x64 Build 14316
Release: v1.7.277.16103-BETA
Upgrade procedure: updated from v1.6.238.16010 using the procedure listed on releases page (ran cleanup utility before new driver installer).

Issue: Service fails to start due to dependency error. Checking device manager, Scp Virtual Bus Driver shows caution icon with the following status:

«Windows cannot verify the digital signature for the drivers required for this device. A recent hardware or software change might have installed a file that is signed incorrectly or damaged, or that might be malicious software from an unknown source. (Code 52)»

Booting with driver signature enforcement disabled allows the driver/service to function as expected.

The text was updated successfully, but these errors were encountered:

sylveon commented Apr 14, 2016

Maybe that the Certum root CA is not in your certificate store. Can you check?
Also, did you approved the dialog box that should show up when installing the VBus? The one that looks like that:

psyke83 commented Apr 14, 2016

I would have definitely allowed installation, but I don’t recall with 100% certainty seeing that dialog during installation. However, the certificate does appear to be installed, so it seems that I did. Here’s all certificates related to Certum:

sylveon commented Apr 14, 2016

Can you try a manual removal and then reinstall?

psyke83 commented Apr 14, 2016

I followed the manual removal steps precisely with no problems encountered (taking into account the libusbK -> WinUSB changes), uninstalled the package, then reinstalled the package and ran the driver installer. Unfortunately, no change.

Upon reinstallation/installing the VBus driver, I wasn’t prompted to accept installing the VBus driver — but I probably did accept it on the first install, considering that the author’s cert is listed in my Trusted Publishers.

I have a fallback Windows 8.1 x64 USB-bootable installation; I’ll try to install the package there and see if I encounter the same problem on the older version of Windows.

Edit: the driver installs correctly with no signature issues on Windows 8.1 x64. Back on the troublesome Windows 10 install, clicking on the author’s cert shows the certificate path (Certum Trusted Network CA -> Certum Code Signing CA SHA2) and says «This certificate is OK.». The certificate was issued recently, so I double-checked that my system time was set correctly. Anything else I can do to help diagnose the issue?

psyke83 commented Apr 14, 2016

I tried uninstalling and manually removing the author’s certificate, and reinstalled. I was shown the Windows Security dialog box and made sure to click «Install» as well as leaving the checkmark to indicate that the software from the author is trusted. No change.

I checked C:\Windows\System32\drivers\ScpVBus.sys. The properties for the file show that the digital signature is OK

Here’s the relevant event log:

Log Name: Security
Source: Microsoft-Windows-Security-Auditing
Date: 14/04/2016 16:24:46
Event ID: 5038
Task Category: System Integrity
Level: Information
Keywords: Audit Failure
User: N/A
Computer: satellite
Description:
Code integrity determined that the image hash of a file is not valid. The file could be corrupt due to unauthorized modification or the invalid hash could indicate a potential disk device error.

File Name: \Device\HarddiskVolume4\Windows\System32\drivers\ScpVBus.sys
Event Xml:

5038
0
0
12290
0
0x8010000000000000

psyke83 commented Apr 14, 2016

I’ve captured the relevant parts of setupapi.dev.log from Windows 8.1 (working) vs Windows 10 (not). Apart from timestamps, a quick diff doesn’t show any obvious difference that would explain the problem.

nefarius commented Apr 14, 2016

In none of my Test-Virtual-Machines ranging from Windows 7 to Windows 10 I had any problems with the signature. I’m downloading Windows 10 Client Insider Preview — Build 14295 English right now to see if I can somehow re-create this behavior.

Sadly there’s like a million advice posts on Google related to mysterious driver signature issues so I’m kinda at a loss to what I should recommend you to do.

psyke83 commented Apr 15, 2016

Thanks, nefarius. Tomorrow I’ll try installing this build (14316) in a VM to see if I can replicate the issue from a clean install state.

nefarius commented Apr 15, 2016 •

I tested it on a clean installation of Windows 10 build 10586:

I whacked together a small demonstration video (excuse the crude quality, I’m currently testing a new screen capture software) where everything looks fine.

sylveon commented Apr 15, 2016

No problems on build 14295:

psyke83 commented Apr 17, 2016

Thanks for testing. I installed the same build I’m running (14316) in a VM, and the driver works without any issue — so my installation must be corrupted somehow. I’ll run some SFC/DISM repair operations or find a way to clear the driver store to see if that helps. otherwise I’ll wait for the next Insider build and see if the upgrade solves the issue.

Will close the issue since it appears to be an issue on my end only.

psyke83 commented Apr 17, 2016

Actually, it looks like it may be an issue with your driver’s signing after all. Please check Event Viewer -> Applications and Service Logs -> Microsoft -> Windows -> CodeIntegrity -> Operational.

In the Windows 10 VM I set up, the virtual hardware is configured in BIOS mode (VMWare Player default), so event id 3085 was shown: «Code Integrity will disable WHQL driver enforcement for this boot session. Settings %1.».

My actual installation is running in EFI Secure Boot mode, so this event id was not logged. Once I disabled Secure Boot, your driver started working correctly.

There must be something wrong with your driver, as the previous version of ScpVbus.sys signed by another author worked in Secure Boot mode. I suggest that you install the Windows SDK for Windows 10 and check your driver/catalog using the signtool.exe.

nefarius commented Apr 18, 2016

@psyke83 weird, I do have the latest WDK installed and used it to sign, verification also seems fine:

But you do seem to be on the right track here; neither of my systems are running in SecureBoot, I’ll investigate.

sylveon commented Apr 18, 2016

I do have Secure Boot enabled on my laptop, and never got this issue.
Secure Boot only concerns the Windows EFI bootloader, kernel and critical system files.

If you try manually editing your Secure Boot database and reput the correct Microsoft public keys, it may do something. WARNING. I am not responsible for any damage done to your system by trying the following advice.

psyke83 commented Apr 19, 2016 •

When Secure Boot is enabled, instead of event 3085 (see earlier reply), event 3084 appears in the Microsoft-Windows-CodeIntegrity/Operational log:
«Code Integrity will enable WHQL driver enforcement for this boot session. Settings %1. Exemption %2.»

This is followed by event 3004 in the same log (almost identical to the security audit failure logged as event 5038 in the Security log):
«Windows is unable to verify the image integrity of the file \Device\HarddiskVolume4\Windows\System32\drivers\ScpVBus.sys because file hash could not be found on the system. A recent hardware or software change might have installed a file that is signed incorrectly or damaged, or that might be malicious software from an unknown source.»

I’ve ran the obvious checks — chkdsk and SFC found no problems, so it’s not a simple matter of a corrupted file.

If you enable Secure Boot, please make sure it’s working properly. Make sure to restart Windows and not merely shut down before changing the EFI setting (as the hybrid startup feature will continue using the previous EFI configuration until you do a full restart). Once you’ve enabled it in the EFI settings, msinfo32 should show «Secure Boot State: On»). I suggest that you see if whether event id 3084 or 3085 is logged on your system afterwards.

By any chance, was the previous version of the driver a user-mode driver, but your version is now a kernel-mode driver? That may be what’s causing the incompatibility — see: https://msdn.microsoft.com/library/windows/desktop/hh848062(v=vs.85).aspx

Regarding signtool, the output doesn’t show anything wrong with your signature — not even a warning. I captured this output while Secure Boot was enabled and the installed driver was showing the code 52 error (on the slim chance that the running system configuration can somehow influence signtool’s parsing of the result):

C:\Users\Conn>»C:\Program Files (x86)\Windows Kits\10\bin\x64\signtool.exe» verify /v /pa /c C:\Windows\System32\DriverStore\FileRepository\scpvbus.inf_amd64_711905c6c0fb8bc5\ScpVBus.cat C:\Windows\System32\DriverStore\FileRepository\scpvbus.inf_amd64_711905c6c0fb8bc5\ScpVBus.sys

Verifying: C:\Windows\System32\DriverStore\FileRepository\scpvbus.inf_amd64_711905c6c0fb8bc5\ScpVBus.sys
File is signed in catalog: C:\Windows\System32\DriverStore\FileRepository\scpvbus.inf_amd64_711905c6c0fb8bc5\ScpVBus.cat
Hash of file (sha1): AAF9C4AF0520AF2AFBDF79F70389CE7B443C5507

Signing Certificate Chain:
Issued to: Certum Trusted Network CA
Issued by: Certum Trusted Network CA
Expires: Mon Dec 31 13:07:37 2029
SHA1 hash: 07E032E020B72C3F192F0628A2593A19A70F069E

The signature is timestamped: Sun Mar 27 12:52:20 2016
Timestamp Verified by:
Issued to: Thawte Timestamping CA
Issued by: Thawte Timestamping CA
Expires: Fri Jan 01 00:59:59 2021
SHA1 hash: BE36A4562FB2EE05DBB3D32323ADF445084ED656

Successfully verified: C:\Windows\System32\DriverStore\FileRepository\scpvbus.inf_amd64_711905c6c0fb8bc5\ScpVBus.sys

Number of files successfully Verified: 1
Number of warnings: 0
Number of errors: 0