Mouse wheel input is ignored on some mice

[ssokolow]

With ps2x2pico.uf2 or ps2x2pico-200hz.uf2 from the Version 1.0 release:

• The mouse wheel registers just fine on the Gateway pack-in mouse (Model: MOAKUO) that I was testing with in case I screwed up my assembly and fried something.
• The mouse wheel on the Acer pack-in mouse (Model: MOLDUO) that I actually use (better sensor that doesn't just give up on the white hardtop mouse pad I'm used to) has no effect
• Both mouse wheels work just fine when plugged into a PC with USB support

[No0ne]

Yes this is a known issue. Currently all devices a run in boot mode where not all wheels are working.
Eventually I'll have to write a full HID descriptor parser and run in report mode for this to work properly.

Please try the report mode uf2 from here: #1 (comment)

[ssokolow]

Geez, I even commented in that thread. How tired was I?

Anyway, I just realized that I don't need the Acer so, since it's a known issue, unless you think it'd be helpful to the development effort for me to test it right now, I'd prefer to wait until you have a "Release Candidate. Needs compatibility testing" build based on something at least as new as the v1.0 200Hz that I'm running.

(The mouse I really wanted to use is my Logitech G203 Prodigy so I have only one mouse on my desk, and its scroll wheel works fine with the ps2x2pico, but it's a bit picky and sometimes becomes non-responsive maybe 30 seconds after toggling my "I emulate enough USB HID to notice when the scroll lock LED blinks" USB/DVI KVM switch. Now that I've got a brainless USB switchbox in front of it to bridge in the ps2x2pico, I can easily reset the mouse without reaching behind the desk if it decides to crash.)

[No0ne]

Please test your mouse with the non-working wheel with this: https://github.com/No0ne/ps2x2pico/raw/24-ps2-input/ps2x2pico-report.uf2

[ssokolow]

Wll do... though probably after I've gone back to sleep.

The ps2x2pico is now installed in place on the underside of my desk with the cables routed, so it's now a hassle to disconnect the PS/2 side so it's safe to reprogram, awkward to disconnect the USB side so I can reprogram it, and then a hassle to hook it back up to the PS2-USB adapter I prefer to use when testing new firmware.

...maybe I should order another YD-RP2040 and another M-M PS/2 cable to cut up and build another ps2x2pico for the next time I need to test a new firmware.

It'd certainly give me an alternative to the USB4VC on my other desk that requires a whole pre-flight checklist to power on and power off without risking corrupting the Pi 3B's SD card. (By contrast, the ps2x2pico seems to be as simple as "make sure the KVM switch on the USB side is set correctly before powering on the PS/2 side or there's a risk the Pico will refuse to recognize input devices until you cut the 'PS/2 is not hot-pluggable' gordian knot by going through the 'hard power off the PC for lack of an input device and then wait through Scandisk' dance.")

[No0ne]

PS/2 is a little bit hotpluggable. It works under Windows for example, the Pico sends a 0xAA (BAT successful) on both ports and Windows then reinitializes keyboard an mouse new everytime.

[ssokolow]

"Not hot-pluggable" in the sense of "multiple guides I've read tell you not to do it because it's sufficiently 'not in the spec' that, depending on the device, you run the risk of blowing that potentially non-resettable fuse".

For example, this passage from the document I recommended for its pinout diagrams:

