Closed serisman closed 2 months ago
I did some further testing, and my assumption was indeed true. I made some code changes and now it works much better. I'll clean it up and submit a pull request sometime tomorrow for you to review.
Hi, thanks for your feedback! Yes you are right, the mouse support is still very sparse.
I've currently only tested it on Windows 2000 as there are still some issues left. I need to port the PS/2 protocol part to the Pico PIOs so that both channels can send/receive independently. At the moment it is just a port from ps2pico where CPU based bitbanging was enough since theres only the keyboard PS/2 channel. In my other repo ps2x2pico-rs I already tried PIO support with Rust, but there the USB support is a bigger problem.
I also found out that all my USB mice with the PixArt chip still do native PS/2 using the green passive adapter! E.g. the official Raspberry Pi Mouse or the Microsoft Basic Optical Mouse
I hope I'll finish the PIO implementation this year.
I'm using this with a Logitech wireless keyboard/mouse receiver, so those green passive adapters won't work for me. :( That's why I was excited to find your project to begin with.
I just submitted Pull Request #2 with some better mouse code for you to review. It still isn't a 100% complete mouse driver, but does the main stuff better than before (i.e. switching between the different mouse types and honoring the corresponding data packet format).
I have tested this in MS DOS with the CTMOUSE.EXE and MS MOUSE.EXE drivers as well as with Windows 3.11, and all seems well. I did run into a weird race condition when trying to run ctmouse /o
where the 'key up' event of the ENTER key from running the command takes time away from the mouse initialization and causes weird issues. If I just use ctmouse
or put the command in a batch file with a pre-delay, everything works correctly. I suppose what you mention about using PIO is probably the real solution that is needed.
Thanks for your PR! Quick sidenote: I did compile the UF2s with Pico-SDK develop branch because of this https://github.com/raspberrypi/pico-sdk/issues/483 Will do a new release with your enhancements soon!
Yeah, I had to do something similar. I think I just updated the tinyusb git submodule to the latest. Without doing that, only the keyboard was working. Took a while to track that one down. Finally realized I could get some debugging info by connecting a USB TTL serial to the UART!
Did a port of the PIO transmit code from the ps2x2pico-rs repository. Sending data on each channel independently looks promising now. Receiving via PIO is still missing on the pio-testing branch.
That looks pretty promising! I'll have to check it out in more detail later.
I had one other thought for optimization, although I'm not sure how useful it would be once the PIO work is done. Anyway, might be helpful to have all the serial logging controlled by a debug flag and produce two different binaries (one for run-time, one for debug). The serial output is very useful for debugging, but it does steal some time from the PS/2 code. During normal operation it seems kinda wasteful for all that serial processing to continue to happen. It's like shouting into the void with no one listening.
Please try the new binary from the pio-testing branch: https://github.com/No0ne/ps2x2pico/raw/pio-testing/ps2x2pico.uf2 I've only tested it on Windows 2000 so far, but there still seems to be an issue if you drag the typematic sliders in the keyboard preference panel. The mouse starts jumping vertically. Also the PIO code is still messy right now.
@No0ne - I finally had a chance to do some testing of your pio-testing branch, and everything seems to be working fine on my side. I did some testing with both MS-DOS 6.22 as well as Windows 3.11 and didn't notice any issues. Good job!
Cool! I still have issues on Windows 2000, especially when changing key repeat settings in the system control panel. I think I need to capture some data between real PS/2 devices and different PCs and mimic the timings as close as possible. Also found out that min/max pauses between bytes do matter and are different on for example NuXTv2 and my P3B-F.
The PIO code is much more refined right now, but still not working 100% of the time. Please try if this is still happening with the latest build [5f96329]:
I did run into a weird race condition when trying to run
ctmouse /o
where the 'key up' event of the ENTER key from running the command takes time away from the mouse initialization and causes weird issues.
Thanks!
The PIO code is much more refined right now, but still not working 100% of the time. Please try if this is still happening with the latest build [5f96329]:
I did run into a weird race condition when trying to run
ctmouse /o
where the 'key up' event of the ENTER key from running the command takes time away from the mouse initialization and causes weird issues.
Sorry, but with the current version the mouse isn't working at all. It works again if I rollback to the Dec 7th version as long as I have ctmouse in the autoexec.bat, but not if I just type it on the command line.
@No0ne @serisman Can you guys share Dec 7th version? (the link above is broken) The latest beta 0.6 does not work at all on my Toshiba 430CDT using my build described at #16. I see lot of communications in oscilloscope, but in the end laptop is not taking any external mouse events.
I'm currently rewriting the whole PIO code as part of integrating to the PiKVM pico hid project. I hope this will fix all mouse related issues, please give me some to finish.
@serisman if you still have the board around you could test the new pre-release, @nanoant this is the 0.6 replacement: https://github.com/No0ne/ps2x2pico/releases/download/beta-0.7/ps2x2pico.uf2
@No0ne - I've mostly moved on to the HIDman-mini / HIDman-micro boards that I designed (https://github.com/serisman/HIDman-mini), but yes, I do still have a ps2x2pico board around I could do some tests with. Can you remind me what pins need to be swapped to try the new firmware?
Cool, please see https://github.com/No0ne/ps2x2pico/releases/tag/beta-0.7
Ok, I've done some additional testing with DOS 6.22 (CTMouse driver) and WFW 3.11, and overall it looks pretty good. My original mouse issues seem to be resolved!
I did notice two potential issues, although I have no idea how I got into this state.
The only other thing I noticed is that the mouse acceleration seems pretty high. Not sure if that can be dialed down at all?
Cool! Finally the PIO version makes progress over CPU bitbanging =)
I'll WFW 3.11 my self, hope I can reproduce it.
I believe the problem is the mouse rate. Currently it sends mouse packets as fast as possible/as fast as the usb reports come in. I'll have to implement proper mouse polling rates, maybe this fixes the acceleration too?
Hi @No0ne. I confirm that 0.7 works also on my Toshiba 430CDT, sort of...
Anything I can possibly do to help here? I have couple of different mice and portable oscilloscope.
Anyway this is a great progress! Many thanks for keeping this project alive.
Thanks for testing! I think its almost certainly the polling rate issue. Should soon be fixed with beta-0.8, please test again after release.
Hi @No0ne. I tested 0.8 today and it is almost perfect:
Thanks for this great work. Let me know if I can support you anyhow. Best, Adam.
Cool, thanks for testing again! I think I'm getting there, but its a lot harder than I thought 😅 Will do further refinement, afterwards please test the new release.
Hi there,
thank you for this awesome project! I've build it up as well and have been testing.
Setup:
I've encountered these issues so far while testing with beta-0.8:
Please let me know if you'd like more information or want me to test something!
Yeah already discoverd this problem my self. Currently the USB stack directly starts the PS/2 transmit process and I'll need to decouple this and sum up intermediate movements. I hope I have some time for this after christmas. I'll let you know if theres something new to test.
@nanoant could you please retest with this version an report if the issue "2. mouse craziness" is fix? Thank you!
@nanoant could you please retest with this version an report if the issue "2. mouse craziness" is fix? Thank you!
Hi. Unfortunately after around 5-10 minutes of perfectly stable behavior the mouse started jumping around generating random clicks, same Toshiba 430CDT setup as before.
While implementing https://github.com/pikvm/pikvm/issues/476 I discovered I can at least reproduce the "mouse jumping around" now if I move the KVM mouse and passthru mouse at the same time. Theres hope for a fix!
I've implemented a sample rate timer now.
@nanoant could you please retry with this: https://github.com/No0ne/ps2x2pico/raw/24-ps2-input/ps2x2pico-boot.uf2 https://github.com/No0ne/ps2x2pico/raw/24-ps2-input/ps2x2pico-report.uf2
The first one runs the mouse in boot mode (as it always was). The second one runs the mouse in report mode (I discovered my wheel only works in report mode).
@seritools please also try the two files above with more than 125 Hz, thanks!
Tests with just the mouse, at 1000 Hz polling rate:
-report.uf2
:
Latency issue is gone, but moving the mouse to the right moves the cursor down, left moves it up, top/down don't work at all.
-boot.uf2
:
Movement works without latency, however fast movements seem to cause the cursor to jump in the inverse direction, like an overflow in the variable used to sum up the movements? Let me know if you want a video showcasing the issue. With the G502 the mouse wheel seems to still work in boot mode.
Test with kb+mouse and -boot.uf2
:
The freeze seems to be gone! 💜
Ah yeah, maybe these need to be bigger than u8: https://github.com/No0ne/ps2x2pico/commit/0ca3e6403c90902dacea0244f2d82c2e9d8a08a4#diff-e25424adb57c069078b41d0ac8adbc71d89db4d8a01f32ab5164dd27e21ce164R37
Ah hm, this sounds like overflow yes. I'll have to cap it at 0xff since I can't send anything larger than 8 bits.
I think I finally fixed it! Did forget that PS/2 movements are 9-bit signed, so I did implement that extra bit. And if the accumulated values are larger/smaller than 255/-255 the remainder will get transmitted in the next mouse packet.
@seritools please try again, thanks! https://github.com/No0ne/ps2x2pico/raw/24-ps2-input/ps2x2pico-boot.uf2
Also the sample rate is now controlled by host settings e.g.: https://i.ytimg.com/vi/rlMeUHGYIiU/maxresdefault.jpg
Just tested again, seems to work flawlessly now ❤️
Thanks @seritools! @nanoant if you can confirm please, I'll make the 1.0 release finally 🙏🏻💪🏻
@serisman if you could also test it, that would be nice: https://github.com/No0ne/ps2x2pico/raw/24-ps2-input/ps2x2pico-boot.uf2
Just did some quick testing on my hardware.
I had some issues where both the keyboard and mouse would completely freeze or not be recognized without a hard reboot. Once or twice I had it happen after entering the BIOS. One or twice the mouse wasn't recognized when the ctmouse driver tried to load it in autoexec.bat. Once, they both froze up after re-entering Win 3.11 after entering/exiting it a few times.
But, as of right now, they are both working flawlessly both in DOS and also Win 3.11. So, not sure if there is still a code problem, or just some weird issue with my hardware config.
Either way, don't hold up a release because of issues on my end. I usually use my custom HIDman-micro board these days anyway.
It just froze up again. It was sitting at the DOS prompt while I typed that reply. After I was done, I re-entered Win 3.11 and everything was working. I exited to DOS again, and at least the keyboard was still working. Then I re-entered Win 3.11 and both the keyboard and mouse are frozen. No way to get them working again that I can think of without performing a hard reboot of the computer. (rebooting the Pi Pico doesn't help).
@No0ne I am sorry but ps2x2pico-boot.uf2 make mouse completely dead after Win98 Toshiba laptop boot or it emits completely random events on the other boot. With ps2x2pico-report.uf2 mouse moves only in one direction but mouse buttons function fine (8-bit overflow?).
ps2x2pico-locking-test.zip works still much better albeit it starts to jump after a while (as previously reported).
Also in Win98 I neither see Microsoft PS/2 Mouse
nor rate settings. I see something like WheelMouseIM
device and Toshiba
as manufacturer of the driver. But my physical PeriMice-209 PS/2 mouse works flawlessly there.
Thanks for all the feedback! Seems 1.0 is still a bit away, I'll work on it.
Hey everyone, if you could please test again that would be nice, thanks! https://github.com/No0ne/ps2x2pico/releases/download/1.0/ps2x2pico.uf2
V1.0 alpha works well with my G305 @ 500hz, though I needed to use PS2Rate to change the rate in Windows 98. The default was very choppy compared to using the same mouse with the Minicom PS2 to USB adapter.
There also might be some intermittent stutter, though I'll need to test this a bit more.
Just checked and yes, Win98 default sets the rate to 0x28 = 40hz which means 25ms between transmits. I currently apply the sample rate requested by the host but if you want we could also hardcode it. Please explain if you have more details about stuttering, thanks!
Just tested again with 1.0, works flawlessly over here. 🎉
And wow, PS2Rate makes a huge difference, TIL Win9x sets it to such a low value. Maybe having a second FW version or a HW switch through another GPIO for forcing a sample rate might make sense?
I've been testing a modification which forces a constant sample rate - ignoring host requests to change it. https://github.com/No0ne/ps2x2pico/pull/28
Both 100hz and 200hz are working well enough for me to comfortably replace the Minicom adapter I was using. Playing Unreal on Windows 98 feels fantastic and responsive; with PS2Rate no longer being necessary.
ps2x2pico_mouse_100hz.uf2.tar.gz ps2x2pico_mouse_200hz.uf2.tar.gz
There still might be an issue with stutter or jumping, but I'm not sure it's due to ps2x2pico. It's not noticeable 99.9% of the time and may be due to the G305 itself. Anyway, the current pre-1.0 release gets my thumbs-up for an official 1.0 release. I recommend that there be at least two artifact variants:
A 200hz artifact may also make sense to include.
Just checked that 200hz with mouse wheel enabled doesn't work without overclocking the ps/2 port. The fourth byte is around the 5ms mark which the next first byte should be. With a 2x overclock the transmission is over 20kHz clock this exeeds the proposed max 16kHz.
Correction: it does start to work above around 14kHz so I could release a 200Hz version with a higher clock.
5628f15 is now optimized, 200Hz mouse movement should work now. PS/2 clock is at 15.625kHz and theres a little bit more than one byte of time space between mouse packets 🥳
5628f15 is now optimized, 200Hz mouse movement should work now. PS/2 clock is at 15.625kHz and theres a little bit more than one byte of time space between mouse packets 🥳
I wasn't having any issues with the wheel previously, but I've confirmed this change works on my end (ABit AV8 motherboard).
First of all, awesome project!
It was super easy to get a Logitech wireless keyboard/mouse (K345/M275) combo up and running on an old DOS PC with only PS2 ports.
I haven't found any issues with the keyboard at all, but the mouse code seems buggy.
I am testing with both the CTMOUSE.EXE driver as well as Microsoft MOUSE.EXE driver. With both drivers, by default, the mouse cursor jumps around pretty randomly and it seems like button presses are being toggled without actually pressing anything. No amount of tweaking the driver's resolution seems to help things. Eventually, I found that the /O switch on CTMOUSE (which enables wheel support) seems to work... about half the time. Other times it just reports 'Error: device not found".
I think what is happening is that this code is always reporting 'Mouse with scroll wheel' and sending 4-byte 'Intellimouse' data packets, even when the computer hasn't asked for them (yet). If I'm reading the documentation at (https://wiki.osdev.org/PS/2_Mouse) correctly, it seems like by default the mouse is supposed to report back type 0 'Standard PS/2 mouse' and send 3-byte data packets until a specific initialization sequence is requested to put the mouse into enhanced mode at which point it will report back type 3 'Mouse with scroll wheel' and send 4-byte data packets.