Back to home page

DOS ain't dead

Forum index page

Log in | Register

Search:  
Back to the forum
Board view  Mix view

In reply to : Bret 'll have to hate FreeDOS mKEYB, too (Developers)

posted by bretjohn Homepage E-mail, Rio Rancho, NM, 18.05.2011, 02:09

> in our case (we are a keyboard driver) the scancode (most likely) comes
> from the keyboard.
Again, that is the point. MS (via their code) says INT 15.4F can come from anywhere, not just from the INT 09 handler.

> even if 'something' is simulating a keyboard by sending scancodes into
> the system by callimg int15.4f, usually the intension is to enter
> characters into the keyboard buffer.
Perhaps usually, but not always. It is also true that the only programs I know of that use INT 15.4F are the SMARTDRV-compatible caches, and the only scancode that is used for this is Ctl-Alt-Del. But that doesn't mean there aren't other programs or other scancodes that do the same thing.

> if this something is sending CtrlAltDel scancodes, it's either an
> annoyance or a remote control program - the system will boot anyway.
Most likely, but not necessarily. It is at least theoretically possible to flush the SMARTDRV caches with INT 15.4F even if you don't intend to reboot. In reality, though, nobody would ever do this -- they would just use the SMARTDRV INT 2F interface instead. BTW, this is yet another justification to assume MS & IBM intended INT 15.4F to be called from anywhere -- the example reboot code from MS could have used INT 2F instead of INT 15, but it didn't.

> I m not sure, but I guess that sending the scancodes using int15.4f should
> just work.
No, because INT 15.4F handlers don't necessarily handle all scan codes. Your program, MKEYB, for instance, does not. It passes the ones it doesn't care about back to the INT 09 handler. And again, I want to reiterate that I don't think INT 15.4F handlers should actually "handle" any scancodes at all.

> I haven't looked at your code, but they should probably send scancodes
> using int15.4f. (even better would be to use SMM and simulate a real PS/2
> keyboard, but this is beyond the current scope). your driver should
> handle the keyboard, and let the scancode->key translation to the keyboard
> driver.
That's basically what it does, but doesn't use SMM. SMM is really, really ugly, and doesn't even exist on older computers.

> is there any way to determine the keyboard layout?
Two different notions here: keyboard language and keyboard layout. The only way I know of to determine the keyboard language is with INT 2F.AD80h. ALL KEYBOARD RE-MAPPING UTILITIES SHOULD SUPPORT THIS FUNCTION, whether they use INT 09 or INT 15.4F. AFAIK, none of the INT 15.4F programs do. They don't need to support it fully, but they at least need to provide the two-letter language abbreviation. This is the only way other programs can know what the current language is.

Determining the keyboard layout, if it is other than the default, can only be done using INT 15.4F, and hoping it doesn't actually process the scancodes. Actually, for my purposes, merely supporting INT 2F.AD80 with a two-letter language ID is enough.

If you add support for INT 2F.AD80 to your program, which I would STRONGLY encourage everyone to do, you really should change it to a "proper" INT 09 interface instead of an INT 15.4F interface at the same time. The only difference between an INT 15.4F interface and an INT 09 interface is the entry/exit "wrapper", which is pretty insignificant.

> I doubt that. int16.5 was exactly created to enter keys into the keyboard
> buffer; no reason not to use it.
Different concepts. INT 09 (IRQ / scancodes / keyboard language), INT 15.4F (keyboard layout), INT 16.5 (ASCII codes). You can call INT 16.5 just as easily from INT 09 as you can from INT 15.4F.

Post reply
 

Complete thread:

Back to the forum
Board view  Mix view
22049 Postings in 2034 Threads, 396 registered users, 257 users online (1 registered, 256 guests)
DOS ain't dead | Admin contact
RSS Feed
powered by my little forum