Vcc/Ground provide power to the keyboard/mouse. The keyboard or mouse should not draw more than 275 mA from the host and care must be taken to avoid transient surges. Such surges can be caused by "hot-plugging" a keyboard/mouse (ie, connect/disconnect the device while the computer's power is on.) Older motherboards had a surface-mounted fuse protecting the keyboard and mouse ports. When this fuse blew, the motherboard was useless to the consumer, and non-fixable to the average technician. Most newer motherboards use auto-reset "Poly" fuses that go a long way to remedy this problem. However, this is not a standard and there's still plenty of older motherboards in use. Therefore, I recommend against hot-plugging a PS/2 mouse or keyboard.

Of course, in this day and age, "there's still plenty of older motherboards in use" should be changed to "as a retro-hobbyist, you have a high chance that your motherboard is one of the older, worst-case ones".

(Though, ironically, that non-resettable fuse is probably easier for "the average user" to fix than "the average technician", given how many "average users" are likely to be tooled up to replace leaky surface-mount capacitors... which reminds me. I need to save up for some hot tweezers for my Hakko.)

[ssokolow]

Please test your mouse with the non-working wheel with this: https://github.com/No0ne/ps2x2pico/raw/24-ps2-input/ps2x2pico-report.uf2

Tested.

The first time I plugged it in, the cursor drifted to the right edge of the screen at a fixed rate, ignored horizontal movement, and then when i moved the mouse up and down, it appeared to inverse-scroll the scrollbar that happened to be below the cursor but I forgot to examine what it was doing more closely.

The second time, it drifted right for a few hundred pixels, then started to function in a way that appears normal and fully functional (including the wheel) except for the cursor movement being a bit glitchy. (It's hard to be sure, but I think it's that 'counter overflows when moving faster than a certain threshold' bug I remember being mentioned previously.)

EDIT: Also tested with the Gateway mouse and it has that same "slide to the right and interact weirdly with scrollables for a little while, then snap into proper function" behaviour.

EDIT: ...but I think it's crashing my Logitech G203 Prodigy. It does the "slide to the right" thing for maybe half a second, then the mouse becomes unresponsive (remember, this is the mouse that sometimes crashes if switched by the DVI/USB KVM switch that speaks enough USB HID to listen for scroll lock blinks), and, since that one is connected via a USB hub/switchbox, I can confirm that the keyboard is responding at that point.

I'm going to switch back to the working firmware now.

[No0ne]

Ok thanks, yeah I'll have to do the HID parser.

[ssokolow]

I'll also need to get that test clip and USB-TTL Serial adapter out again once it's not so late in my day. It seems that something about testing and then flashing back to the v1.0 firmware I remembered having on it before has it crapping out when I KVM switch away and back.

At the moment, the behaviour is:

1. If I want it to work, I have to set the KVM switch to make the input devices visible before I power on the PS/2 side. (It was always like this)
2. If I KVM switch away and back after it's started, the Logitech G203 Prodigy stops responding but the keyboard comes back fine.
3. If I KVM switch away and back again, there's at least a chance (I only tried it once) that I'll also lose the keyboard.

In any of those failure modes, un-plugging and re-plugging the USB side doesn't fix things and never has.

EDIT: Maybe I should look up which pin is RESET and solder on an alternative to the reset pushbutton buried under the level shifter.

[No0ne]

If you want to debug this I can make you a version which also prints out PS/2 bytes on the serial debug.

[ssokolow]

I'd appreciate having access to it, but, given my degree of mental fatigue right now, I can't say whether I'm willing to commit to actually using it until I've had some rest.

...especially since I tried it again when I forgot to start miniserve on my Linux machine before booting up Win98SE and, this time, it worked fine... which means there's some variable I'm going to need to pin down in order to reproduce it reliably.

(eg. Maybe the success cases were all ones where I waited until the mouse began the "I've booted up. Let me celebrate before I apply your 'LEDs off' saved setting" animation cycle before I tried touching the keyboard or mouse, while the failure cases had me jumping the gun in some way? That might explain the mouse going first and then the keyboard the next time. Without the mouse celebrating the dawn, it's hard to tell when the keyboard will have finished initializing without counting seconds.)

...I suspect I'll probably say "yes" though. Half the reason the ps2x2pico interests me is that it's more idiot-proof than the USB4VC (the other half is because it's, to quote Douglas Adams, "slightly cheaper") and I've already ordered a USB Type C Male to Type B Male cable to take the USB OTG adapter out of the equation as a potential point of failure. Diagnosing this would fit with that.

[ssokolow]

Yeah, I'll do it. I'll have to fit it in around whatever else is going on, but I'll do it.

[ssokolow]

I just realized that might be unclear. It's a "Yes, please offer up the build at your earliest convenience." I just meant that, depending on what comes up, there might be 12-24 hour gaps in my testing."

EDIT: Oh, and a casual test seems to indicate that this "wait for the input devices to init before moving/typing or that input will be stuck nonresponsive" bug is also why I thought I needed to have the USB KVM switch on the correct setting before powering on the PS/2 side of things.

If we can get this diagnosed and fixed, I'm likely to order the parts to build another two, one of which can replace my USB4VC since, if I can trust the ps2x2pico to be goof-proof, it'll be a lot more convenient to turn on and turn off than the USB4VC, and easier to case for ESD protection (Canadian winters), and I don't currently need the USB4VC's "Bluetooth or USB gamepad to IBM PC Gameport or hardware joy2key" support.