feat(onexplayer): add ONEXPLAYER 3 support - #660
Conversation
|
Does this device have any strange serial devices in /dev?
Thanks |
|
No Serial devices, just regular TTYs.
Sorry for the formatting here let me know if you prefer a pastebin or something. Also some extra devices will show up because I have the OneX 3 plugged in through a docking station at the moment
Actual device "/sys/class/leds/go:rgb:joystick_rings"
|
4b32dad to
7b6aeec
Compare
| name: Microsoft X-Box 360 pad | ||
| phys_path: usb-0000:00:14.0-7/input0 | ||
| handler: event* | ||
| - group: keyboard |
There was a problem hiding this comment.
One final improvement that could be made would be to only report the events we actually care about from this device, specifically the ones in the capability maps. That would ensure that dozens of extra events don't show up in the input test UI or in other UI that probe InputPlumber for capabilities aren't cleared with events that we won't ever get.
Here's an example from the MSI class config.
7b6aeec to
742d487
Compare
| - keyboard: KeyLeftMeta | ||
| target_event: | ||
| gamepad: | ||
| button: QuickAccess2 |
There was a problem hiding this comment.
Before I finalize this, I'd like to make sure we're consistent here. I've been working with another user on the x2 mini pro: #672
There we did the opposite, where ONEX was set to QAM and keyboard (labeled options here) was set to qam2. I'd like to remain consistent here. The configs are the same so I'll probably end up dropping type10 there once this is merged, I've only got it labeled differently to avoid merge conflicts.
Is one on the left and keyboard on the right for the 3? If so, let's swap them here. That will be consistent with other devices in the lineup and other manufacturers.
There was a problem hiding this comment.
They are yes, so I'll swap QA and QAM2.
This leaves the "home" button on the left a bit weird since I think Bazzite maps it so it wants to use it as the keyboard button but it's consistent with what you have setup right now
|
After working on the x2 mini pro I had some insight into the left paddle it working here. There it was the right paddle not working, then some odd mapping after the controller is out into wireless mode with the dongle and reattached. It also has two fe00 interfaces, one for each controller. Given that these are so similar, I'm inclined to cherry pick this into my x2mp branch and merge them together once we figure out the interface fully. I've already made the necessary changes to load the second interface in the hid-oxp driver and have an email out to OneXPlayer asking for further details. We also need to figure out the wireless config for both. |
Add the DMI autostart match, composite device profile, and extra-button capability mappings for the ONEXPLAYER 3. The profile and mappings were generated with OpenAI Codex assistance, then reviewed and verified interactively on ONEXPLAYER 3 hardware using evtest and InputPlumber. Validation included the full test suite, clippy, YAML parsing, and the autostart configuration test. Co-developed-by: OpenAI Codex
742d487 to
1f2b129
Compare
Add the DMI autostart match, composite device profile, and extra-button capability mappings for the ONEXPLAYER 3.
Hardware tested
045e:028e1a86:fe00Known limitation
The left rear paddle does not emit an input event while the device is in its normal XInput mode with the current
hid-oxpbehavior. The right rear paddle works. This appears to be outside the InputPlumber profile and is not worked around in this change.AI assistance disclosure
The profile and mappings were generated with OpenAI Codex assistance, then reviewed and verified interactively on ONEXPLAYER 3 hardware using evtest and InputPlumber. Validation included the full test suite, clippy, YAML parsing, and the autostart configuration test.
Co-developed-by: OpenAI Codex