I can connect a Sony DualSense (PS5) controller to Windows via USB or Bluetooth.
The HTML5 Gamepad API recognises the DualSense whether I connect over USB and Bluetooth work with https://gamepad-tester.com/
However with XInput the DualSense only works over USB. Over Bluetooth, nothing happens. https://thatsmytrunks.itch.io/xinput-controller-tester
Why is that? And can it be fixed? I tested an Xbox controller with XInput, and it works over either USB or Bluetooth.
DualSense isn't recognized through XInput because it's not an XInput compatible game controller. XInput is a legacy interface for Xbox 360 and Xbox One controllers and isn't compatible with HID gamepads.
You can run software like DS4Windows that will create a virtual XInput device that mirrors the inputs from a compatible controller. DS4Windows works with DualShock4, DualSense, Switch Pro Controller, and Switch Joy-Cons.
Applications that don't need compatibility with versions of Windows earlier than Windows 10 should use the Windows.Gaming.Input API which has built-in support for HID gamepads (including DualSense).
DualSense works in Chrome because Chrome uses the Windows HID API to read inputs from HID gamepads like DualSense.
Related
I have a Wemos D1 Mini (ESP8266), flashed with WLED and I want to create an application like .exe and have control on turning it on/off and choose colors. Does anyone have any idea how I can do without to connect on wifi and just do everything via USB?
To control the WLED firmware over USB, you would use the firmware's ability to be controlled over a serial connection. It looks like you would open the virtual serial port that appears when you plug in the device, at a speed of 115200, and then you take the same JSON that you would POST to /json/state for controlling it over WiFi, and instead send it over the serial connection, and get your responses back over the serial connection.
You could also implement the TPM2 protocol, or the Adalight protocol (which doesn't really seem to be documented except in code), as those are also supposed to be supported.
If you want to do all this in C++ on Windows, you might start by reading the (very old) Windows tutorials for Win32 API serial port programming. If you only want to target Win10 or newer, you could learn C++/WinRT and then use the new WinRT serial APIs. Or you could consult the answers to this question about serial programming on Windows.
I've got Windows 10 Creators Update and am writing a UWP C++ app. I've tried with both C++/WinRT and C++/WRL and it seems that Windows.Gaming.Input.Gamepads just refuses to see my wired XBOX 360 controller and my Logitech XBOX 360 style gaming controller. Both are old, but they do show up in device manager as XBOX 360 controllers, and both work with other games. I've XInput, but XInput could only see the Logitech, and not the Microsoft controller. I would have thought the newer API would have picked them up. But here's the crazy part. Both controllers work fine in Microsoft.Minecraft, which is a Windows store application, so, by the store rules, I thought only XInput and Windows.Gaming.Input.Gamepads was supported. So the question is, really, what API could they be using, that recognizes both joysticks, and why wouldn't Microsoft Windows.Gaming.Input work with a Microsoft joystick?
I'm trying to emulate a xbox 360/one controller using a HID device that is already connected to the PC.
I can read data from it and I will have to map it to the XInput structure.
Is there another way to do this without building a virtual driver to simulate a game-pad and using a feeder to send in the input from my own HID device?
Development is done using Qt5.4 and C++.
is it possible to tap into the USB drivers / resources with a windows console app (win32 c++)?
i would like to detect connected hardware, send and receive midi from my USB keyboard.
but i don't want to build a complete GUI app for my small needs to test my own hardware on perf board.
the main purpose is also to test the software written for the pic microcontroller, it's much faster debugging, rather than compiling and running with the chip from zif socket tot zif socket.
i need some directions, thank you.
This is possible. For midi keyboards, check the midiIn... functions
Im trying to get the output from a Wii Fit (balance board). I can find the device via the C++ Bluetooth enumerators but attempts to connect via a windows socket are failing.
Im wondering if anyone has had success in such a direction (C++, windows) I'd love to hear how you did it.
The Wii Balance Board is a HID device. To understand communications with the Balance Board, you need to know a little bit about Bluetooth HID. There's good information on WiiBrew about the Wiimote and the Wii Balance Board.
I don't think you can use Windows Sockets to connect to a HID device. The Windows Socket Bluetooth interface only allows you to connect to RFCOMM-based services. HID is based on L2CAP which is further down the Bluetooth protocol stack. There's some information at MSDN about that limitation.
If you're just looking to hack around with it, you can try Bluecove for Java. You may be able to do something using another stack (for example, Widcomm). If you're locked in to Windows and C++, you may have to look into writing an custom HID driver for the Balance Board.
As pwc said there is a limitation in the MS Bluetooth API, so with sockets you cannot have something else except RFCOMM, but this doesn't mean you cannot go down at L2CAP layer. What you have to do is to implement a client profile driver and you can use as starting point an article from MSDN: Creating a L2CAP Client Connection to a Remote Device and vice-versa: Accepting L2CAP Connections in a Bluetooth Profile Driver
Next of course as pwc said you have to study Bluetooth HID and WiiBrew for the communication protocol.
Also a good document to read is Bluetooth Wireless Technology FAQ - 2010 which states clear that it is possible to have L2CAP connections with Microsoft Bluetooth stack driver. Of course not with sockets.
When using HID on a Bluetooth device there is generally no need to create a L2CAP connection directly. All(???) of the Bluetooth stacks on Win32 have support for Bluetooth HID and provide access to the HID stream/control through the native Windows HID API. No (direct) L2CAP required! :-)
On WinCE there is built-in support for Bluetooth HID also, but I'm not sure there's a way to access a HID API.
That's how Brian Peek's wiimore library works -- it uses the HID API. The good thing about that is that one gets supports for all(?) the Bluetooth stacks that way -- they each support HID devices via the Windows HID API, whereas to use L2CAP directly one would have to support each of the stacks' APIs... (That's if they have one! BlueSoleil has no L2CAP API as far as I can see).
So, on Win32 one should just pair with the device and check that the HID checkbox is checked on its Bluetooth Service control panel tab (whichever Bluetooth stack is in use). In my 32feet.NET library one can discover the device and then ensure that HID is enabled for it with:
BluetoothDeviceInfo[] list = btCli.DiscoveryDevices();
var deviceInfo = list[n]; // Select the correct device
deviceInfo.SetServiceState(BluetoothService.HumanInterfaceDevice, true);
(That should work on MSFT and BlueSoleil; there's no API for that on Widcomm AFAIK -- although when paired it might be automatically enabled anyway).
The one possible exception case is that apparently some devices are not fully compliant with the Bluetooth/HID specs, I'm told the PS3 blu-ray controller is like that. Then one might want to try L2CAP connections directly -- however its likely that the stack's support for HID will interfere with third-party applications trying to provide the same service...