(01-23-2014, 04:28 AM)InhexSTER Wrote: [ -> ]So I put together final version for DS4 1.1. It has hide DS4 Controller checkbox and some performance improvements.
That's about it. I will work on tap/two finger functionality for the next update and more speed improvements
Until we have a lengthy discussion and define the future of the tool with electrobrains. It might take as some time. I will be posting small updates in meantime
By default the behaviour is to not hide DS4 control (Shared Mode)
When you hide it, it tries to enter Exclusive mode.
Checbox automatically restarts the mapping process so you switch between them without restarting the tool
Awesome, I think I will do similarly in the meantime -- develop in specific directions that aren't especially stepping on each other's toes. What is important is getting the concepts right, learning how to operate the hardware properly, and coming up with a future feature set so we have a nice architecture to allow for whatever people are interested in.
I just realized when I couldn't use the controller to accept a UAC dialog (Java updating) that we really need to implement a virtual touchpad/tablet/keyboard driver. There is so much that we cannot properly do without it. Scarlet.Crush probably has a lot of good knowledge in this area since he's already implemented virtual I/O drivers! I want to continue fixing the specific issues people have reported in my branch of development, and continue working on some different operational modes for the touchpad just to prototype (eventually, the same modes would exist but each button would be fully-programmable in function, and I absolutely want to make the touchpad usage modes modular so you can configure your own set like the four I've defined now, and toggle between them).
I've come up with the plan to make the touchpad push a modifier key. The touchpad push sucks as a mouse click due to jitter, at least until we make it a proper virtual mouse and therefore access the built-in de-jitter APIs that I'm sure exist in Windows. I don't really want to even open that can of worms because I want the latency of a direct path of I/O without processing, so that the games can do their own processing if they want.
By the way, I just made this change to test out your rumble theory:
Code:
const int buzzDuration = 3000, silenceDuration = 2000; // we're not enforcing real-time... output reports are tied to input data packet processing currently
switch (touchpadMode)
{
case TouchpadMode.MouseWithButtons:
touchpadMode = TouchpadMode.MouseWithOneButton;
bd.PerformHapticFeedback(() =>
{
bd.HapticBigRumble = 255;
Thread.Sleep(buzzDuration);
bd.HapticBigRumble = 0;
Thread.Sleep(silenceDuration);
It doesn't require pushing the output report repeatedly. It just seems to work fine telling it to start buzzing and to stop buzzing. I think you must have accidentally made non-buzz output reports periodically at some point to come to that conclusion. That's particularly why I want to try to meticulously comment our operating assumptions as we reverse-engineer this hardware -- we each operate on varying assumptions as to how we expect something to work, so we'll all run into different surprises. You should try merging back the redundant-output-report-removal, I don't think it will break rumble but that perhaps another bug is covering things up. I'd add debug prints for every output path that could possibly go to the Bluetooth/USB HID device, or assertions. I've fixed a great deal of thread synchronization issues that could cause random errors, and one of those could easily be at fault. I think we could probably merge the two codebases we have soon, and get someone to work on a GUI, and not worry about starting form the ground up... just as long as we are totally willing to scrap and rewrite entire "subsystems" when it seems necessary.
We could also work on pushing the native HID integration into the original Scarlet.Crush DS2/3/4 drivers, which would certainly not be harder than rewriting our whole DS4 driver. After that we could spend our time trying to improve the other side of things: extend the software to support customizable and pluggable operation modes for the touchpad, axis remapping, all that sort of thing.