Open BangDroid opened 1 year ago
Does this happen every time?
I have the same issue with a single pico variant plugged to the computer rear usb and a jfedor trackball. i can unplug the trackball from the pico and it wakes up. it happens every boot, but using older remapper.uf2 firmware only was happening once every 10 boots.
I made a previous post requesting a watchdog timer which i closed https://github.com/jfedor2/hid-remapper/issues/69
Appears to be happening every time. I tested multiple times over the past few days and while connected to the remapper the Huge always becomes unresponsive, but without the remapper the Huge behaves as expected.
Also as itsnoteasy mentioned, unplugging the Huge from the Pico is sufficient to resume normal operation.
Thanks for the reports. I need to try and reproduce this.
I have done some more testing, and it appears that if i reboot with shutdown -r now, then the trackball does not become unresponsive. it only becomes unresponsive after a cold boot. While unresponsive, there are no messages within the monitor tab at https://www.jfedor.org/hid-remapper-config/ but i can open the device, and load all the settings from it.
Just sharing more information and experience. Logging in today with the Huge connected to Pico it was unresponsive on login screen, after logging in and waiting a few moments, I noticed the DPI indicator on the Huge flash and the Huge woke up and was fully responsive. The wait was maybe 30 seconds. I'll admit I was probably impatient the previous times, standard HID behavior is usually immediate, but I suspect this is what's happening. For whatever reason the Huge is slow to wake when connected to Pico. I may not have created this issue knowing this, it's certainly acceptable to me to have a delay, compared the having to un/replug. I will leave this open for now as maybe it's an indicator of something undesired.
I stopped using the hid-remapper because i detested replugging, but it turned out that my trackball needed to be replugged, so i must retract my bug report, as it could have been the trackball causing the issue. my gut feeling is that both jfedor devices, the jfedor trackball and the remapper have the same bug, but i haven't used an oem mouse enough to compare with. my current workaround is to solder a normally closed microswitch in series in the 5v usb wire. when it locks up after boot, i click the switch. I have started to use the remapper again today, because the workaround seems to reset both devices. I have also installed a ryzen cpu and new mobo in my system, so that eliminates my system as a fault. edit: a little searching indicates that there appears to be a bug in linux causing the usb issues.
I think I have almost the same issue, but with Elecom Huge Wireless.
I was using an older version of your firmware. After updated to latest version, the Pico is not working after a cold boot. I need to unplug and plug again the start working.
If I flash the older version, it is back to working flawless.
Older firmware compiled by me: 1a4eec1 . Pi Pico single. Windows 10.
I have also tried this older firmware linked by leokesler. It has fixed my cold boot replug issue, but I haven't been able to program it with the browser since the tap and hold feature is missing. i noticed that with the new firmware my cursor tended to jump 5mm about once a minute on the screen. i thought that it was dust on my sensor causing it, but it is completely absent with the older firmware. edit: cursor jumping has reappeared, so belay that complaint.
This is a good lead, I should be able to git bisect, except I don't think I'm getting the issue on my PC. Will try to look around.
i have updated to the latest release and the cold boot issue appears to be gone. good work jfedor. had you intentionally fixed it or was the fix by accident?
I haven't done anything to fix this specifically. It's possible that something changed internally in TinyUSB and we got a behavior change when we pulled the latest version in.
So, I'm in a similar-ish boat:
@itsnoteasy @LeoKesler do you know what versions of the firmware you're currently running and whether or not you have the problem with it?
I don't use a usb hub, and i dismantled the jfedor trackball, but i upgraded to r2024-02-14 single pico variant with the kensington expert wired. the pc boots without issue with my ryzen 5. I haven't tried sleep modes, as i have them disabled. I think there's an old linux kernel bug with sleep modes so your issue may not be hid-remapper's fault.
@jasonanovak I am not using Elecom Huge Wireless anymore, because the many issues with connect / disconect and battery issues. It was a huge mistake to buy the wireless version.
Currently, I am using the Protoarc EM03. It is wireless too, but I never got a disconect from it. Almost perfect device, except for the size ( I have big hands) and the lack of additional button at right side, like Elecom Huge.
Same issue here with single pico and Elecom Huge wired. After the PC wakes from sleep or reboot, it needs to be unplugged and replugged. I tried several other devices but only the Elecom Huge is like this. Windows 11. Using the latest firmware, r2024-06-27.
I have a similar problem with an Adafruit Feather RP2040 with USB Type A Host and a Apayado K33 keypad that I've remapped to allow easy hex input for Windows calculator etc. It all works really nicely on Windows 10 and Windows 11, but if I unplug and then plug either the Feather from the PC or the keypad from the Feather it's unresponsive until I press the reset. I've tried leaving it for a few minutes and that makes no difference, it is unresponsive until I press reset. I am using the latest FW from the bottom of the readme section of the project page (remapper_feather.uf2) Have I missed something silly or is this how it works?
I had the same issue after waking up from hibernations. Shutdown and restart used to solve the issue. I started using a different keyboard and it has solved the issue I believe. i am doing more thorough testing to see if the issue reappears somehow. will post an update here if something happens.!
there was another issue, in general with any of the keyboards that are not connected via remapper are connected and disconnected repeatedly , not immediate connection and disconnection but repeated connection and disconnection makes the keyboard unresponsive. idk if this is the root cause for unresponsive remapper-connected keyboard. but it would be wise for others to check if it is the same with their systems.
i have recently enabled selective usb suspend setting in power settings. not disable, but enable. idk if this has solved my issue.?! ie., more testing is needed. , will update here. will test using "leokesler" build too this month and update.
i tried to create a fork of this repo and attempted to make the remapper to renegotiate the connection after PC wakes up, but i am not a good so, it didn't work.
using windows 10 Pi Pico single generic keyboard arduino is connected to another usb port 4ish keyboards connected at the same time to pc
Single Pico variant, latest firmware. Connected to Elecom Huge wired. After shutting down Windows (10 21H2) and restarting the next day, no input was detected, neither the indicator led on the Pico was lighting. Unplugging the the Pico (with Huge still connected) and re-plugging resumed correct function. Pico is connected directly to computer rear USB not a hub. Any ideas what could cause this? TIA