[Q] Could tinkering with HID (mini)driver be of any help?

[mirh]

In particular I'm referring to the idea implemented here https://www.julianloehr.de/educational-work/hid-wiimote/

I see it might require to reinvent the wheel, but I was wondering if the concept could at least be of any use. EDIT: additional juicy stuff here

[sylveon]

Having a driver that you could simply install over the original driver and everything works... That'd be my dream.

It would be waaaaay much easier to simply install a driver over the original controller driver instead than having to install a suite of tools, servers, configuration utilities, etc...

A bit like Android ADB drivers. Install over the original drivers and forget about them. No external dependencies, just a .sys, .inf and .cat file. That you can also delete after.

I really hope someone has that idea and makes it real one day.

[jloehr]

Whats the problem anyway? As long as the controller/devices successfully connects via Bluetooth or USB and exposes one Bluetooth Profile/USB Device Class, you can replace that Device Driver or inject a Filter Driver (or in case of HID a minidriver).

[mirh]

Oh, hey there :s The problem now is that different USB and Bluetooth device drivers are required. And I found your HID minidriver concept way more elegant and functional.

[sylveon]

A PS3 controller won't connect directly to Bluetooth. A special Bluetooth driver is required. And I don't have enough knowledge to write a driver, either for Bluetooth or the PS3 controller.

And I found your HID minidriver concept way more elegant and functional.

Same here

[jloehr]

Ah ok, yeah then the Device/Filter/Minidriver Concept doesn't work.

[mirh]

.-. It doesn't connect directly for the same kind of reasons a Wiimote don't tbh.

[sylveon]

On my computer, a WiiMote connected directly to my Bluetooth, without any special drivers (using the Windows default drivers). FYI

[jloehr]

Yes the default Bluetooth Driver can pair it. However it reports all of its HID Reports as "Vendor defined". So you need a driver or third party tool to actually use it as gamepad. When you check the USB Gamepad Properties, you'll see, that the gamepad has no buttons and inputs whatsoever. That paper about the PS3 Controller is quite interesting. So correct me if i'm wrong, you first need to connect it via USB to set the Bluetooth radio address it will connect to. And then you also need to send some special message after it paired to enable it?

[mirh]

Yes, that's how I'd describe DS3 functioning (which works out of the box in linux and some droids btw) Iirc instead DS4 should even support normal HID protocol (plus its special "ps4 mode")

[jloehr]

Ping: @Gooberpatrol66 #293

For the USB connected Controller, one could write an driver to set the Bluetooth Address, but as long as it also works with an User Mode App... A driver would load faster and only run when a device is connected, contrary to a background service, that is running always or does need the user to do something. However a User Mode Service may have other advantages, biggest one is it does not cause any BSODs. So imo a driver is not worth the work. Although that may change if the cable bound controller should be used in a cable bound manner, but that's another story.

I assume when you set the Bluetooth Host Address via USB cable, the controller will connect fine via Bluetooth and is present as Bluetooth Device and its HID Profile as HID Device, isn't it? The only issue then is, it won't sent any data as it needs the special HID Message to start its "operational mode"?

If so the concept of providing a device driver for the Bluetooth connected controller is viable, so you won't have to replace the dongle's driver.

1. You can either add a Filter Driver between the HID Class/HID Minidriver and the Bluetooth Stack to inject the HID Messager. You would need to inspect the BRBs to know when it is save to inject the HID Message.
2. Second option would be to replace the HidBth Minidriver (as me with the Wiimotes). Then you would basically rewrite the HidBth Minidriver with the only difference of the special HID Message beeing sent somewhere in between.
3. The third option would be to replace the HID Class Driver altogether and provide a custom interface to read and sent data to/from the controller. (such interface could also be implemented with the second option.)

With 1) and 2) the controller would be enumerated by the HID Class Driver as HID Controller. As the XUSB driver also enumerates each XBox Controller as HID Controller, each controller would show up twice (for DirectInput). With 2) and 3) one could directly enumerate another child device and load the XUSB driver for it. Then the driver would be able to directly feed the input data to the XUSB driver without the detour via the User Mode Control Center, back to the SCPBus, etc. That may also be an idea for all the other Controllers (DS4 and cablebound controllers). This is btw. what i am planning for my Wiimote driver to make them available to XInput Games.

[sylveon]

http://dancingpixelstudios.com/sixaxis-controller/sixaxispairtool/ Sadly, when my Bluetooth radio's MAC is set as host, my SixAxis controller won't show up in the Bluetooth control panel. The controller will search (light flashes) for it's host for ~1 minutes, then shutdown. It won't even pair.

Even if I use ScpToolkit to do the initial pair (Install the WinUSB Bluetooth driver, pair it via USB, then reinstall the OEM Bluetooth driver)

[nefarius]

@jloehr hey hey, nice to see you here, love your work!

Ok it seems like I have to clarify a few things. Here we go:

• Until about three month ago I never did actual driver development (the Toolkit 100% user-mode and ~90% .NET) and simply adopted the original idea of the creator of ScpServer to use general-purpose device drivers like WinUSB (switching to libusbK was my mistake; I attempted to solve a problem with it that had a complete different cause, well, you always learn something new...) and implementing all the protocols within .NET and the Windows Service. This had the advantage that rapid development was possible; compared to kernel-mode stuff testing .NET apps is easy. Anyways, this has now changed. Thanks to Shaul my interest in developing actual kernel-mode drivers was lit an I dedicated every single free moment of my time learning and experimenting. I rewrote the ScpVBus.sys (Xbox 360 controller driver) in KMDF as my playground and just recently added a working DualShock 4 emulator to it. I also began to implement a USB<->HID driver for the DS3 so in a somewhat distant future the toolkit won't be required anymore for out-of-the-box DS3 HID support.
• In USB mode the DS3 requires some additional control requests sent to it so it will start sending HID reports. It might even be possible to get away with a filter driver to add this functionality but I have to test this first. Once it starts sending it uses standard-conform HID input reports. The DS3 doesn't support pairing via common ways; the Bluetooth host`s MAC it shall connect to has to be sent to the DS3 once over USB via control request. That's why it won't pair with default Windows Bluetooth stacks.
• In Bluetooth mode it uses a custom protocol via L2CAP so maybe also a filter driver could solve this but again, I'm at the beginning of my kernel-journey :)

Hope this sums it a with not too much rambling.

[sylveon]

Once you get the USB<->HID driver a bit working, I'd be glad to help testing it.

[mirh]

Looking also forward to Jays2Kings/DS4Windows#123 d:

[nefarius]

@mirh Ohohohoho interesting! rubs hands

[nefarius]

We have some progress!

[sylveon]

@nefarius Neat!

Won't the fact of having it using DirectInput make the controller not work in some XInput-only games?

[nefarius]

@charlesmilette no worries; I've got that covered too :wink: