Add extended/raw keycode support

[pabru]

Hi,

I would like to somehow get raw keyboard access to handle non-ASCII keycodes, since the current code does ASCII translation if I'm reading it correctly (I'm still working on my C skills). The ideal API for my use case would allow getting the key up/down status of each individual key on the standard 10x-key QWERTY keyboard at the time of calling the function.

A suitable candidate for this appears to be int 16h, function 10h/11h - see the Keyboard BIOS Interface.

I could potentially hack up a solution on my own since LOVE appears to be quite a good match for my use case (cross-platform, high-res graphical UI, modern language + tooling, reasonable library support), but given my C skills, the end result might take a bit of cleaning up before I can submit a PR.

Do you think something like that could be added with reasonably little effort?

[rxi]

I'm not entirely sure I understand -- what is your intended use case?

[pabru]

My goal is to produce a clone of something like the Bloček text editor, except in Lua. I want to handle the keymap and display issues just like Bloček does, namely bypass DOS altogether and do all the key-mapping and text display by myself, in software.

I've spent ages trying to get DOS to be able to display/edit text in my language without using Bloček and I eventually managed to succeed. The problem is that it was an obscure process that required a few educated guesses, a lot of Googling and messing around with things like looking up the correct codepages (there was more than one for my language), keymap settings, VGA fonts and other such things. The end result is a bit fragile, and still results in files being saved under a codepage-based encoding instead of UTF-8.

Bloček is the closest thing to what I want to need, but:

1. It's missing a keymap for my language, and I haven't been able to figure out how to create a new one based on the existing keymaps bundled with the application.
2. I want to extend the editor so that it better supports the workflow that I want to achieve. I would need to do some rework for that anyway, so why not write everything in Lua?
3. It doesn't support TTF fonts (from what I gather), which is a bummer because I'd like to load TTF fonts directly without having to re-compile them into a program-specific format first. Lua does that with a couple of lines of code.
4. Pascal (which Bloček is written in) is a compiled language, and it would be cool if I could make ad-hoc tweaks to the source code (Lua, being a scripting language, would let you do that). That's not a must-have, but definitely a nice-to-have.

Given the above, raw keyboard access would let me do keyboard shortcuts (like CTRL+S to save, Alt+F4 to exit, etc. - with distinction between left and right modifier keys), as well as accented character entry / non-Western alphabets, without having to arm-wrestle DOS into co-operating. Even if the use of the raw keyboard API will require things like manually mapping (LShift|RShift)+8 → *, etc., it's still worth it IMHO.

[Vivix]

I think, as far as I can tell at least, lovedos already allows you to do these, but doesn't itself return the scancode to isDown(). You could use the table in the keyboard handler (which does bypass dos) as a reference, or make a quick edit to what is returned to isDown and see what happens, but it seems easier to just try with what is already here.

Try to avoid using bios interrupts unless you are in an enviornment without space for your own functions, these are relatively slow and clunky calls.

[pabru]

@Vivix Great point about avoiding BIOS interrupts. I haven't done any x86 low-level programming yet, so I didn't know whether they were performant or not. My use case doesn't need uber-low response time, but I recognise that some people may want that - and obviously the broader set of use cases supported, the better the code.

I'll try my hand at this stuff and see what happens. Based on a cursory (and possibly mistaken) skim-read of the source code, it appears to be using Scan Code Set 1. I will need to implement support for the 0xE0, 0xNN code sequences to support Alt-Gr, but that may be the case of modifying the loop slightly and adding an additional table to map the 0xE0 sequences (currently the code discards them, the 224 in line 172 is 0xE0 in hex).

I'll post here if I make any progress.