simultaneous controller initiation problem about ds4windows HOT 16 CLOSED

New test build. A simpler hotplug technique is being tested.

https://drive.google.com/open?id=0B6yGHDx0CFzDUVRmaTk0bVVzSUE

from ds4windows.

Looking at the commits for version 1.4.74 shows that nothing regarding Xinput allocation was changed. There is no reason that it would work in 1.4.73 and not the current version. It still works on my system. Something might be going wrong with the Scp Virtual Bus Driver that is outside of DS4Windows' control. If one virtual controller can get allocated then I don't know what can be done; trying to check each virtual port on the hub might not even help.

At some point, I will have to look into the current state of ViGEm and see if it can replace Scp Virtual Bus in future releases. Prior releases of ViGEm seemed to have some problems.

from ds4windows.

from ds4windows.

To slim it down, it's after plugging and then unplugging a controller and then turning that one back on the bluetooth way.

I shoulda said quick charge is messing things up. Because there is no problem with xinput allocation or quick charge in the previous version.

Also, isnt vigem windows 10 only? That would suck for me because I'm on win7 ultimate and don't plan on moving because win10 is far from game friendly as they say.

from ds4windows.

Unfortunately, that situation works fine on my system. I have found two main points where some significant changes were made so I have made builds based on those commits.

Stick Mouse changes (minor code moving regarding lightbar color calculations) (f7d3d1b):
https://drive.google.com/open?id=0B6yGHDx0CFzDc1dsV0E1Q203OEE

BT Timeout (f61cd59):
https://drive.google.com/open?id=0B6yGHDx0CFzDTEtMbDJ2UUFYS0U

Just for completeness, here is a current build which also includes some small uncommitted work.
https://drive.google.com/open?id=0B6yGHDx0CFzDVGhTeGoxVjFvRE0

I think that ViGEm is currently Windows 10 only. As far as I know, the lack of compatibility is only a matter of only having purchased a signing certificate for that platform. Last I remember reading, ViGEm will be released for other versions of Windows in the future. Scp Virtual Bus is not really being maintained anymore and ViGEm does provide some functionality that ScpVBus does not.

Edit: It looks like there is now a version of ViGEm that has been signed for others versions of Windows including Windows 7.
https://github.com/nefarius/ViGEm/releases/tag/v1.8.1.0

from ds4windows.

This reminds me of the frog on looney tunes that kept pretending to die whenever more than one person was around lol.

I can't reproduce this problem today like yesterday -_-.

But I did find that in .73, .74, and 0603 testbuild that:

1. bluetooth p1 + bluetooth p2 + plug in p2 after = 2 xbox controllers and one generic controller in joy.cpl. So something is up with the hide ds4 feature when this situation happens. Everything is fine when 3 controllers are on.

2. when that p2 is unplugged, the controller stays on. It is supposed to turn off when unplugged even if bluetooth was on before. Pretty sure this was fixed before, now it's back. It works as it should when the battery is full. It stays on when unplugged when battery isnt full.

*i don't know if you put a fix for the idle timeout light while plugged in that test build but it's still not working when plugged.

Edit: whats different about vigem? Is the only difference just working on win10 where scp doesn't anymore? Edit2: nvrmnd about vigem. I see that it will support a variety of devices.

from ds4windows.

Figured out why I was having those other issues earlier. Sometimes when I replace ds4 with new version, I will have to restart the computer or else it won't work correctly.

1.Everything fixed except quick charge unplug. If battery is full, unplugging turns off the controller which is what we want. If battery is still charging and you unplug, it goes back to bluetooth instead of turning off.

2. Idle timer light while plugged still not working.

from ds4windows.

Maybe the hotplug delay is not long enough. The delay is supposed to be 50 ms and that is supposed to give BT controllers enough time to grab an input report and update the device charging state. Maybe there is a delay before the DS4 changes the relevant byte in input reports. With the recent update, I can usually see the BT controller battery status get updated in the GUI before DS4Windows disconnects the controller. Quick Charge works on my system fine under both circumstances. I am thinking about changing how hotplugging is performed in a future update.

The idle light works as intended as well.

from ds4windows.

The idle light timer dimming until off while plug doesnt wrk for me. Other users are saying that as well in its own thread. I just mentioned it here again bcuz i already mentioned it b4 here.

As for the quick charge while on charging mode, post a test after youve done that tinkering, please.
Thanks for your hard work!

from ds4windows.

The changes will mainly revolve around getting some processing out of the main GUI thread. Testing out the delay hypothesis is still needed. It does seem like there is a small delay between the time a USB cable is plugged into the DS4 and the time that the DS4 sets the value in input reports. Can you try a test build and see if you have better luck with it? The delay has been increased to 200 ms.

https://drive.google.com/open?id=0B6yGHDx0CFzDN1Iwd1NHNWZidlk

from ds4windows.

That works but seems like this (maybe) makes another problem. When turning on bluetooth controllers one after the other, sometimes, controller colors get shared. Sometimes a controller may stay on a white light instead of the color they are supposed to be. Maybe they are getting confused when theyre trying to connect to the same player number at the same time?

from ds4windows.

The next test is to move quick charge checking to the input thread. That way the delay before running the hotplug routine does not matter anymore; it has been reverted back to 50 ms but it could possibly be removed in future builds. I have tested it and it does work without causing much extra work in the input thread.

https://drive.google.com/open?id=0B6yGHDx0CFzDeHdOUWFudXJveVk

from ds4windows.

Charging, plugging, then removing turns controller off now. That seems fixed.

But when I turn all 3 controllers on simultaneously, 2 of them go to a solid white light, then eventually turn their proper colors after a short while. But sometimes one of them goes to a solid white light and it stays there. During this time, all 3 xinput controllers are shown in joy.cpl but you can't press home+start to turn the white lighted controller off. Again, this happens sometimes. Also sometimes, only 2 controllers show in joy.cpl when attempting to turn on all 3 controllers at the same time. One of them lose the fight and don't allocate at all.

So, quick charge thing is fixed. Them fighting over the positions when turned on simultaneously still remains.

from ds4windows.

Previous comment remains the same for both issues.

from ds4windows.

any update to the simulataneous activation fight over the virtual xinput the controllers have when turned on at the same time? Maybe a controller profile option of "preferred xinput slot for this particular controller' or something like that? So when they fight, each controller will know what place to go to so they don't get confused.

Any other better solution is welcomed as well.

from ds4windows.

Although it might be somewhat unrelated, I found that using the DInput only option in a profile can cause this problem to happen. Multiple calls to the SCP Virtual Bus can potentially happen at the same time and cause conflicts. The issue with DInput only has been fixed in newer commits. I hope that is the last spot where XInput slot issue would occur.

Any type of preferred slot set in the program seems like it would only affect the SCP Virtual Bus. Any application using XInput would still detect controllers in the order they were connected.

from ds4windows.