Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Joycon input lag, constant need to restart daemon, and taking a long time to restart daemon #143

Open
HoodedDeath opened this issue Jun 30, 2024 · 0 comments

Comments

@HoodedDeath
Copy link

Got a few issues, which are all in the title.

  1. Having two JoyCons connected leaves whichever one connected later with noticeable input latency. I'm not sure if that's caused by this daemon, but I couldn't find any help about controller latency by searching online and testing variations of bluetooth latency fixes led me nowhere, so I'm just adding it here in case it's important to anyone.
  2. On pairing/first connect of JoyCons, everything works perfectly. If I disconnect the JCs, the daemon doesn't destroy its virtual input device, which leaves it unable to create a new one if the controllers reconnect. This leads me to needing to restart the joycond service any time I'm reconnecting my controllers, which becomes incredibly annoying with my third problem.
  3. Upon starting joycond, if it had been started previously (aka, I'm restarting it to get my controllers to reconnect), it will sit is disk-sleep for a random and sometimes LONG time. I assume this is it removing a virtual device left over from the last instance, since I see Removing /devices/virtual/misc/uhid/0005:057E:2007.001E/input/input62/event27 from unpaired list in the output around this time. During this disk sleep, joycond is unable to setup the joycons, leaving them waiting in the same limbo they end up in if I reconnect them without restarting the daemon.

My second problem may be the same as #136, #124, and #107

For my third problem specifically, I resorted to making a script for restarting the service and showing me when it's ready to use.

function _dowait {
  while true; do
    pid=$(pgrep joycond)
    stat=($(cat /proc/$pid/stat))
    running=${stat[2]}
    if [[ ! "x$running" == "xD" ]]; then
      break
    fi
    sleep 0.5
  done
}
sudo systemctl restart joycond.service
sleep 1
time _dowait
echo JoyConD ready.

In my roughly 4 hours of testing this daemon out, I have seen this waiting period being anywhere half a second, to over 3 minutes. The difficulties with reconnecting controllers and

I'm not going to assume the input lag is this daemon's fault, especially as it's only effecting one joycon and is dependent on the order they connected in. If anyone has some input for that, I'd be happy to hear it.

Maybe I'll give a shot at figuring out more about the reconnect and restart issues in the future, but right now, I don't know the codebase, so I have nothing for it.

Possibly relevant system info:

  • Arch linux
  • Installed via AUR joycond-git
  • Version v0.1.0.r54.g9d1f509-1 (as reported by pacman)
  • Bluetooth via Intel Corporation Wi-Fi 5(802.11ac) Wireless-AC 9x6x [Thunder Peak] [8086:2526] (rev 29), using iwlwifi kernel driver
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant