You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
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.
Got a few issues, which are all in the title.
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.
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:
Intel Corporation Wi-Fi 5(802.11ac) Wireless-AC 9x6x [Thunder Peak] [8086:2526] (rev 29)
, usingiwlwifi
kernel driverThe text was updated successfully, but these errors were encountered: