>> how should a KEYB scancode->keycode driver react to copdepage
>> changes, and how are these communictated?
> Well, first of all the keyboard driver should detect the current
> Code Page on installation and not just assume one.
codepage is a display thing, essentially it's the table how to convert
8-bit bytes into a visable character set, and mostly unrelated to the
way the keyboard driver converts scancodes into bytes.
with an US keyboard driver,
pressing the '7' key (scancode 0x08) results in '7'.
pressing the '7' key while holding SHIFT results in '&'.
pressing the '7' key while holding AltGr results in nothing.
with an GR keyboard driver,
pressing the '7' key (scancode 0x08) results in '7'.
pressing the '7' key while holding SHIFT results in '/'.
pressing the '7' key while holding AltGr results in '{'.
> And, the KEYB
> program should work with multiple code pages when it can.
they all do. they always produce the same byte values öäüÖÄÜ whatever
the codepage.
of course a brasilian KEYB might produce different values for á then a
french KEYB (I don't know), but they still produce the same value
consistently.
> DISPLAY.SYS calls INT 2F.AD81h when the Code Page is changed to
> inform KEYB so it can change its mapping.
please provide an example where this is necessary AND plausible.
> Unless the tables are in a "public" format, the data contained in
> the tables is irrelevant.
> The reason that other TSR's (at least mine) may need to know what
> the keyboard mapping looks like is because they need to do an
> "ASCII-to-Scancode" lookup.
nope. you intend to do "ASCII-to-Scancode" lookup, then feed these
scancode to the KEYB program, in the hope that this KEYB program
converts it back to the same ASCII character that you started with.
there's a BIOS call for this:
KEYBOARD - STORE KEYSTROKE IN KEYBOARD BUFFER (AT/PS w enh keybd only)
AH = 05h
CH = BIOS scan code
CL = ASCII character
use '2' as scancode. compatible with 99,95% of al existing
applications.
otherwise you have to implement what the KEYB program does in reverse
direction. not only different scancodes with different shift states,
but also dead keys: á is produced by hitting ´, then a; à is produces
by holding SHIFT, hitting `, hitting a, releasing SHIFT.
for the german keyboard at least ;)
or
AH = 05h
CH = 02h
CL = à
int 0x16
> My SCANCODE program, e.g., "types" scancodes automatically (it is
> useful for creating "macros"), but the user can tell SCANCODE what
> to "type" with ASCII codes. To do this, SCANCODE needs to know what
> scancode(s) to type (what physical key(s) on the keyboard to press)
> to generate the ASCII code the user wants to see. For example, if
> you tell SCANCODE to type a "Z" it will press the shift-key, press
> the "z", release the "z", then release the shift-key. But, it needs
> to know where the Z key is on the keyboard to do that, and the Z key
> is in different places (different scancodes) depending on the
> keyboard layout and, in some cases, the code page.
yes that's complicated. how about sending 'Z' to the program?
> Another kind of TSR that needs to know is a TSR that has some sort
> of "hot-key" to enter into the TSR as it is running to make
> configuration changes. My CLOCK and SERIAL programs do this. TSR's
> usually (though not always) monitor scan codes for hot-keys rather
> than ASCII codes, but the user usually enters the hot-key as an
> ASCII code. The current versions of CLOCK and SERIAL simply assume
> the keyboard is a standard US QWERTY layout, but I'm in process of
> changing them to be "keyboard-layout aware").
there are enough 'non-controversial' keys to use for hotkey; just use
B-X and avoid Q.
Tom
_______________________________________________
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user
