(04-06-2016, 07:44 PM)Nefarius Wrote: [ -> ]I actually tried to get in touch with the developer of the Android Sixaxis App a few month back but never got any response so...
Well based on some of the stuff that I found when digging into using this with Linux, I would guess that they are probably either using some of the existing Linux kernel modules for sixaxis support and/or sixad similar to what I posted before but modified to work with Android. I am not certain on this though.
(04-06-2016, 07:44 PM)Nefarius Wrote: [ -> ]I bookmarked the repository, thanks. Will have a nice long read once I've got more free time.
I have tried to do a little debugging and comparison and so far my general initial assessment is as follows...
1) In the Linux daemon they are not seemingly doing anywhere near as much of the back and forth with HCI / L2CAP as what I am seeing with ScpToolkit. Some of this might be just using existing bluetooth functionality already in Linux or maybe they are just keeping it much lighter in that regard?
2) He has modified to essentially push some of the stuff that you have in BthDs3.cs, specifically like with this:
Code:
if (IsFake)
{
//_hidOutputReport[0] = 0xA2;
//_hidOutputReport[3] = 0xFF;
//_hidOutputReport[5] = 0x00;
}
But in the Linux sixad they are instead pushing the "fake" first and then just executing the enable command for original immediately after. Also he is pushing both of these pretty early in the process from what I can tell .. by contrast with my GAME-O pad and ScpToolkit none of the code in BthDs3 is never even called because the device is never Start()ed .. it just gets into that disconnect / connect loop and never even gets to the point where the BthDs3 code could modify the buffer like that even if we were to uncomment these lines of code.
What I am seeing on their side is almost even a little different process entirely....
Start up the bluetooth and then the worker process looks like it is under
void hid_server. Line 316 of bluetooth.cpp you can see the loop (
while (!io_canceled())) which looks relatively synonymous to the loop in ScpToolkit's ScpControl for Bluetooth, in BthDongle.Tasks.cs
void HicWorker
Then if things check out it seems like it is calling over to
l2cap_accept which is basically just setting up a new device ? (creates instance of
sixad-sixaxis ) .. and when this is done, it is opening some kind of stream for the device with uinput and running
enable_sixaxis which pushes that buffer for both fake and original.
Not sure if I am seeing this wrong, but on initial glance it looks like what they are doing is much more streamlined and there isn't anywhere near as much of this "back and forth" that seems to be happening with Scp ... am I getting that part wrong?