Closed Yohoki closed 4 years ago
Ryochan7
commented
5 years ago I think I might have experienced that problem once before but other tasks made me not look into it at the time. I cannot remember if I was running DS4Windows in user mode or admin mode when it happened. I am going to assume that the Exclusive Mode routine is likely the culprit of the problem though. The XInput unplug change should have nothing to do with it.
Ryochan7
commented
5 years ago This just happened to me again. My initial assumption seemed to be correct. I checked the device listing in Device Manager and the device was in an odd state. The "HID-compliant game controller" was listed as disabled but the right click context menu showed an option to disable the controller rather than enable it. It seems like some funky state issue can happen on occasion.
It is not the same as having the device permanently disabled though. Unplugging and plugging my Sony Wireless Adapter back in was all that I needed to do and then Windows recognized it as an enabled device again. DS4Windows was still running and it was able to detect the controller immediately as well.
Yohoki
commented
5 years ago I've not seen it happen until a few days ago, and haven't seen it today but I've been out all day. I don't get exclusive mode to work. I tried using the Process explorer that was mentioned in #573 , but the only device that pulls anything up only pulls up DS4Windows and DWM.exe (Required system process) so I can't even stop the other programs to get it to work.
I should be in admin mode, because it's set to run as task on startup. but it's entirely possible that I closed out for whatever reason and had it running in user mode. I'll check that as well.
Ryochan7
commented
5 years ago I was running in Admin mode when it happened to me.
Yohoki
commented
5 years ago Would you like me to run it in non-admin mode for the next week or so and see if it persists?
This just happened to me again. My initial assumption seemed to be correct. I checked the device listing in Device Manager and the device was in an odd state. The "HID-compliant game controller" was listed as disabled but the right click context menu showed an option to disable the controller rather than enable it. It seems like some funky state issue can happen on occasion.
It is not the same as having the device permanently disabled though. Unplugging and plugging my Sony Wireless Adapter back in was all that I needed to do and then Windows recognized it as an enabled device again. DS4Windows was still running and it was able to detect the controller immediately as well.
-Edit I just noticed this other post. Must have come in while I was typing my reply. I've enabled mouse-keys to check devman next time it happens. Your amazing app is the only thing allowing me to have a mouse right now, so I've been quite reliant on it, so thank you for keeping it alive and providing many new updates. I wasn't able to check devmanager or controllers in control panel before.
Is there any particular reason why it would get the device into this weird state, or is that just a funky windows 10 issue?
Ryochan7
commented
5 years ago Maybe the controller is being probed too early after getting re-enabled. The last similar issue that was fixed was the user mode routine would timeout before the exclusive mode function was finished and the app would try to probe the controller again. Even then, the controller state was consistent after the disconnect. This limbo state is unexpected.
This whole process should be considered unsafe but it is the only option that is available to get exclusive access to the controller without using a filter driver like HidGuardian. The only thing to do is to keep trying to hammer out any problems that pop up. It does not help that it is a moving target since Windows updates seem to change the process on occasion. This whole fork started after a Windows update broke the exclusive mode routine.
ExpatUK
commented
5 years ago In a similar fashion, the gyro also plays up after a certain amount of time and is only fixed via a reboot. I think it's related...? Otherwise I can make a separate bug post.
It seems to be an issue with DS4Windows itself as even if the controller hasn't been powered on or connected since reboot, but the process runs for a day or two, the gyro (using BOTW in Cemu to test) only looks up and left when you only tilt the controller up, and goes down and right when tilting the controller down. Rebooting seems to be the only recourse to fix this as unplugging/plugging, powering on and off and restarting DS4Win in either user mode or admin doesn't fix it. I've replicated this on two Win7x64 systems.
Ryochan7
commented
5 years ago That is a very odd problem. I have not tried using cemuhook after a long period of time. I can give it a try at some point.
I remember a somewhat related issue someone had mentioned regarding Final Fantasy 14 and the controller inputs not being detected after an extended period of time and reconnecting the DS4. DS4Windows would detect the DS4 though. I tried to duplicate that problem on my own with no success. I cannot remember which version of Windows the person was running.
Yohoki
commented
5 years ago I've gotten this issue with ds4 getting messed up again a few times. I checked the dev manager, and it's just as you said. The device shows the "Disable device" button greyed out and process explorer doesn't show any open handles to the device.
Likewise, Controllers show both the DS4 Controller and the virtual XBox controller as normal. Pushing any buttons doesn't have any effect in this menu either.
Removing the USB cable and plugging it back in has no effect, but moving to a different usb port seems to fix it. I even tried plugging in my keyboard to the broken usb port and the keyboard works but plugging in a controller afterwards still doesn't change it.
I guess I'm going to chalk this up as quirky windows 10 problems. I at least have 4 USB ports in close reach, so that means I only have to do a full shutdown every few days.
ExpatUK
commented
5 years ago To clarify, I'm replicating this issue on three (now) Windows 7 x64 systems, all with cables and without, all with different USB BT adaptors.
One workaround which seems to work reliably (albeit annoyingly), is the following procedure:
It seems that opening the profile edit page refreshes something and "unlocks" the controller from its weird state. But you have to kill DS4Win first...
Ryochan7
commented
5 years ago I could not reproduce the same gyro problem. The only way that the gyro acts funky like what was described is when the controller is not oriented properly when launching Cemu. Launching the emulator with the DS4 standing almost vertically (while charging in my case) makes it to where the the gyro looks up and right while tilting the controller up and down and left when tilting the controller down. Left and right movement becomes extremely throttled in that situation as well.
Opening the Options form causes DS4Windows to load the selected profile or reload it if already in use. That process includes making some changes to the output report to reset rumble and use the profile's lightbar color settings.
If DS4Windows would crash for some reason then it would be a problem as a dead XInput controller would still be seen by Windows. A cycle of calling the unplug call in ScpVBus and a plugin call would be necessary to get a virtual XInput controller to work again. The unplug call would likely be from when you close the application normally.
Ryochan7
commented
5 years ago The old issue was #506. That problem was different though because Windows could actually detect input from the virtual XInput controller but Final Fantasy 14 could not.
Yohoki
commented
5 years ago I'm no longer seeing the original issue of getting an orange blinking light that requires restarting the computer. I'm still getting frequent disconnects from shooting cable/port, but there has not been a single time when that disconnect resulted in the controller being completely unusable without a system restart. Whatever you changed in 1.6.13/1.6.14 have completely resolved my issue.
I'm not sure about @ExpatUK 's gyro issue, but mine at least seem to have been fixed. Thank you!
Ryochan7
commented
5 years ago I am guessing that changing the location of the hotplug delay in version 1.6.14 might have helped. That is good to know that some issues have been fixed.
ExpatUK
commented
5 years ago Latest patch certainly have improved matters a lot - not getting much earache from the missus! I'll let you know when we've had more time to test but it seems the disconnecting/crashing/gyro issues have not yet reappeared. Not had enough time to properly test, yet.
ExpatUK
commented
5 years ago Gyro bug (constantly one direction) appears to be resolved on Computers 1 & 2. DS4Win crashing occasionally is still present (I'll look into getting some logs), and the issue-only-a-reboot-can-fix is still present, but noticeably different. Now, instead of the controller not responding to any inputs, it does - but with an incredible input delay it seems, described as "very jerky".
Tried to test with a spare BT 2.0 dongle found in a dusty drawer, but sadly couldn't get input latency in DS4Win below 20ms, with regular spikes up to 300+ until it disconnected the controller after around a minute. Can only assume it's due to the almost megalithic BT adapter, but thought it was worth mentioning as the behaviour was similar.
Ryochan7
commented
5 years ago Any adapter that uses BT 2.0 is too old to get a decent connection with the DS4. BT 2.1+ is the minimum spec that is required but even my experience has shown that using a BT 4.0 adapter should probably be considered the minimum requirement.
Maybe I should just try to add a try block there so if the problem happens then at least it won't take DS4Windows down with it. I don't know how the UDP server would end up behaving after that though. Also, I should see how ViGEmBus would behave when DS4Windows crashes and see if the dead controller issue would still be present.
Ryochan7
commented
5 years ago I have tested explicitly killing DS4Windows many times. ViGEmBus does remove virtual Xbox 360 controllers after DS4Windows is killed and ScpVBus leaves a dead controller in limbo. I guess that is another benefit of finally making the switch to ViGEmBus for the next release.
The UDP server problem will not be dealt with in that release. The idea behind the next DS4Windows release is to make almost no code changes outside of changes required to get ViGEmBus support working. A test build would not get posted until after DS4Windows 1.7 is released.
ExpatUK
commented
5 years ago Thanks for the update. I was hoping a full implementation of ViGEmBus would happen. Just to confirm, a 2.1 BT adapter is used on Computer 2 without issue (now, since the last patch) - there are very few 4.0 BT adapters compatible with Windows 7, so I would advise caution over implementing any software BT 4.0+ limitations etc.
...and thanks for all your work on keeping this project going!
Ryochan7
commented
5 years ago The changes are still being tested but it almost seems to be ready to go. The main concern is making sure the driver installer works in different configurations.
I guess I got lucky with my adapter as it works fine in Windows 7 using a generic driver. I use a Rosewill RNX-BT401 as my primary BT 4.0 adapter.
https://www.newegg.com/Product/Product.aspx?Item=N82E16833166126
ExpatUK
commented
5 years ago Thanks, I'll add that to the list - also note the Plugable BT4LE works flawlessly on Win7 as well, but none of the cheap CSR-based ones work with Windows 7 to any degree (no audio, no HID, obviously no BLE, etc) as far as I can tell - I recently tested 7 different models. They all worked fine on Windows 10.
Computer 2 update from yesterday: user reports that DS4 win still ends up crashing with a nonresponsive controller, only much less frequently than before. It certainly does seem that ScpVBus is the root of all of these issues.
I look forward to the update - I have several machines (Win7/Win10) and am happy to test, etc.
ExpatUK
commented
5 years ago Just a quickie - three computers now running latest version with ViGEmBus - all problems appear to be resolved!!
New one popped up though (minor, I'm sure), touchpad doesn't track mouse any longer. But at least it's not disconnecting! No crazy gyro inputs either, so far. :)
mika-n
commented
5 years ago New one popped up though (minor, I'm sure), touchpad doesn't track mouse any longer. But at least it's not disconnecting! No crazy gyro inputs either, so far. :)
Have you tried to re-create a new profile? See this post where another user had the same problem with touchpad mouse but creating a new profile with the lastest DS4Win version solved the issue. There could be some properties missing in the new profile or wrong "default" value. https://github.com/Ryochan7/DS4Windows/issues/637
EDIT: Forget this. It was you who reported the fix/workaround so maybe one of your personalities have already tried this fix :-)
ExpatUK
commented
5 years ago So! Developments on the weird gyro bug problem - it has returned!
But this development comes with good news - I can specify the problem much better now. When the gyro bug happens (after DS4win has been running for an eternity and the controller gets switched back on), it is just the horizontal axis that is inverted. Vertical seems unaffected. This is different behaviour to the previous SCP builds, so I'm thinking there's some bug on reading X values from the controller somewhere as the vertical axis was unaffected when the bug happened before.
Currently on mobile so apologies if that comes across a bit scattered; will reiterate better later if required.
I've recently started having an issue where a disconnect will happen with my controller, likely a bad USB cable or such, and ds4windows breaks on reconnect. Logs will show the normal things: Found controller... Plugging in x360 controller... x360 plugged in... Cannot use exclusive mode... Using profile "whatever" . It all looks normal and reacts to being unplugged and plugging it in.
The issue is that the lightbar becomes orange, fading in and out like it's charging. There is no controller listed in the controllers tab of DS4Windows and no response from controller. Switching to a different USB cable, port or even controller all results in this same status. Closing program and restarting in Admin mode doesn't fix the problem and even using an older version of DS4Windows doesn't work. The only solution I've found is to reboot the computer.
It has been happening once or twice a day for a while, but I'll have to go back and check which update started this. I suspect it's 1.6.9's "Fixed issue with xinput unplug routine on device removal" that started doing this. I at least know it wasn't happening in 1.6.7 . It also doesn't do this on every disconnect, maybe 1 in 50?
Next time it happens, I'll check windows control panel to see if something weird shows up under devices and controllers. Then I'll pop back a few updates and see where it started doing this. It's not frequent, only happened about 3 times now.