On Tue, Feb 20, 2018 at 02:29:48PM -0800, Pierre-Loup A. Griffais wrote: > Hi Rodrigo, > > Thanks for working on that! I have a few questions and remarks. > > For the reverse-engineering part, there's a lot of existing reference in > existing (user-space) drivers for the controllers like sc-controller, but > feel free to reach out if you have any questions. It's overall pretty simple > and there's nothing secret about how it functions; there are some quirks, > however. Nothing secret about it, but also no documentation, so might as > well be... Have you tried deflecting the analog stick while touching the > left trackpad? You'll most likely need special handling there. How are you > planning to expose enabling/disabling auxiliary data like gyro over > wireless? Yeah, I look for information about a year when I started on this. I read Ynsta's user-mode driver [1] (I didn't find sc-controller), but I found that a bit incomplete, so I wrote my own named `inputmap` [2]. About the left trackpad/joystick, currently I'm not treating them different. I'm out of ABS axes, and anyway, it is not likely that the left pad and the joystick be used at the same time (I only have one left thumb). Nevertheless, if we really want to make them apart, we can use bits 10.3 (lpad_touch) and 10.7 (lpad_and_joy) together. I described the details in [2], but I'm not currently doing that in this driver. About the gyroscope/acceleration/quaternion, you know the issue that the wireless gives gyro plus quat but no accel, while the wired gives all three. My general idea is to create an additional input device with INPUT_PROP_ACCELEROMETER to expose what is available. Pity is that the wireless gives no accel, maybe there is some command to enable it? Also, ideally, we could expose the quat. data directly to userspace, but I see no clear way to do that. Maybe defining INPUT_PROP_QUATERNION? I also thought of computing yaw/pitch/roll from the quat. and exposing those, but doing that requires atan2() and sin() (16-bit precision), and that would be tricky. Any thoughts on that? > Will this driver being loaded affect functionality of existing applications > that talk to it through HID directly, like Steam or sc-controller? Will they > be able to keep getting the same HID data they do today? If so, the extent > of the work needed to support it in Steam might just be to ignore the > controller device it's exposing, since Steam will expose that itself through > its own means. As it is, this patchset hould be pretty safe. The only command sent to the controller is the get-serial-number, and that seems to do no harm to Steam Client. Other than that, it only reads. Moreover, the hidraw device is still created, so user-mode driver should keep working (but AFAIK, Steam Client uses direct USB access, not hidraw). Curiously, Steam Client does not show the new native Steam Controller gamepad. That is, if I connect the Steam controller with hid-steam.ko and an Acme HID gamepad, then in Steam Client controller settings I see only two controllers, the managed Steam Controller (not HID) and the Acme HID gamepad. I reckon that Steam Client recognizes that the new HID device is a Steam Controller and ignores it in favor of its own managed controller. Regards. Rodrigo [1]: https://github.com/ynsta/steamcontroller [2]: https://github.com/rodrigorc/inputmap -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
