fix(Hardware Support): Add 8bitdo Pro3 - #624
Conversation
Blocking the DInput evdev seems to be enough to get this controller working, might be able to reuse support for the 8bitdo ultimate 2 when that is merged, as the controllers are functionally very similar
pastaq
left a comment
pastaq
left a comment
There was a problem hiding this comment.
This is the opposite of what we want to do. By blocking the evdev without an hidraw driver we are losing all input for this controller through InputPlumber. It doesn't make sense to ship a config to bypass InputPlumber within InputPlumber, and it removes the ability for OpenGamepadUI to see the input and open the quick bar.
The actual problem is that SDL is directly reading the hidraw as well, so blocking that instead will prevent the duplicate input issue and allow evdev events to propagate through InputPlumber as expected. Then, once a driver is written for it, we can flip the block to this pattern for the full functionality provided by the controller.
| vendor_id: 0x2dc8 | ||
| product_id: 0x6009 | ||
| interface_num: 0 | ||
| # XInput/Receiver Mode |
There was a problem hiding this comment.
This section is carried over from the ultimate 2 and should be removed
|
not blocking the evdev device and instead block hidraw resulted in
so i guess just moving the config to bazzite would be the best solution for now and then when you're back from vacation i can try help with anything you need for getting a proper driver made. evtest shows it as dinput (makes sense since the switch on the controller in order to use steam input native requires you to set it in dinput mode) and in terms of losing the intercept for ogui, i think for the average user its more important they have a functional controller over (hopefully) temporary losing ogui interception of buttons. especially for the popular 3rd party controllers like 8bitdo, gulikit, flydigi, etc. But that config would make more sense to have on the distro side until a hidraw driver is made and i had misunderstood you in earlier discussions. |
|
It might be as simple as adding the capability_map_id for dinput_generic to the controller |
2 participants
Based this on the 8bitdo Ultimate 2 file as @pastaq suggested.
Blocking the DInput evdev seems to be enough to get this controller working, might be able to reuse support for the 8bitdo ultimate 2 when that is merged, as the controllers are functionally very similar.
Without this, the controllers inputs are messed up
If there is anything else i can provide to get proper support added, i am happy to provide it