Re: Non-standard 8-bit fonts still in use

From: Philippe Verdy <verdy_p_at_wanadoo.fr>
Date: Sun, 8 May 2016 17:24:17 +0200

2016-05-08 16:19 GMT+02:00 Don Osborn <dzo_at_bisharat.net>:

> The flexibility of touchpad keyboards in theory gets beyond the
> limitations of the physical keyboards - has anyone tried adding a row to
> say a QWERY layout, which includes additional characters, rather than
> sweating the issues about shoehorning them in other levels or key
> sequences? Is that even possible? Still would be helpful to have standards,
> but where something is visible, it is easy to use.
>

It is technically possible, but the problem is to add distinctive hardware
"scan codes" to keys in this row.

See this table:
https://msdn.microsoft.com/en-us/library/aa299374(v=vs.60).aspx

You'll note that almost all scancodes in the 7-bit range are used. So you'd
need "extended scancodes", i.e. prefixing the special virtual scancode 00
on Windows (or the hardware scancode E0) before the extended scan code for
the actual key. (The special scancode "00" turns the 7-bit table into an
equivalent 8-bit table, but note that keyboards use 7-bit scancodes only,
as the 8th bit is used for the press/release flag)

For that, you could then reuse the scancodes of the first row (those for
digits). Note that the scancodes for the row of "standard" function keys
(F1..F12) is already extended this way (for additional function keys).

Bit note also this table:
https://www.win.tue.nl/~aeb/linux/kbd/scancodes-10.html

You'll see that the hardware scancodes E0-0A and E0-0B are already assigned
on PC for special functions, and so cannot be used to "extend" the keys for
digits 9 and 0 on the first row (whose scancodes are 0A and 0B
respectively). This is not so critical: you can perfectly have additional
keys assigend for a row using non-contiguous hardware scancodes (after all
the alphabetic part of the keyboard is already using multiple ranges of
hardware and virtual scancodes).

But you'd need a new keyboard driver (and an extension to MSKLC on Windows)
to allow mapping this supplementary row, and a industry agreement to assign
new extended keys in non-conflicting ways (these days, it is the Microsoft
hardware labs that centralize the extensions used on PC-compatible
hardware, Apple used to have its own registry for its own keyboards, but
now Macs are PC and can use the same keyboards not necessarily built by
Apple, e.g. by Logitech). The connectors are compatible with the same USB
interface.

There are some differences in hardware scancodes used on the USB interface
(Windows internally translated hardware scancodes for some interfaces into
the same virtual scancodes before sending them to upper keyboard drivers
and applications: this is where scancode E0 on the old PC-keyboard
interface or the newer PS/2 interface or USB interface, or in the old BIOS
interface is remapped into the same virtual scancode 00 for Windows drivers
and apps).

There's also an additional hardware extension code E1 for a few function
keys (it is used for a few functions encoded on 3 bytes, for upward
compatibility reasons, such as the "Pause" key).

Various other vendors have used specific hardware scancodes, but today
almost everyone agrees to the same PC standard.
Received on Sun May 08 2016 - 10:25:11 CDT

This archive was generated by hypermail 2.2.0 : Sun May 08 2016 - 10:25:11 CDT