I'll get to testing these 2 drivers shortly - but I've always had the preference pane open before plugging the controller in.
That thing can be really weird about what it recognizes after it opens. I just want to make sure that you are plugging in your controller first before opening the Preference Pane.
That means that for 2 and 8, the controller failed to show up as a valid device, but was initialized properly. Those button presses aren't sent out by the controller unless it is initialized. Something that really bothered me is how 2, 6, and 8 all put out button press output. This is just to make sure that the debug printouts aren't magically making it work. The second one is the same as the first, but without the debug prints. The first one has even more debug output every time a button is pressed, because I just want to check some stuff. And in programming when you get some flukes like this, its probably a timing problem! So I've got two new builds with a delay introduced. Its led to me to believe that all of the previous situations where the controller has worked have been flukes of the build process. Thanks for you notes and detailed descriptions of each build. Reply to this email directly, view it on GitHub, or mute the thread. You are receiving this because you authored the thread. (110) (This should be the same as the second one I gave you.) (000) (This should be the should be the same as the first one I gave you.) I'll always try to uninstall previous versions first, as per above.
There are currently three blocks of code that differ from the first driver I sent you. This is 110% not okay! Nothing I just did should have solved this! I'm going to need you to test a couple builds for me so I can figure out what it the world just happened here. IManufacturer 1 Performance Designed ProductsīInterfaceClass 255 Vendor Specific Class Here's the output for lsusb -v for that device -> I've just copied/pasted the whole device section as I thought it may have something else which helps. If it doesn't work with xpad, then I don't think anything short of a USB protocol analyzer will be able to fix it. If it doesn't work for xpad, that means that no one has figured it out yet. If it works, I can see all of xpad's source code and I can figure out what they do differently that we aren't. There isn't any real specific testing you need to do beyond seeing if the controller works. It has instructions for VirtualBox explicitly, so you may just want to stick to VirtualBox. To get around that, you'll want to use this. Since kernel version 4.4.0-20, unsigned kernel modules will not run with secure boot enabled. Then you just have to build and install it with sudo dkms install -m xpad -v 0.4. The order probably doesn't matter, but it would go in at line 183 if you want to do that. Inside this file, at line 128-ish you'll find xpad_device which has a bunch of listed devices. You'll need to navigate to that directory and find xpad.c. That will clone the repository into /usr/src/xpad-0.4. I'm not the most familiar with Linux myself, so I can't quite get you an exact description of what you will need.įirst, you would need to clone xpad and edit it to add your controller.