mirror of
https://github.com/safijari/openpuck.git
synced 2026-11-03 22:30:22 +00:00
[GH-ISSUE #278] Feature Request w/ code to get started - XBox 360 & XBox One Console Support - Connect Open Puck to those consoles as the native controller #126
Labels
No labels
pull-request
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
safijari/openpuck#126
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @Intoxicus on GitHub (Sep 6, 2026).
Original GitHub issue: https://github.com/safijari/openpuck/issues/278
I put my OpenPuck/Steam Controller into XBox 360 mode and went to connect to an actual XBox 360.
It doesn't even try to connect. I set the QAM button to be the Guide Button. The Xbox 360 doesn't register anything at all. I
The XBox 360 has been hacked for so long I would imagine any security issues can be overcome.
For all I know it actually should work and it's bugged out?
Either way I'm probably the first person to even try this and find out I would guess.
Definitely a low priority issue. But it would add a lot to have it.
@safijari commented on GitHub (Sep 6, 2026):
I have been told that it doesn't work with unmodified 360s. It should be possible as joypad OS does it but I haven't been able to test because I don't own a 360 unfortunately.
@Intoxicus commented on GitHub (Sep 6, 2026):
How do unauthorized 3rd party controllers make it work? I would be very surprised if it can't be made to work at all.
Perhaps 360 mode for Windows and 360 mode for the console will need to be different modes to make it work?
I would be willing to be your tester for this feature.
@Intoxicus commented on GitHub (Sep 6, 2026):
So I asked a Jippity. And I think it's easy to forget that because it's wired and not wireless we don't have the issue with MicroSlop's proprietary signaling. Because this is over USB, this should be not that big a deal. If there is a hitch it would be a encrypted/secure pairing/hardware addressing type stuff. The 360 has to be tricked into registering the Open Puck's 360 mode as a 360 controller. Windows just isn't as picky about devices claiming to be a 360 controller.
The link to the Google Doc is what a Jippity said would work. But I wouldn't be surprised if that's not quite correct, because Jippities are not actually AI and all that.
I wish I had the time/energy/capacity to flange this up myself. I'm on disability, genetic autoimmune disease, chronic fatigue issues. It's too much extra for me to try and contribute as much as I really really want to.
If you flange it up I'll test it for you.
https://docs.google.com/document/d/1SkCOAuNAS7TMgYB90EOcm0rm7uSYMenZ8zlvMfaMpQE/edit?tab=t.0
(Btw the doc title is the prompt for the Jippity.)
@Intoxicus commented on GitHub (Sep 6, 2026):
Again this is from a Jippity and may need to be fixed up.
This is supposed to be a code snippet for the USB Descriptor Security stuff that would be an issue.
The Fulll output is here: https://docs.google.com/document/d/1DjlMlS8VhqnCtM1zHV3lD8hp8aPMXr1dFefsXDSqTYc/edit?tab=t.0
#include "tusb.h"
// Strict hardware identity registers
#define X360_VID 0x045E
#define X360_PID 0x028E
// Custom Device Descriptor table forced to register as a Microsoft device
tusb_desc_device_t const desc_x360_device = {
.bLength = sizeof(tusb_desc_device_t),
.bDescriptorType = TUSB_DESC_DEVICE,
.bcdUSB = 0x0200, // USB 2.0 Specification Compliance
.bDeviceClass = 0xFF, // Vendor Specific Class (Critical for 360 console recognition)
.bDeviceSubClass = 0xFF, // Vendor Specific SubClass
.bDeviceProtocol = 0xFF, // Vendor Specific Protocol
.bMaxPacketSize0 = CFG_TUD_ENDPOINT0_SIZE,
.idVendor = X360_VID, // Microsoft Corp.
.idProduct = X360_PID, // Xbox 360 Controller
.bcdDevice = 0x0114, // Firmware revision version (matches original wired gamepad)
.iManufacturer = 0x01,
.iProduct = 0x02,
.iSerialNumber = 0x03,
.bNumConfigurations = 0x01
};
// Raw configuration byte sequence mapping out Interfaces 0 through 3 (Data & Security Handshaking)
uint8_t const desc_x360_configuration[] = {
// Configuration Descriptor
0x09, TUSB_DESC_CONFIGURATION, 0x30, 0x00, 0x01, 0x01, 0x00, 0xA0, 0xFA,
};
@Intoxicus commented on GitHub (Sep 7, 2026):
Also this lead me to figuring out a start point to make XBox One Controllers work too.
I want this to work so much I just might put some other stuff on hold to wrangle a Jippity into helping me make this flange proper.
https://github.com/safijari/openpuck/issues/239
Specific to emulating the Elite 2 -
https://docs.google.com/document/d/1QX_31G3TiHd5p7SRb-NzcQdv9O664GwmTlzeWOYnk3g/edit?tab=t.0
@Veri7ion commented on GitHub (Sep 7, 2026):
@Intoxicus https://github.com/InvoxiPlayGames/libxsm3
@Intoxicus commented on GitHub (Sep 7, 2026):
That is amazing! Thank you!
So I've seen other projects with Xbox 360/Xbox one support like I'm seeking for Open Puck.
Are they using this and I missed that?
Or are they do something similar in their own way?
Edit: they are using libxsm3, it's just not obvious unless you poke around.
I'm getting deep enough into this I probably will flange it up because I really want this for Open Puck :)
XBox One uses GIP instead of Xinput.
GIP resources:
https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-gipusb/e7c90904-5e21-426e-b9ad-d82adeee0dbc
https://gist.github.com/TheNathannator/c5d3b41a12db739b7ffc3d8d1a87c60a
@DragRedSim commented on GitHub (Sep 10, 2026):
I'd also look into how the Santroller project has implemented native behaviours. It's focused on the RP2-series platform, but it might give some hints. Alternatively, if you need an immediate solution, you could build a USB passthrough adapter on that platform.
I do note that the current implementation does not include certain elements which are required to even establish communication with a 360 console, namely the "Xbox Security Method" strings.