 Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me. |
Forum Index : Microcontroller and PC projects : USB Keyboard - slow response/dropped keypresses
  Page 4 of 4 |
|||||
| Author | Message | ||||
| matherp Guru  Joined: 11/12/2012 Location: United KingdomPosts: 10240 |
Can you download again please - I updated the download in the last few muinutes |
||||
| Amnesie Guru Joined: 30/06/2020 Location: GermanyPosts: 639 |
Of course, give me a second, I'll try it again with all keyboards!  |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2437 |
Peter, see: https://www.usb.org/sites/default/files/documents/hid1_11.pdf Universal Serial Bus (USB) Device Class Definition for Human Interface Devices (HID) Firmware Specification—6/27/01 page 62 (72/97 in PDF) reads: "The keyboard must report a phantom state indexing Usage(ErrorRollOver) in all array fields whenever the number of keys pressed exceeds the Report Count. The limit is six non-modifier keys when using the keyboard descriptor in Appendix B. Additionally, a keyboard may report the phantom condition when an invalid or unrecognizable combination of keys is pressed." page 74 (84/97 in PDF) reads: "- The Boot Keyboard shall report “Keyboard ErrorRollOver” in all array fields when the number of non-modifier keys pressed exceeds the Report Count. The limit is six non-modifier keys for a Boot Keyboard. - The Boot Keyboard shall report “Keyboard ErrorRollOver” in all array fields when combination of keys pressed cannot be accurately determined by the device, such as ghost key or rollover errors." the value for ErrorRollOver can be found in: https://www.usb.org/sites/default/files/documents/hut1_12v2.pdf Universal Serial Bus (USB) HID Usage Tables 10/28/2004 Version 1.12 on page 53 (53/168 in PDF), table 12: Table 12: Keyboard/Keypad Page Usage ID Usage ID Usage Name Position PC-AT Mac UNIX Boot (Dec) (Hex) 0 00 Reserved (no event indicated) N/A √ √ √ 84/101/104 1 01 Keyboard ErrorRollOver N/A √ √ √ 84/101/104 2 02 Keyboard POSTFail N/A √ √ √ 84/101/104 3 03 Keyboard ErrorUndefined N/A √ √ √ 84/101/104 4 04 Keyboard a and A 31 √ √ √ 84/101/104 5 05 Keyboard b and B 50 √ √ √ 84/101/104 6 06 Keyboard c and C 48 √ √ √ 84/101/104 [...] ie, 0x01 in each of the 6 array positions: "010101010101". hopefully this should help. cheers, rob :-) addendum: if my reading of the documentations is right, there is NO order to the 6 slots. it is up to the host to figure out the order of keypresses by comparing one report to the next. see page 72 from the first PDF: "The order of keycodes in array fields has no significance. Order determination is done by the host software comparing the contents of the previous report to the current report. If two or more keys are reported in one report, their order is indeterminate. Keyboards may buffer events that would have otherwise resulted in multiple event in a single report." Edited 2025-07-08 00:36 by robert.rozee |
||||
| Amnesie Guru Joined: 30/06/2020 Location: GermanyPosts: 639 |
Same problem, but to be sure I generated the MD5 checksum, so that you can compare the version: Md5 Checksum online tool: https://emn178.github.io/online-tools/md5_checksum.html It gives me "3971224a263653cd6881573a34df4d7a" for your file. Here sadly the same problems, new image:  |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10240 |
Please just run a single finger across vbnm as fast as possible - what happens? |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10240 |
This means if the first time two keys appear is in the same report there is no way the software can determine their order - what a crap I/F! |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2437 |
it is up to the host to poll the USB keyboard every 1ms and compare the previous report to the current one. from there the host builds up a map of what keys it believes are down and what are up. when the host sees the "010101010101" report it then (presumably) is expected to throw out the map it has previously built up and start afresh. cheers, rob :-) Edited 2025-07-08 00:53 by robert.rozee |
||||
| Amnesie Guru Joined: 30/06/2020 Location: GermanyPosts: 639 |
Ok done. With a single finger I wasn't able to produce any false chars or missing or swapped chars. Then I tried to write in my maximum speed in german and english (a bit slower), here I can't replicate any of the mentioned "problems". It only appears if there is rollover involved. And this (rollover?) problem with the group of "VBNM" starts really quickly, I must not type fast that the problem occurs. But what (for me counts) I wasn't able to re-create any of the mentioned problems with normal writing. Before your fixes, I wasn't able to write the word "save" for example. Now with an english text and some keywords I tested, the problem isn't re-producable under normal circumstances. So for me, as said a few post ago, absolutly usable now. Although the problems persist under the mentioned circumstances, I think we have to live with that - which is fine because: only a few people have those problems and as it is now with the fixes, it is even for me highly unlikely that I run into problems again. So I think further fixes will be just for sports (is it even called this way in english?)  Edited 2025-07-08 01:00 by Amnesie |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10240 |
That doesn't work because as we have proved in an earlier test version it creates duplicates as a key can appear both before and after the error code. Even with a 1mSec scan it is perfectly possible for two keys to be pressed and the order in the array ought to indicate their order but again, the evidence from the difference between Amnesie's keyboards and mine is that they seem to report in the opposite order. Currently it seems like the last version last night is the best with the only issue that after a 0x010101010101 Amnesie sees a swapped pair of characters. I don't. |
||||
| Amnesie Guru Joined: 30/06/2020 Location: GermanyPosts: 639 |
I have no clue about all of this, but I think the same. That is the best version. To sum up: - You fixed the missing chars (this was the worst problem!) - the dublicate chars (was a bad problem, too) Now there are still swapped chars and when typed really really fast with rollover there is a missing char again (latest firmware ONYL) So yes, last night version was the best, under normal circumstances I see no way of having any problems with it. Edited 2025-07-08 01:11 by Amnesie |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2437 |
if two keys are pressed down in the time interval between reports (ie, both within a 1ms period) then who is to say that one was pressed before the other? the clue is in the "H" of HID: human. a human can not determine the order of two events that occur within 1ms of each other, hence the time-ordering is irrelevant for any practical human-machine interface. cheers, rob :-) Edited 2025-07-08 01:11 by robert.rozee |
||||
| Amnesie Guru Joined: 30/06/2020 Location: GermanyPosts: 639 |
I have no clue about all of this, but I think the same (only from testing). This is the best version. To sum up: - You fixed the missing chars (this was the worst problem!) - the dublicate chars (was a bad problem, too) Now there are still swapped chars and when typed really really fast with rollover there is a missing char again (latest firmware ONYL) So yes, last night version was the best, under normal circumstances I see no way of having any problems with it. My whole summary is: PS/2 is such a great thing for it's simplicity .. but I understand, we can not live in the past forever Edited 2025-07-08 02:11 by Amnesie |
||||
swoodgate Newbie  Joined: 24/11/2011 Location: AustraliaPosts: 15 |
|
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4038 |
Link should probably be here John |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10240 |
Once more unto the breach, dear friends This is the Thursday lunchtime code with one tiny tweak. Assuming nothing untoward I intend to do a patch release of V6.00.02 with this change and a couple of other bugs fixes (PLAY SOUND n,R) PicoMiteRP2350VGAUSBV6.00.02.zip |
||||
| Amnesie Guru Joined: 30/06/2020 Location: GermanyPosts: 639 |
Tested all keyboards again, only when "typing" really fast (with rollover on the groups of four) I still get the described things like: VBNM: vbmn vbm vbm etc.. 4567: 4576 457 etc.. But as mentioned, I don't see a chance for normal (or even fastest) writing that those problems will ever come up. I wrote some english keywords and also some english text and german text as fast as I could; no problems. To summarize: Problems with certain (!) keyboards will persist, but fixed to a level, I don't see any chance to be problematic in real life. So thank you for fixing it to this point, so that this usb-firmware is usable for those who got those problems. I can imagine it was really hard, specially because not everyone can replicate it. Greetings Daniel Edited 2025-07-08 20:54 by Amnesie |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2437 |
hi Steve, the limitation in the case of modern/cheap keyboards is the hardware implementation of the key switch matrix. without a diode in series with every key switch, there will always be some combinations of simultaneously depressed keys within the matrix for which no more than 2-key rollover is possible. consider the simplified case of a 4-key keyboard, using NO diodes, and with the keys arranged in a 2x2 matrix: 2 rows by 2 columns. if attached to a microcontroller, said microcontroller can always determine the up/down status of all 4 keys when just ONE keys is held down. similarly, it can always determine the up/down status of all 4 keys when any two keys are held down at the same time. however, in the case of THREE keys being held down at once, no matter how the row and column wires are driven and read by the microcontroller, there is NO WAY for the microcontroller to determine which key is still up. nor can it distinguish between the case of THREE keys being depressed at once and the case of all FOUR keys being depressed at once. a typical PC keyboard has around 100 regular keys, arranged (electrically) as matrix of 10x10, or perhaps 13x8 or 12x9. without use of diodes, certainly there will be some cases where multiple simultaneous key-presses can be made sense of; for example if a group of keys sitting along a diagonal are simultaneously pressed then the state of each one can be determined without issue. BUT if any three keys that sit on the corners of a square within the matrix are simultaneously pressed, then we are back to the problem of a 2x2 keyboard - there is uncertainty about which ONE of the keys at the four corners of the square is up. the solution: add a diode in series with every key. THEN you are in a position where you can look at implementing NKRO across the interface to the host computer. but while 100 diodes are cheap, fitting them to a membrane keyboard is a mechanical nightmare. i hope this all makes sense? i really don't want to have to start drawing diagrams to further explain it. the situation is simple: without a diode in series with every key-switch in a matrix, there will ALWAYS be some combinations of 3 simultaneously pressed keys that are ambiguous to any attached microcontroller that is reading the matrix. cheers, rob :-) |
||||
Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 7865 |
This is where not all keyboards are the same. It's not always a regular matrix. e.g. A, S and D may be on the same row but different columns. By moving W onto the same row in hardware it becomes possible to differentiate between W and A or S very easily, with no chance of mistaking them. Better still is to move all four onto different X-Y positions on the matrix so that even with limited rollover it's still possible to catch them if typing at high speed. You can't assume that a keyboard has a regular matrix as the code you see at your microprocessor has been produced by the scanning processor, not the key switches unless you are using a very old system where the main CPU scans the keyboard itself.. Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2437 |
A. when i used the word "microprocessor" in my post, i was referring to the chunk of silicon sitting INSIDE the keyboard housing that is doing the matrix scanning and performing the USB device functions. B. it IS always a regular matrix, with the majority of junctions linked to a key switch. if too many junctions had no switch present, then the size of the matrix and hence number of pins required to scan the matrix would quickly grow. C. the designer will no doubt have attempted to arrange, as much as possible, for adjacent keys to not share the same row OR column in the matrix. but there are limitations to how far this can sensibly be taken, and there will STILL be certain combinations of keys that are both adjacent and end up sitting at the corners of a square. cheers, rob :-) |
||||
| Amnesie Guru Joined: 30/06/2020 Location: GermanyPosts: 639 |
I think the N-Key Rollover could be a potential issue with my keyboards, although the keyboards I am using (99% from the brand "Cherry") are high quality mechanical keyboards I've looked up the specifications: Cherry G80-1800 N-Key Rollover no Anti-Ghosting no Cherry G84-4100 (I have three of them) N-Key Rollover no Anti-Ghosting no And my cheap black USB only keyboard definitely hasn't these specification either. So for all my tests it is maybe from interest, I can now say I have not a single keyboard with N-Key Rollover or Anti-Ghosting. Greetings Daniel Edited 2025-07-09 00:50 by Amnesie |
||||
| Page 4 of 4 |
|||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |
