Yes, if you read the Output buffer three times for a three byte scan code, you might get all three bytes, but the PS2 will still fire two more times, even though you already read those bytes.Only read one byte per IRQ.
#Vmware enhanced keyboard driver forums code#
Just because the IRQ fired, doesn't mean you can read a whole scan code from the Output Buffer. One other error that gets a lot of new-comers is that you only get one byte per IRQ.
#Vmware enhanced keyboard driver forums driver#
Your OS or driver should read from the Output Buffer and write to the Input Buffer. The Input Buffer is the (one byte) buffer it receives bytes from. The Output Buffer is the buffer the hardware is sending bytes to, i.e.: outputting to a buffer. Note: The PS2 uses the names from the hardware point of view. Therefore you must make sure and know which irq is reading from the buffer (I/O port). The way to know if the byte in the PS2's Output Buffer is from the keyboard or the mouse is simply because the keyboard and mouse each fire a different IRQ, though *both* use the same Output Buffer. Feel free to swap the "head" and "tail" keywords.Īnyway, that is all that should be in your IRQ. I am looking to run VMWare Workstation or Player, as I have both, on my SP3 running Windows 10. It all depends on how you look at it, from the IRQ point of view or the kernel thread (task) point of view. Vmware Enhanced Keyboard Driver Download Mac I posted this in another thread and asked a few of you but really haven't gotten or been able to find a definitive answer. i.e.: the tail is that more recent byte read and the head is the byte that should be used first by the kernel. Note: some think the head and tail should be swapped. ( i.e.: don't want the head to write on the tail ) ( NEXT retrieves the next position in the circular buffer ) This way the IRQ does so little that it uses only 10 to 30 cycles of the CPU (not counting time to acknowledge interrupt), and all of the work is done in the a kernel thread, where preemptive thread (task) switching is okay and does not hurt performance any. Then, I have a thread (or task) that monitors this buffer and when enough bytes are found to create a scan code, it retrieves them, creates the scan code, and adds it to the scan code buffer (where ironically, another thread (or task) monitors it). Very little to anything else should be done inside the IRQ. You need to rethink your design.In my book, Input and Output Devices, I show that your PS2 IRQ should simply retrieve the byte from the Output Register and store it in a buffer, acknowledge the interrupt, *and* (interrupt) return.
Basically it just needs to insert raw keycodes into a queue. The interrupt part of a keyboard driver should be very small. Well yes, my IRQ is insanely big, but i'll try to reduce it's size and optimize it.Īny ideas to somehow speed up keyboard lag without optimizing my IRQ?
0 kommentar(er)
