JoyCon-Driver
JoyCon-Driver copied to clipboard
fossephate
Joycon Input Delay
I believe the developer is already aware of this but for anyone else that is experiencing this issue, I am here to let you know that you are not alone. The bug is that the longer the amount of time the joycons are connected, the greater input delay becomes apparent. I have seen my own setup get as bad as 3 seconds. If it's worth noting, this is using the combined joycon configuration. Also, for anyone getting the VCRUNTIME140D.dll error, what I did was copy a vcruntime140.dll file into the system32 folder on my computer are rename it VCRUNTIME140D.dll. It just worked after that, it seems really strange but I hope this either gets fixed or that information helps someone else out.
Yeah, I'm aware of the issue, I just don't have the time to fix it right now with AP exams next week, among other things. Hopefully I'll get around to fixing it sometime soon. Thanks for opening an issue though.
Oh, also just to note: distance to the Bluetooth receiver definitely seems to affect responsivness/response times; although I'm not sure exactly how much I'll be able to do about that
Alright, just to note, I was within 2 feet of the integrated Bluetooth adapter and I felt it still got increasingly worse. Good luck on your ap exams, I know they can be tough, I took ap chem yesterday and have AP Physics 1 today and AP Calc AB next week.
well the D in the DLL dependencies seemingly stands for debug, maybe the program isnt properly optimized since it's a debug build...
Hey, I just wanted to say that this is a great project! Also 2 things:
- I don't know if anyone else is getting this, but for me, the lag only happens on the right joycon after a few inputs
- Also, I don't have much experience in C++ (I only fiddle with it a little bit, I personally prefer JS), but this sounds like a memory issue (whether it's the driver's fault or vJoy's fault)
- I've also noticed that if you wait a little bit after it starts to lag (maybe a minute or so), it speeds up again. Maybe packets are being backlogged?
I compiled the new version submitted yesterday and still experience the delay issue. I hope there is a way to solve this problem because this driver has a lot of promise
Something's been changed in the new commits that completely fixed this for me. Using --combine and --auto-center, I've been playing Portal 2 for almost an hour with no input lag. Haven't tried without these 2 options yet, but I'm assuming there'd be no lag without them. Thanks @mfosse 👍
this should be improved with the latest commit, the charging grip still seems to be having some issues, though
Hmm, I got a chance to test it out and it seems like it might be improved but I feel like it still needs work. The right joycon seems to consistently have more input delay.
The right joycon definitely has input delay while the left joycon feels spot on. The input delay does seem to be consistent though. It can't be a problem with my Bluetooth module because this doesn't happen without using the driver
still experiencing problems with both joycons in the release and debug builds. Edit: actually, the right stick feels extremely responsive (using combined mode) Edit 2: I did some more testing and it seems inconsistent, sometimes the joycons disconnect and sometimes the left joycon is super responsive and the right isn't and vice versa. I think you are getting somewhere though. Just to note, I don't have my switch right now since its battery is getting replaced at Nintendo, so I haven't done any possible joycon updates with the new switch firmware
It should be better than before but I haven't done any extensive testing.
Hi!
Just wanted to let you know I've been watching this project pretty closely and was also experiencing unusable input delay. I can't speak for the person that opened this issue, but since your last commit stating input delay was addressed, I haven't had any problems and have been happily playing pc games with my joycons now for about half a week.
I have shoulder problems that make it hard to bring my hands together to play games with normal gamepads for long, so this driver has been hugely helpful for me since the joycons can be used with one's hands held apart. Thanks so much for making it!
I think it's pretty safe to close the issue, but if anyone is still having problems let me know / reopen it.
I figured you would still receive this Matthew even though the issue is closed. I found the problem. It's my computer, I tried it out on my sisters laptop and everything worked perfectly. For some reason my computer is acting possessed and will always delay the input. I'm trying to narrow down now if its the vjoy or maybe some system files. thanks for all your help. You have done a great job
well now that I say that, now it isn't working so perfectly on my sisters's laptop. Oh well maybe it just isn't for me.
:/ mysterious, I have some ideas as to what it might still be, hopefully I'll figure it out soon.
Interestingly, I've found this bug to be much more apparent when using the shoulder buttons.
Going to do some protocol profiling work a bit later
As of comment 157b108, I have noticed some new occurrences to me. Upon first starting up the driver, with combined, auto centered, and gyro activated, every time, one of the two joycons would disconnect. What I found out was that the gyro was causing it to disconnect and disabling it would fix the problem. Also, I experienced no input lag for about 5 minutes after disabling gyro until seemingly randomly the lag was back. It would then come and go sometimes not appearing again for another 5 minutes, sometimes it would stay for 10 minutes. I just thought I would note that. Keep up the good work.
So turns out I'm still getting the input lag issues on one of my machines, and as someone who did a lot of mobile programming with a specialty in performance optimization and finally some time on my hands, I was finally able to take a look into it.
I've put a preliminary fix up on a fork (https://github.com/HollyJean/JoyCon-Driver) and so far things seem to be performing better than ever. It's fairly cowboy code and I'd like to make it require a flag for now so I'm not ready to open a PR yet, but will have time hopefully on Sunday evening or Monday to clean up and submit.
(More technical details follow) Looking at your code, the operations that are done are all really just a bunch of simple math, which usually doesn't cause much of a performance impact. After some strategic logging, I had a hunch the bottleneck was updates to vjoy. My guess is because the joycon driver polls so rapidly, vjoy's buffers get overloaded or something? Anyway, I offloaded sending updates to Vjoy onto another thread, per vjoy device, and while an update is being made, any other calls to update are just ignored.
The solution seems to be working pretty dang well but I want more time to test it (hence the desire to make it just an option for now). I was worried there would be occurences of buttons presses or releases not being reported since it's dropping update calls, but that doesn't seem to be the case. If anyone is feeling adventurous feel free to check out my fork and give it a spin and see if you can find problems with it. Note that I did not do a build (don't have the win8 sdk atm) so you'll have to build it yourself.
@HollyJean Ironically, when testing your fork, there was a lot of input lag; which is why I still think the issue is with the understanding of the joycons && the command structures. I think it may also be a timing issue(which would explain why it sometimes works better than others).
Testing out another fix on my fork for the next couple days, this time related to the way reads are made from the HID device. It seems there may be an issue with using hid_exchange exclusively to get messages from the joycons, as I found that 0x3F messages might possibly be sent by the joycons even without a status message being sent, causing a buffer of messages to build up, one of which are only grabbed each time a status message is being sent.
@imarceldoe probably... I'm not too familiar with Windows programming but if you check out my fork at https://github.com/HollyJean/JoyCon-Driver I just pushed up a freshly built exe in the release folder (just like how mfosse does it). I believe the build will only work for windows 10 but I'm not totally sure about that?
I have not tested this with gyro controls on or outside of combined mode so beware if you do either of those :P.
@HollyJean Personally I experience what @mfosse said, more input lag as I do more commands at once, ie hitting the shoulder buttons and joystick up at the same time or so on.
Alright. The fix is kind of hacky to begin with and to do it the "right" way would be a little more involved than I'd like without an environment where lag issues manifest to test in. So far I've been able to repro issues and confirm them on my machines but haven't after my last bit of code. Maybe this weekend I'll dust off an old laptop to see if it's got problems my others don't. I have a few questions for ya if you don't mind @imarceldoe.
What kind of CPU do you have? How many cores?
What kind of bluetooth device do you have? If it's internal I can figure it out if you don't mind sharing the model of your machine.
And lastly, do you see any lag issues when not using this project? Bluetooth can be notorious for being kind of crummy, and the joycons themselves don't seem to have great bluetooth antennas. I wonder if the lag combined with the disconnect issues you're experiencing could point to a greater problem in your whole setup.
On another note, a word to @mfosse. Since you don't have a license on this project I understand it's wholly under your copyright. If you feel like I'm taking too heavy a hand in your project or anything you have every right to let me know and I can of course ease off. I just really want this one particular issue to be done and gone :P.
I've been testing @HollyJean's fork of the project, and it seemed to have eliminated my input lag issues in combined mode. I'm using an integrated Bluetooth adapter (Intel Wireless Bluetooth) on my MSI laptop. I'll try to give more details once I've figured out a solution to a few other issues I'm having (Joy-Con disconnecting, swapped up/down directions on the left thumb stick).
@HollyJean 5820k, 6 cores I have a Insignia bluetooth adapter, I'm not really sure what else I could test that adapter on.
@imarceldoe what I was curious of was whether the joycons had the same input lag issues when not using this driver, i.e. just using the controllers with the default windows driver. Could you give that a spin and let me know your results?
@HollyJean To test that I just sync one of the controllers and boot up a game, right?
You could try running a game but there's not guarantee it'll support it because lots of games only integrate with xinput (xbox-style) controllers these days. The easiest way to test it out would be to just open the game controllers control panel, which have a testing tool. This guide shows you several ways to do that: https://www.isunshare.com/windows-10/5-ways-to-open-game-controllers-in-windows-10.html
well depends on the game. a lot of in my opinion good games still do direct input, simply becase you can use controllers other than xbox controllers with them. there are also games that use SDL2 which would need a specific entry in the gamecontrollerdb because the games dont know this kind of controller.
@mfosse I notice you updated something, whatever you did definitely made the issue better. It still occurs frequently enough to impede gameplay, but I'm having a slightly better experience.
It might also be a fluke but on less CPU intensive games I seem to have no issue with input lag.
Again, my system has a 5820k so I'm sure it's not bottlenecking or anything and more so a software thing if that were the case.
@HollyJean Your fork so far has worked wonders for me. I don't have any joycon disconnects and there is zero input lag. I haven't tested with gyro yet but combined works great! Edit: I tested with gyro and one of my joycons always disconnects almost immediatly, same as the @mfosse master
@imarceldoe Thanks for the info... a shame that it's not helping for you still. We might be looking at two different things causing input lag issues maybe. Also, a 5820k really shouldn't make things too hard, unless maybe you have integrated graphics?
@theofficialgman Thanks for letting me know. Glad to hear it's helping someone else out too.
Since this has helped a few users I'm going to go ahead and find some time this week to clean up my implementation and make sure I haven't broken gyro or single joycon modes. Then it should be pull request worthy.
@HollyJean I'm willing to get a new bluetooth adapter to test out if it might be that.
Any recommendations? I have an insignia right now.
@imarceldoe you can try? But I dunno if it'll really help, especially if you're not having problems using a joycon without this driver application. I have Kinovo, Plugable, and IOGEAR bluetooth dongles and they all work alright for me after my fix, but I can't promise anything for your situation :/.
Do you get input lag when you're not in a game, but just open up "monitor vjoy" by any chance? If you don't it could lend some credence to the CPU-is-the bottleneck theory.
And also just to make toootally sure, if you're using the build I made, are you running whatever's in the release folder? And that you've updated to whatever my latest commit is?
Just a quick update... sorry if anyone is waiting on this fix to go into main. Had some medical issues come up but should hopefully find some time to get a PR up this week.
Hey guys, I am guilty of reading only the first few posts of this thread before replying but I have noticed the same issue and I can maybe suggest a root cause for the problem.
My hardware is not a real joycon, it is a device I created myself that looks like a joycon to the Nintendo console. A Joycon emulator or "fake-joycon".
When I was using this driver,with the fake joycon, I noticed an input lag problem. At first the lag was a few hundred miliseconds, but it got worse and worse over a period of a few minutes until it was seconds long.
Since I can debug the code on the joycon side of things, I was able to locate the problem fairly quickly. It seems like the joycon-driver is spamming "0x00" subcommands to the joycon. Each time this subcommand is received, the joycon replies with a button report. I think this behavior might be intentional in order to "keep the flow going", as the joycon will not usually send button reports when no buttons are being pressed.
The issue is simply a buffering issue. So many button reports are being sent that they start to back up in various buffers throughout the system. I modified my code so that it does not reply to 0x00 subcommands and the lag was instantly gone.
Using this page online: http://html5gamepad.com/ I was able to view the timer or counter value on the joycon device (NOT the vjoy device) go from incrementing over 100 times per second, to incrementing only up to 60 times per second (this is the regular report rate for a joycon).
EDIT: as a side note, In theory this constant stream of 0x00 subcommands causing the issuing of numerous extraneous button reports might impact the battery life of the joycon, since it is kept in the highest power mode (transmit) for most of the time
@timmeh87 Have you looked at @HollyJean's explanation for his fork (scroll up)? He seems to have also noticed that updates were too frequent and created buffering issues. His fork eliminated input lag with my Joy-Cons.
Well that is it then, I suggest we pull that code asap or else implement a throttle of some kind to keep the report rate near 60hz
Actually, since this is a full fledged driver, the correct way to do it is to stop sending id:x01, subcmd:00 and parse x21 reports.
It should send a id: x01, subcmd:x3 x30 once, so the joycon can start spamming x30 reports. This way, with a x30 input report parser, the latency should reach around 16ms. Rephrasing the above, the connection should be one sided. The only thing the driver should send, is id: x10 rumble reports every 120ms. Or every 8 x30 received.
There are numerous ways to do it. Best way is a thread with blocking hid reads. And a second thread for parsing. Lastly, a FIFO queue for the 2 thread communication, would also be a good idea.
Another way is to use a loop with timeout hid_reads and when they are not receiving anything and time out, the parser does keep the same values from the previous packet.
^ this guy knows what he is talking about.
I do support the idea of changing the driver to operate correctly, but it might be a lot of work for mfosse to refactor the code and in the short-term I think we should accept a hack fix that does correct the immediate problem
Ok, then for now the quick fix is to implement a timer. And if dt >= 15ms then send a x01 ouput report and parse the x21 report.
Also about my previous comment, a very simple loop is the one I have here
If you also comment out the limiter if statement, it can reach real time parse of 15ms.
My code is for reference though (because the scope of the app is testing). Check my analog stick parser also. I implemented a parser that uses the calibration (factory or user) and applies center and outer radial deadzones. The good thing is that it can be optimized way further, even though it can still parse real time.
@CTCaer @timmeh87 for now I reduced the poll rate to 60Hz, but this far from perfect and I'll try implementing a better solution when I get back to my apartment (around 5pm eastern)
still experiencing input lag on one of the joycons on dcea71f . It seems vjoy is still being bottlenecked.
Just took a look at the commit linked (dcea71f), and yeah that's more or less the fix I did on my fork, so thanks for doing that and anyone who's been using my fork might as well go back to the main project. I ended up needing surgery (it was successful and I'm recovering well!!) so was never able to get around to making a pull request but I'm happy to see at least that stopgap solution in the main project now.
Also imo @CTCaer's comments are right on the money for a great final solution to the problem.
Glad to hear you're okay!
Edit: Well, I might still need to use your fork. I haven't encountered connectivity issues in 9847582 yet, but I still have important input lag (especially on the left Joy-Con) that is curiously absent with your workaround. I wonder why everyone doesn't experience the same reactivity, is it linked to our Bluetooth adapters?
In ddf5c7c I still get input lag in the right joycon, but when I first start the program, there is little to none. Using the gyroscope visualizer and the vjoy monitor I noticed the input lag doesn't start until about 2-4 seconds after starting the program.
EDIT: it seems the input lag is only present with both joycons connected (regardless of if I combine them or not), if I connect just the right one it's smooth as butter.
@HollyJean's fork is still the superior version. I get the same situation as @theboyboy, where the input lag starts out fine, but then gradually gets worse and worse. The fork is as smooth as butter in comparison. However, the problems with the gyro controls in their fork still stands - whenever gyro controls are on, one of the Joycon disconnects. It's a trade off - input lag with gyro controls vs. no input lag without gyro controls.
@mfosse Even when they aren't connected, it still has input lag. When both are active, regardless whether or not they're connected, it has input lag.
HI!
I too experience delays when using your driver. Without it, there is no lag whatsoever, but unfortunatly I need analog input to play my games. Is there any fix on the way?
I've also seen that there is close to no delay in the first few seconds after your driver initialized.
@Uglynator it's a known bug, and it's sometimes hard to reproduce, what Bluetooth adapter are you using and what version of Windows are you running?
I'm running Windows 10 Pro 64 Bit, with an old Belkin bluetooth USB dongle. I think it's bluetooth 1.1. But the Joy Cons work lagless without using your driver, so I don't really think that's the issue here?
For what it's worth, I'm experiencing the issue with a Windows 10 64-bit laptop and Bluetooth 4.2 (integrated Intel Bluetooth adapter).
@mfosse So... that's odd. I've had these problems since I started using this driver, but today I've been testing the latest version and encountered no input lag issues or disconnects in combined mode. Besides, after closing the driver window, the Joy-Cons weren't disconnected either: both had their first light still on, and I could go back to the regular "Wireless Gamepad" driver by pressing the sync button once, then any button on each Joy-Con. I'm adding this because I often had to re-pair them after interrupting the driver with earlier versions.
I'm not sure which commit triggered this but in any case, great work. I'll test it some more tomorrow.
So I have seemed to notice some things in my own research. At least on my set of joy-cons, the right joy-con seems laggy while the left one is very responsive. I'm pretty sure the polling of the joy-cons is synchronous, so the program must wait for the right joy-con before it updates vJoy. My hackintosh doesn't even recognize my right joy-con as a HID device, but it works with lag in Windows. I think this might be a hardware issue.
I also have a huge lag with this fork. I tried the fork from @HollyJean and this one works without delay, but after a moment one joycon always disconnects. Anyone help?
Is the lag issue fixed? What does everybody use now, perhaps a fork?
@timmeh87 I'd love to see your "fake-joycon" that you made. Please upload pictures.
@theboyboy What is the gyroscope visualizer?
@LAPIII your timing couldn't be more perfect lol. I literally just released the first version of a project that does this, but written in python (I tried working on this one but couldn't stand working in C++ lol). You can check it out here https://gitlab.com/hoppet/joyconvey/blob/master/README.md
@fossephate if you'd prefer me not to advertise my project here please feel free to delete this comment, or ask me to if you can't.