[Bug] Ploopy Classic scrolls erratically and erroneously during mouse movement after reconnect
Describe the Bug
I'm using the Ploopy Classic trackball (running QMK) with a USB switch plugged into two computers. When I press a button on the switch to change to the other computer, moving the mouse will randomly start scrolling a little bit. It's noticeable due to things like seeking in mpv getting activated when I just try to move the mouse. It took me a while to realize what was going on. I thought maybe I was bumping the scroll wheel, but that's not it. Usually what I'll do is find somewhere I can scrolll and then move the mouse wheel a bit, then go into drag scroll and scroll up and down, then turn off drag scroll again and it doesn't have issues beyond that point. Not sure how much of that process is necessary. I think of it a bit like an analog stick being stuck going in a direction because it was being pushed that way when the controller was plugged in, or like a shift key getting stuck until you press it again.
System Information
Keyboard: Ploopy Classic
Revision (if applicable): Ordered quite recently (this year), going to say it's the latest revision of the mouse probably.
Operating system: Guix System GNU/Linux and Windows 10 Enterprise (happens on both)
qmk doctor output: Not sure if this is relevant, and I usually compile and flash on different machines + use dfu-programmer for the flashing... if it matters a lot I can get it from whichever machine(s) later
(Paste output here)
Any keyboard related software installed?
- [X] AutoHotKey (Windows) (yes on the Windows machine, no on the GNU/Linux machine, so likely irrelevant)
- [ ] Karabiner (macOS)
- [ ] Other:
Additional Context
USB Switch used: https://www.amazon.com/dp/B01N6GD9JO/
I had the switch for a little while before I had the Ploopy and I did not notice any similar issues with my Logitech G400.
I can get my QMK files off the other machine I do the build on if needed. I basically combined the VIA profile (although I have never used VIA and don't plan to) and drag_scroll profile and then lowered the DPI presets a lot. Everything works great besides this weird scrolling issue.
could you use the firmware from http://qmk.tzarc.io and see if that resolves your issue?
Sorry, haven't gotten around to trying this yet. Are there instructions anywhere for setting up that version? I may be able to get to it this weekend.
edit: I thought it was another branch/fork of QMK where you'd tweaked some things. I guess maybe you just want me to flash some pre-made layout and see if the bug happens there. Can't recall what the 005 means and if I want that one or the regular one.
I flashed ploopyco_trackball_rev1_005_via.hex from that page and was still able to recreate the issue. I activated the USB switch twice to leave and then return to controlling this PC, then a few seconds of ball movement with no contact with the side of the mouse and it seeked forward 10 seconds in mpv as if I'd scrolled up.
the qmk.tzarc.io compiles from the qmk develop branch, and is very up to date.
And is it just scrolling that happens, or other behavior?
As far as I can tell, everything works normally besides the strange unintentional scrolling. The mouse still moves with the ball, but it will occasionally scroll.
@Soundtoxin Sorry for half hijacking the thread, would you be able to send your QMK package? Thanks in advance, nouun.
@nouun
@Soundtoxin Sorry for half hijacking the thread, would you be able to send your QMK package? Thanks in advance, nouun.
What do you mean? Like the qmk binary I'm using? or my configs? is uploading /usr/bin/qmk enough or would you need other files too? ls -hal /usr/bin/qmk shows a date of December 2nd on one of the machines I have qmk on. I have built my configs on a couple different [non-primary] machines and then I just flash the hex on my PC with dfu-programmer after I copy it over due to issues getting the full qmk tooling working locally.
Wait, this is a USB switch and / or drag scroll issue?
I had been troubleshooting this (weird, jittery constant scrolling after boot) as an encoder calibration issue with my Ploopy Mini. I recently switched back to my Classic and noticed the issue continued. I never had the issue with my Classic before, but I suspect I had not been using it with my USB switch.
In my ploopy_encoder_recalibrate branch, I change the encoder logic to perform a recalibration on every invalid greycode transition (matching the behavior of the "simple" optical encoder implementation). Using my branch (or the "simple" optical encoder code) I am able to regain regular behavior just by scrolling one way or the other.
This also effectively works around an issue with the scrolling becoming erratic with my Classic when sunlight comes in my office window in the afternoon.
It looks like I need to investigate USB behavior as well. A couple of questions:
Does anyone remember a period when the scroll wheel worked correctly after a boot, even when connected to a USB switch? I'm trying to work out if this might be a regression.
Could anyone with this issue post the output of lsusb?
Mine, for reference:
$ lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 002: ID 05e3:0608 Genesys Logic, Inc. Hub
Bus 003 Device 003: ID 048d:5702 Integrated Technology Express, Inc. RGB LED Controller
Bus 003 Device 004: ID 1235:8212 Focusrite-Novation Scarlett 4i4 USB
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 005 Device 002: ID 05e3:0608 Genesys Logic, Inc. Hub
Bus 006 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 007 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 007 Device 008: ID 05e3:0610 Genesys Logic, Inc. Hub
Bus 007 Device 009: ID 3434:0433 Keychron Keychron C3 Pro RGB
Bus 007 Device 010: ID 5043:5442 Ploopy Classic Trackball
Bus 008 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 008 Device 004: ID 05e3:0626 Genesys Logic, Inc. Hub
> lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 8087:8008 Intel Corp. Integrated Rate Matching Hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 002: ID 058f:9540 Alcor Micro Corp. AU9540 Smartcard Reader
Bus 002 Device 003: ID 17ef:1010 Lenovo ThinkPad Ultra Dock Hub
Bus 002 Device 050: ID 0bda:5411 Realtek Semiconductor Corp. RTS5411 Hub
Bus 002 Device 099: ID 544e:7034 tamanishi Pinky4
Bus 002 Device 101: ID 05e3:0610 Genesys Logic, Inc. Hub
Bus 002 Device 102: ID 5043:5442 Ploopy Corporation Trackball
Bus 002 Device 103: ID 544e:7034 tamanishi Pinky4
Bus 002 Device 122: ID 17ef:100f Lenovo ThinkPad Ultra Dock Hub
Bus 002 Device 124: ID 0d8c:0008 C-Media Electronics, Inc. C-Media USB Audio Device
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 002: ID 8087:8000 Intel Corp. Integrated Rate Matching Hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 004 Device 026: ID 17ef:1010 Lenovo ThinkPad Ultra Dock Hub
Bus 004 Device 027: ID 0bda:0411 Realtek Semiconductor Corp. Hub
I don't recall having issues shortly after boot, but I may have just not noticed since I go from LUKS to GRUB to LUKS to a TTY and then start sway from there, no mouse needed that whole time and it takes a few minutes to get that far.
I don't use my switcher nearly as much as I used to (as in I don't hit the button, it's still always plugged in), so while this issue definitely is still around, it's not as big of a deal to me. I went from going between personal PC and work PC to going between personal PC and Steam Deck, and I rarely will go back and forth quickly anymore.