You can do "something" with FD-KEYB, but not easy.
First of all, you have to find the KeybCB (KEYB Control Block) which is
currently in use.
That's the tricky part, you have to find out in the memory data blocks
associated to KEYB.
Then, you can walk through the KeybCB structure:
---Header---
000 BYTE Number of submappings (n+1) described in the block
General submapping is counted, and is usually numbered as 0.
001 BYTE Number of additional planes (m) that are globally defined for
the whole keyb control block. The total number of planes is
m+2 (there are two implicit ones, see TABLE 3)
The maximum number of planes is 10 (that is, m=8)
002 BYTE Character to be used as decimal separator character by
the driver when using this layout.
0 when the default character (usually .) should be used.
003 BYTE Current particular submapping in use (1 to n)
004 WORD MCB-ID of the KeybCB, only if the KeybCB resides in a MCB
that must be deallocated if the KeybCB will no longer be
used.
006 DWORD PTR=> Next KeybCB
KeybCBs may be organized in a linked list, if the keyboard
driver supports more than one.
Set to 00:00 if there are no more KeybCBs.
010 WORD ID Word of the current KeybCB (see ofs 012)
012 8 BYTES 0-padded string of the name with which the KeybCB has been
loaded. It is usually a two-letter identifier, such as UK,
GR or SP.
KeybCBs are usually loaded as single "keyboard layouts"
identified by a short string and an identifier word in case
there are several models appliable to the same string ID.
(for the identifier word, see ofs 010)
Aitor
On Thu, 7 Oct 2021 at 00:20, Bret Johnson <bretj...@juno.com> wrote:
> > 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. And, the KEYB program should work
> with multiple code pages when it can. If DISPLAY.SYS is installed, you can
> use INT 2F.AD00 and INT 2F.AD02 to detect the current Code Page. If
> DISPLAY.SYS is not installed, you can use INT 21.6601. If neither of these
> work, you should assume code page 437 (which is the default on most
> systems).
>
> DISPLAY.SYS calls INT 2F.AD81h when the Code Page is changed to inform
> KEYB so it can change its mapping.
>
> > why would any other TSR need insight into KEYB installed/not
> > installed state or a pointer to private tables?
>
> Unless the tables are in a "public" format, the data contained in the
> tables is irrelevant. E.g., MS KEYB and FreeDOS KEYB tables do not use the
> same format. I'm not sure about any of the other DOS's out there, but
> wouldn't necessarily expect them to be the same as MS.
>
> 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. That is, the program allows the user to
> provide an ASCII code as an input parameter (since ASCII is far easier for
> the user to enter than a scancode), but the program itself uses the
> scancode.
>
> 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. So, it has
> internal tables of a bunch of different keyboard layouts so it knows how to
> "type" the different ASCII characters. It would be nice if SCANCODE could
> somehow "ask" the KEYB program what its tables look like, but that's not
> really feasible. I realize you may think "typing" scancodes may be a
> "silly" thing to do, but there are cases where it works and ASCII codes do
> not (e.g., SCANCODE is able to "type" into older DOS-based versions of
> Windows, and can actually "type" things like PrintScreen or Pause or the
> multimedia keys or the Sleep/WakeUp/ShutDown keys that some keyboards have).
>
> 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"). To do
> this, they need to know the current keyboard layout so they can do the
> "ASCII-to-Scancode" lookup using the internal tables. If the KEYB program
> doesn't identify itself using INT 2F.AD80, the TSR's don't know what the
> current keyboard layout is, and the user will get frustrated because the
> keys they are supposed to press on the keyboard are in the wrong places.
>
> What this boils down to is making it easier on the user, trying to make
> things as "automatic" as possible, even though it can make it MUCH harder
> on the programmer.
>
> BTW, this brings up another issue I've been trying to figure out regarding
> keyboard layouts. There are two different parts to the keyboard layout
> identification -- there is a two-letter code (for example, US = United
> States), but most keyboards also have a code number to go along with that
> (for the US keyboard, it is 103). But there are also cases where the there
> is more than one keyboard layout for the same two-letter code. An example
> of this is Bulgaria (BG) which has three different layouts with three
> different numbers (103, 241, & 442) even though they are all "BG".
> Unfortunately, the standard KEYB interface (which MKEYB doesn't use) only
> tells you the "BG" part and doesn't tell you the number part.
>
> Does anybody know of a way to automatically/programmatically determine the
> number part of the keyboard ID from KEYB?
>
>
> _______________________________________________
> Freedos-user mailing list
> Freedos-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-user
>
_______________________________________________
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user
