Keyboard Issues

[h0ly0ne]

When KeyPresses with my Keyboard (Logitech Unify Keyboard K400+) are entered slowly and with a slight delay (half a second) everything seems to be fairly ok - seem to work flawlessly then. Using legacy PS/2 equipment does not produce any of the these behaviors - so it seems to be replated to the ps2x2pico somewhere.

But when playing a game (is reproduce-able in DungeonKeeper D3D within playing a few minutes) the cursor keys seem to "hang". So when pressing "LEFT"-cursor key for longer than 1-2seconds the key hangs and permanently sends "LEFT"-cursor to the game (even when the key is released). Only solution is to press and release the "LEFT"-cursor again shortly (not longer than a second). The same behavior could be reproduced when playing Unreal.

Additionally when this "hanging" happens there also seem to be random "ghost" keypresses (other keys) and also mouse movement (not sure about the mouse movement as it seems to produce "ghost" movement on its own without any keypress at all)

And last but not least - the complete system seems to freeze when this "ghost" actions appear to often. So randomly after 1 to 60 minutes the system freezes whenever you trigger these behaviors at least once. Only a Reset/Repower does resolve this issue.

Version used: 0.8 (i think) - most recent download available as release. System/Mainboard used: MSI 875P Neo-LSR/ FIS2R (Pentium 4 Board)

[No0ne]

Does this reproduce in notepad or other programs, or only in-game?

[h0ly0ne]

Back from testing machine - and this "keyboard issue" seems to be a red herring. When trying out the keyboard in e.g. Notepad it seems to work flawlessly - but you do not move your mouse at all when just testing the cursor keys of your keyboard. But when you in addition move your mouse during testing the cursor keys in Notepad you see the "real" problem - the mouse is sending keypress"es"!

Just a short sample from my testing:

Default pattern of my testfile: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Pattern after LEFT-cursor testing (no changes!): xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Pattern after LEFT-cursor testing with mouse any direction (as you can see have moved the mouse three times): xxxxxxxxxxxxxxxx4444444444444xxxxxxxxxxxxxxx44444444444444444xxxxxxxxxxxxxxxxx44444444444444

Pattern after RIGHT-cursor testing with mouse any direction (as you can see have moved the mouse three times): xxxxxxxxxxxxxxxx66666666666xxxxxxxxxxxxxxxxxxxxxxxxxx6666666666xxxxxxxxxxxxxxxxxxxxxxxxxxx6666666

Pattern after DOWN-cursor testing with mouse any direction (as you can see have moved the mouse three times): xxxxxxxxxxxxxxxxxxxxxxxxxx22xxxxxxxxxxxxxxxxxxxxxxxxxxxxx22222xxxxxxxxxxxxxxxxxxx2222xxxxxxxxxxxxxxxxxx

Pattern after UP cursor testing with mouse any direction (as you can see have moved the mouse three times): xxxxxxxxxxxxxxxxxxxxxx88xxxxxxxxxxxxxxxxxxx88x88xxxxxxxxxxxxxxxxxx88888xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Notepad really gets crazy when pressing e.g. LEFT(0,5s)+UP(0,5s) and moving the mouse - here it seems that there are sent some system presses (e.g. pasting current date, selecting all text, right mouse click, alt+tab, alt+escape etc.)

In addition I am monitoring some "non working" states of the pi pico sometimes when powering up the system (around 50% of times) - it seems that multiple power on/off then somehow solve that issue and keyboard+mouse seem to work until repowering the system again.

[No0ne]

Thank you for the detailed report! This narrows it down to packet collision detection which seems to not work 100% correct. Will try to replicate this and send you a fixed UF2 when I've found the bug, but this might take a while since time is limited at the moment.

[megaloegoman]

Thanks for this space saving, open source, product. I've been using it to play Doom with both the keyboard and mouse plugged in. But I'm getting random key presses (usually always to escape key) every ~10s. This doesn't happen when the mouse isn't sharing the ps2x2pico. Could it also be due to the packet collision you described?

[No0ne]

Yes I suspect that, but I'm currently out of time to look into this. Will resume in spring/summer.

[No0ne]

ps2x2pico-locking-test.zip Could you both please retest with this version an report if the issue is fix? Thank you!

[megaloegoman]

Terrific! The random key strokes are gone now. I've tested it on 2 retro PCs. One Pentium 3 based, running Counter-strike and another 486 running Doom. Also tried pressing several keys at a time to see if that's handled. I saw the USB HID spec says up to 8 keys can be held together.

