Feature #7784

Updated by Toomas Soome over 1 year ago

The current console input is only supporting iso8859-1, would need more wider support.

The current keyboard driver is built on keymaps based on 8-bit character encodings and specifically using 8859-1 table (in some cases only ascii set).

To provide better support for input, we could either allow other 8-bit tables, or build the input around unicode and pass the chars to upper layers in utf-8 encoding.

8-bit tables is no go because the world is moving to unicode already. Therefore we build the keymaps to support unicode chars, the initial take is to rewrite the existing maps to use the same chars but in unicode encoding (this is because right now our console only can display 8859-1); the keyboard internal structures are redesigned to use 32-bit chars and the unicode chars are translated to utf-8 sequence when data is leaving the keyboard driver.

This approach will need 7796 ( to actually have this data stream properly working through ldterm module.

To display the data, tem already is processing the utf-8 byte sequences to reconstruct unicode chars and does handle the unprintable ones. In followup work we will update tem to provide full support for unicode chars (not just latin1 set), and add font subsystem to create bitmaps and low level screen handling to draw the bitmaps.

This approach by itself is nothing new or unseen, the same idea is implemented in FreeBSD keyboard maps and keyboard driver (and probably elsewhere too).

The actual implementation is already done in and the test iso and usb images are currently available at