Hi Bret, >> I disagree here. You would only need reentrant handling if it could >> happen that int 15.4f is called while int 15.4f already is busy. >> This is unlikely for two reasons ... > > Agreed: Unlikely, but absolutely not impossible. > Drivers should be designed to handle even unlikely events without crashing
Returning "ignore this scancode" or returning the scancode untranslated would not crash anything, at most drop a key. >> To create fake keystrokes, use int 16.5, again avoiding direct I/O >> manipulation and staying on the 40:xx keyboard buffer level. > > There are a couple of problems with that approach. The first is that > not all keys on the keyboard end up in the BDA/keyboard buffer (Pause, > PrintScreen, SysReq, Left/Right Windows/GUI, Power/Sleep/Wakeup, multimedia > keys, etc.). If these keys are to be simulated, it must happen at the As far as I remember, power keys could be handled by the BIOS int 9, pause, printscreen and sysreq manipulate 40:xx and call user int/... handlers in well defined ways and windows / multimedia keys could just be stored in 40:xx as normal ASCII 0, scancode X function keys. >scancode level, not the BDA level. The 2nd problem is that some programs > provide their own INT 9 handler, and don't even use the BDA at all. > For these kinds of programs, the simulation must also happen at the scancode level. >From what I remember, such programs would not implement anything beyond int 9 itself and int 9 would not do anything apart from directly talking to 8042 and putting data in their app specific buffers, so they would ignore int 15.4f and int 16 and any other keyboard support BIOS or driver modules. In short, they would not care about simulated keypresses unless you virtualize 8042 which is probably why BIOS USB PS/2 simulation tends to do that. Of course writing to 40:xx (after asking 15.4f) would be cleaner and easier, but as noted, MS KEYB does not follow standards here. Eric ------------------------------------------------------------------------------ All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 _______________________________________________ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
