BTW I've fully merged the XT keyboard support. Now when you press the button the LED will cycle between three modes - AT/PS2 (blue), XT (green), AMSTRAD (red, not implemented yet).
rasteri wrote on 2024-04-26, 18:07:No idea I'm afraid. There's so much different in your setup from mine (different board, mice, keyboard, PC, port pins, etc) that any one of them could be causing the problem.
Maybe grab one of those cheapo logic analyzers, then you can investigate further?
I think I've managed to fix this problem (without logic analyzer but I think I will order one nevertheless). Noticed that (wireless) mouse works more often if it's not powered on at boot and then proceeded to find out that if I move mouse on boot it will never work. Studied PS/2 protocol a bit and noticed that data reporting should be disabled by default and only enabled after Enable Data Reporting command. So implemented support for Enable / Disable Data Reporting and now mouse works on every boot. I guess PS/2 controller got upset when it received data when it did not expect it.
Hardware-wise found out that my GPIO re-mappings did not work very well and only mouse aux pins did work . I am no C nor embedded systems developer so no idea why is that but I will just desolder resistor from P4.3 and then this dev board should work with stock firmware...
jarp wrote on 2024-04-28, 20:36:I think I've managed to fix this problem (without logic analyzer but I think I will order one nevertheless). Noticed that (wireless) mouse works more often if it's not powered on at boot and then proceeded to find out that if I move mouse on boot it will never work. Studied PS/2 protocol a bit and noticed that data reporting should be disabled by default and only enabled after Enable Data Reporting command. So implemented support for Enable / Disable Data Reporting and now mouse works on every boot. I guess PS/2 controller got upset when it received data when it did not expect it.
Interesting - I didn't implement that command because I was just like.... just don't move the mouse while it's booting, heh. But maybe your wireless mouse sends movement commands during poweron or something.
Feel free to submit a pull request with the command implemented 😀 (or just post the file you updated here if you can't be bothered)
rasteri wrote on 2024-04-29, 11:20:Interesting - I didn't implement that command because I was just like.... just don't move the mouse while it's booting, heh. But maybe your wireless mouse sends movement commands during poweron or something.
Feel free to submit a pull request with the command implemented 😀 (or just post the file you updated here if you can't be bothered)
Heh, and I have developed a habit of always shaking the mouse on boot 😀 I believe it is because wireless mouse needs some movement to wake it up so I tend to wake it up on boot. But also non-modified firmware failed to boot with mouse quite often even if mouse was not touched so I guess indeed mouse sends unexpected updates or something.
Pull request created, please check feasibility of it, I had troubles understanding code architecture at first as I am no embedded systems programmer...
jarp wrote on 2024-04-29, 18:47:Pull request created, please check feasibility of it, I had troubles understanding code architecture at first as I am no embedded systems programmer...
Tested it on a bunch of PCs and it works great, thanks for your contribution!
Does anybody know if anything out there uses ps/2 mouse native scale 2:1 mode or is acceleration always done on driver level? I did not even find DOS mouse driver which would allow to even to enable it. Out of curiousity and for excercise I added support for scaling as well, but not sure if it would have any practical use...
Ps/2 remote mode would be another one, is it used in real life? Or wrap mode by any diagnostocs software or anything?
Edit: Ok, decided to learn some x86 asm and wrote utility which can set scaling, resolution and polling of PS/2 mouse. Will try to implement support for them (short of rate i think...) and intellimouse support. Not sure if @rasteri welcomes such modifications but it is ok if not, just wanting to learn some DOS and embedded stuff.
jarp wrote on 2024-05-01, 20:38:Will try to implement support for them (short of rate i think...) and intellimouse support.
I'm not sure which programs set scaling. Maybe some versions of windows. But yeah feel free to implement.
Have you started on Intellimouse? I was about to start implementing it myself never mind, I saw your comments on the issue
It's been a while since I played around with the HIDman, but I'd like to give it another go in my upcoming third version of the TinyLlama SBC.
Couple of questions:
1. Did you manage to make any progress with USB hubs?
2. Looking at the PS/2 version of the schematics, I see you've connected both pins 2 and 8 (6) for both PS/2 connectors - is that for enabling both keyboard and mouse data+clk over a single cable? Does this mean several of the pins from the CH559 are actually outputting the same signals?
Eivind wrote on 2024-05-10, 10:35:1. Did you manage to make any progress with USB hubs?
Yeah most USB hubs now work, but I still have one stubborn one that doesn't. Even the CH559 example library doesn't work with it, but it works in Windows and Linux so it isn't just broken.
I have access to a fancy logic analyzer so I'm going to look at the raw USB packets to figure out why. It's my top priority currently (I'm having a batch of HIDmen manufactured so I need to get to the bottom of this one way or another!)
2. Looking at the PS/2 version of the schematics, I see you've connected both pins 2 and 8 (6) for both PS/2 connectors - is that for enabling both keyboard and mouse data+clk over a single cable? Does this mean several of the pins from the CH559 are actually outputting the same signals?
Yes exactly - the AXP version has the same feature too. The advantages of this are twofold the way I see it - firstly it's useful for devices that have combined keyboard/mouse over a single PS/2 port (many laptops and industrial computers for example). Secondly it allows the use of a splitter cable to keep cables neater.
rasteri wrote on 2024-05-10, 19:25:Yeah most USB hubs now work, but I still have one stubborn one that doesn't. Even the CH559 example library doesn't work with it […]
Eivind wrote on 2024-05-10, 10:35:1. Did you manage to make any progress with USB hubs?
Yeah most USB hubs now work, but I still have one stubborn one that doesn't. Even the CH559 example library doesn't work with it, but it works in Windows and Linux so it isn't just broken.
I have access to a fancy logic analyzer so I'm going to look at the raw USB packets to figure out why. It's my top priority currently (I'm having a batch of HIDmen manufactured so I need to get to the bottom of this one way or another!)
2. Looking at the PS/2 version of the schematics, I see you've connected both pins 2 and 8 (6) for both PS/2 connectors - is that for enabling both keyboard and mouse data+clk over a single cable? Does this mean several of the pins from the CH559 are actually outputting the same signals?
Yes exactly - the AXP version has the same feature too. The advantages of this are twofold the way I see it - firstly it's useful for devices that have combined keyboard/mouse over a single PS/2 port (many laptops and industrial computers for example). Secondly it allows the use of a splitter cable to keep cables neater.
Sounds great! Love that you're still invested in this project and I look forward to using it (again)!
OT: Had to chuckle when I read "HIDmen"... 🤭
I'm also really happy to see the recent commits to the git and to see the project still being worked on!
sofakng wrote on 2024-05-10, 19:33:I'm also really happy to see the recent commits to the git and to see the project still being worked on!
Yeah thanks to jarp we have 5 button Intellimouse support! Also there's been a few other improvements (XT support being the main one I suppose)
So I've done some more testing on various hubs and come to some findings.
The problem only seems to appear when the following setup is used :
USB1.1 low speed device ---> USB 2.0 hub --->USB1.1 Host (i.e. hidman or PC)
Interestingly the same hubs that fail on the hidman also fail when connecting to an old PC that only has USB1.1 ports. So I think the problem may be with the crappy cheapo hubs I'm using rather than anything hidman is doing.
Eivind wrote on 2024-05-10, 10:35:1. Did you manage to make any progress with USB hubs?
I'd be interested to see if the same setup works on your RP2040 USB implementation. Got any cheapo USB2.0 hubs and low-speed USB HID devices?
rasteri wrote on Yesterday, 14:47:So I've done some more testing on various hubs and come to some findings. […]
So I've done some more testing on various hubs and come to some findings.
The problem only seems to appear when the following setup is used :
USB1.1 low speed device ---> USB 2.0 hub --->USB1.1 Host (i.e. hidman or PC)
Interestingly the same hubs that fail on the hidman also fail when connecting to an old PC that only has USB1.1 ports. So I think the problem may be with the crappy cheapo hubs I'm using rather than anything hidman is doing.
Eivind wrote on 2024-05-10, 10:35:1. Did you manage to make any progress with USB hubs?
I'd be interested to see if the same setup works on your RP2040 USB implementation. Got any cheapo USB2.0 hubs and low-speed USB HID devices?
Haven't done extensive testing or anything, but what I have here right in front of me is an HHKB Pro 2 keyboard (which I love using) - it has an internal USB 2.0 hub and does not work with the HIDman but does work using the TinyUSB stack on the rp2040. Happy to run some test and send you debug info if that helps?
Eivind wrote on Yesterday, 15:43:Haven't done extensive testing or anything, but what I have here right in front of me is an HHKB Pro 2 keyboard (which I love using) - it has an internal USB 2.0 hub and does not work with the HIDman but does work using the TinyUSB stack on the rp2040. Happy to run some test and send you debug info if that helps?
Actually, a better test would be to see if your USB2.0 hub/keyboard works on the latest hidman code. I have some USB2.0 hubs that work just fine, and yours probably is one of those.
(EDIT - note that you'll have to have all devices plugged into the hub when you connect it to hidman, the code doesn't automatically detect USB device attaches/detaches on hub ports, but I'm working on that as we speak)
TBH if my USB hubs won't work under Windows or Linux on then I doubt very much I can make them work on the hidman. I also suspect they won't work on the RP2040 either, unless tinyUSB does some magic to fix faulty USB hubs. I'll get a Pi pico and test it though.
rasteri wrote on Yesterday, 16:11:Actually, a better test would be to see if your USB2.0 hub/keyboard works on the latest hidman code. I have some USB2.0 hubs that work just fine, and yours probably is one of those.
(EDIT - note that you'll have to have all devices plugged into the hub when you connect it to hidman, the code doesn't automatically detect USB device attaches/detaches on hub ports, but I'm working on that as we speak)
TBH if my USB hubs won't work under Windows or Linux on then I doubt very much I can make them work on the hidman. I also suspect they won't work on the RP2040 either, unless tinyUSB does some magic to fix faulty USB hubs. I'll get a Pi pico and test it though.
You mean the code that's currently on main? I believe I already tried, and it didn't work. But I'll do another test, just to be sure. Also, the actual keyboard device is always plugged into the hub, as it's internal and unaccessible unless you open it up and start performing electronic surgery... 😀
Eivind wrote on Yesterday, 16:19:You mean the code that's currently on main? I believe I already tried, and it didn't work. But I'll do another test, just to be sure.
Thanks, yeah current main code theoretically supports most USB hubs. make sure it works on directly-connected mice/keyboards first, possibly the code broke compatibility with the tinyllama board somehow.
My guess is that your USB keyboard runs in full-speed mode so it should theoretically work with hidman. If it works on RP2040 but not on hidman then there's presumably another bug somewhere, or tinyUSB is magic.
I've ordered a pi pico board, I'll see if I get the same results on my weird hubs as I do on the hidman.
rasteri wrote on Yesterday, 16:44:Thanks, yeah current main code theoretically supports most USB hubs. make sure it works on directly-connected mice/keyboards fir […]
Eivind wrote on Yesterday, 16:19:You mean the code that's currently on main? I believe I already tried, and it didn't work. But I'll do another test, just to be sure.
Thanks, yeah current main code theoretically supports most USB hubs. make sure it works on directly-connected mice/keyboards first, possibly the code broke compatibility with the tinyllama board somehow.
My guess is that your USB keyboard runs in full-speed mode so it should theoretically work with hidman. If it works on RP2040 but not on hidman then there's presumably another bug somewhere, or tinyUSB is magic.
I've ordered a pi pico board, I'll see if I get the same results on my weird hubs as I do on the hidman.
Compiled the fw currently on main, flashed it and tested. The HHKB still doesn't work, but another USB keyboard I have does. Same as earlier, in other words.
I did an lsusb -v on the HHKB on my mac, and it shows a NEC 2.0 hub and the keyboard itself is a 1.1 device from Topre. This seems to match what you wrote about connecting a 1.1 device -> 2.0 hub -> HIDman.
One thing though - isn't the CH559 capable of 2.0 speeds? Just wondering, since you said "USB1.1 Host (i.e. hidman or PC)"...?
EDIT: Btw, I had the fw configured as BOARD_AXP, since the PS/2 signals on the TinyLlama are hooked up like this: KBDATA: 0.3, KBCLK: 0.5, MSCLK: 3.7, MSDATA: 4.3. I assumed that was what made the most sense.
Eivind wrote on Yesterday, 17:47:I did an lsusb -v on the HHKB on my mac, and it shows a NEC 2.0 hub and the keyboard itself is a 1.1 device from Topre. This seems to match what you wrote about connecting a 1.1 device -> 2.0 hub -> HIDman.
USB 1.1 devices can run in Low Speed (1.5Mb/s) or Full Speed (12Mb/s). USB2 devices have those modes too, but can also run in High Speed (480Mb/s). I would be interested to see if your keyboard is Low Speed or Full Speed.
So far I've only had problems when running Low Speed devices on High Speed hubs, then connecting the hub to a Full Speed host.
One thing though - isn't the CH559 capable of 2.0 speeds? Just wondering, since you said "USB1.1 Host (i.e. hidman or PC)"...?
Yes this is where using the 1.1/2.0 scheme gets confusing. Electrically-speaking the CH559 is USB2.0 compliant, but only does Low/Full speed so it's kind of a moot point. I perhaps shouldn't have called it a USB1.1 device, but it gets the point across that it only does Low/Full speed.
The Pico-PIO-USB also only seems to support Low and Full speed devices so if the issue with your keyboard/hub is the same as the one I'm seeing here then your keyboard shouldn't work on an RP2040 either.
Do you have access to UART0 on your CH559? If you change the 0 to a 1 in line 5 of trace.h and recompile you get debug output at 115200kbps. If not I'll modify the menu system to include a lower-level USB logger output to the keyboard port.
(EDIT : my guess at this current time is that there's something else about your keyboard that's causing it to fail on CH559 but not RP2040, like a super complicated report descriptor.... or maybe tiny USB is really magic)
rasteri wrote on Yesterday, 19:11:USB 1.1 devices can run in Low Speed (1.5Mb/s) or Full Speed (12Mb/s). USB2 devices have those modes too, but can also run in High Speed (480Mb/s). I would be interested to see if your keyboard is Low Speed or Full Speed.
The keyboard reports being capable of FS, according to the screenshot below. Not sure if this means it's currently running at that speed though, macOS USB reporting is a bit simplified I think. I can try hooking it up to a linux machine later if that helps.
rasteri wrote on Yesterday, 19:11:Do you have access to UART0 on your CH559? If you change the 0 to a 1 in line 5 of trace.h and recompile you get debug output at 115200kbps. If not I'll modify the menu system to include a lower-level USB logger output to the keyboard port.
(EDIT : my guess at this current time is that there's something else about your keyboard that's causing it to fail on CH559 but not RP2040, like a super complicated report descriptor.... or maybe tiny USB is really magic)
I don't have the two UART0 pins connected to anything on the TL 2.1 (pins 7 and 4, right?). I could always solder on something if needed, but if it's relatively simple for you to make a fw version that spits out relevant info on the PS/2 keyb lines, that would be easier for me! 😜
EDIT: Oh, and I know for a fact that this keyboard worked using my rp2040 solution on the ITX board, but I can't remember if it worked both on the native USB host and through the PIO-backed host, or just the former. Don't have any of the ITX boards up and running at the moment, but I can dig one out if we need to get to the bottom of that particular question.