I see you have a 3rd developer now. Actually I'm a software developer, so I was thinking of contributing. But it looks like you or the other 2 beat me to it twice already. I 1st heard about your project on 8/19 on Vogons. https://www.vogons.org/viewtopic.php?f=46&t=57471&start=40. I was thinking of adding support for PIO, but you already did that. Here's a picture of the 2 devices I made. It's made very compact by using a waveshare RP2040.

Actually, I had a look at the code 2 weeks ago and my biggest suspicion was that the keyboard and mouse run on the same PIO unit and share the same interrupts (0 & 4). Won't that cause missed or ambiguous interrupts unless you run them on different PIO units. But then it seems like you can no longer use the same PIO program for both since the interrupt #s have to be compile time constants.

The only problem I have now is that I cannot power on the PC with the keyboard + mouse + hub connected at the same time. It seems that's too much load and causes the rise time to not be fast enough and causes some power-on-reset detector to not trigger. I had to power on with only the hub & keyboard. Then plug in the mouse (Microsoft optical Intellimouse). Have you encountered this?

Thanks for the fix, -Yale

On Sat, Jan 27, 2024 at 2:40 PM No0ne @.***> wrote:

ps2x2pico-locking-test.zip https://github.com/No0ne/ps2x2pico/files/14074183/ps2x2pico-locking-test.zip Could you both please retest with this version an report if the issue is fix? Thank you!

— Reply to this email directly, view it on GitHub https://github.com/No0ne/ps2x2pico/issues/19#issuecomment-1913356074, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEZ27QXE4HEASXE5MC3UB7LYQV65FAVCNFSM6AAAAAA7GIG732VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMJTGM2TMMBXGQ . You are receiving this because you commented.Message ID: @.***>

[No0ne]

I'm currently running all HID devices in boot mode, so the keyboard sends 8 bytes but one is used for all modifiers and one is unused so in total six keys can be held together. There was a fork by anteo which is gone now (don't know why) which switched from boot mode to report mode which allows more keyboard and mouse feature (more keypresses and mousebuttons). I'll try to implement that in the future.

Development is mostly done by my self, had some contributions, the biggest ones by hoffman373 and serisman.

The main problem was that both PIOs started transmitting nearly simultaniously and most mainboards only can read one PS/2 port at a time, so they lock the other port by pulling clock down. But is only after the start bit was sent which was too late for the second PIO to pause transmission. The fix was a 1ms global lock+cooldown timer for transmissions. The interrupts you mentioned are ok as they are set with the "rel" argument so the statemachine index is added to the irq number: sm0 sets irq0 for busy and irq4 for failure and sm1 sets irq1 for busy and irq5 for failure.

The power on issue i saw my self with the Raspberry Keyboard and Mouse with the built-in hub. Don't know if its a tinyusb bug or not, I'll have to investigate!

Thank you Yale for testing and reporting success.

[megaloegoman]

I see, I never anticipated the problem you described. I only was thinking if any data from the keyboard/mouse to the PIO got lost (e.g. lost interrupts), but didn't consider anything after that. I did know about clock stretching from I2C and PS/2 from a long time ago, but never had to handle it.

I don't think not being able to power both devices is due to software, assuming there's nothing gating the power pins. I'll see if adding an external power supply helps or reducing the resistance of the wires. I have an oscilloscope, so can measure how fast the voltage rises and also if the current draw exceeds the PS/2 limit.

Let me know if there's anything else I can help with. Handling the clock stretching inside the PIO code would be ideal, but could be difficult since the program already takes up the maximum 32 instructions. The I2C example from the SDK could help. Also, you already have code to handle it by setting interrupt 4, but maybe not restarting the byte transmission.

On Sun, Jan 28, 2024 at 3:19 AM No0ne @.***> wrote:

Closed #19 https://github.com/No0ne/ps2x2pico/issues/19 as completed.

— Reply to this email directly, view it on GitHub https://github.com/No0ne/ps2x2pico/issues/19#event-11619673619, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEZ27QRPFKCZPINECHLZFN3YQYX5NAVCNFSM6AAAAAA7GIG732VHI2DSMVQWIX3LMV45UABCJFZXG5LFIV3GK3TUJZXXI2LGNFRWC5DJN5XDWMJRGYYTSNRXGM3DCOI . You are receiving this because you commented.Message ID: @.***>