cvuchener
Upstream
Is this one in the process of being upstreamed? If not, can you point me to the blocking points?
No, it is not. I did not mean it to be in mainline.
The first reason is that the controller is meant to be configurable through the driver. Because of the complexity of this, it won't be done in the kernel, it is best left to user space. I think is is best that, by default, the kernel driver does not send events for the non-standard HID reports to avoid conflicts with whatever the user space driver is doing. Although Steam detach the kernel driver, so there would be no actual fighting. My own user space driver uses hidraw instead of libusb (that requires detaching the driver), I would need to mute the kernel events to replace them with the driver's ones (not a difficult change actually, I just need to grab the event device).
The second is that I am not using this driver, so I am not actively maintaining it.
The first reason could be debated, if you believe otherwise, you are free to improve it and submit it upstream. I can help if you have questions on how the controller works.
Some points that could be improved:
- use separate input device for motion sensors, the same way as hid-wiimote and hid-sony.
- the current driver uses hat axes for the touch pads but some applications (e.g. retroarch) expect hats to be 8 directions only, not fully analog axes. I am not sure which is the best way to fix that. Retroarch inputs could be fixed if it is the only application doing that. I did not test this driver enough to know how much widespread this problem is.
- more generally check that input events comply with linux standards and what applications expect.
- maybe add features like controlling the led, configuring and playing sounds, ...
