Closed MJoergen closed 3 years ago
Actually, it turns out the monitor intercepts the up and down arrow keys to move the screen buffer.
Indeed: In a "textmode application" this existing behaviour (intercepting up/down and also pageup/pagedn) for the scrolling of the terminal window makes a lot of sense. (**)
But in a game for example it does not. This is why for example in Q-TRIS I directly accessed the registers using MMIO to query for the USB keyboard's keys instead of using getc
.
There are a bunch of solutions thinkable. IMHO the best one would be:
Treat getc
as a function for "textmode apps only" (because as said: there the behaviour makes sense) and have a second function like readkbd
that is more on the level of raw keyboard reading and which might be related to issue #142 (Feature request: Add ability to poll current keyboard status).
@MJoergen What are your thoughts?
EDIT: about (**): It not only intercepts up/down for the scrolling but also pageup/pagedn AND POS1 (HOME) and END
I like your idea.
How about going one step further and ONLY use Issue #142? I mean, once we have a solution to poll the current keyboard status, I see no reason to have a very similar function readkbd
, unless all that function does is to read the HW register IO$KBD_RT
and return the value.
Agreed. I suggest to CLOSE this one as a duplicate of #142.
When calling the monitor function
qmon_getc
, the left and right arrow keys correctly generate the return values 0x1200 and 0x1300, respectively. However, the up and down arrow keys are in-effective; theqmon_getc
function does not return when pressing these keys.I'm using an ASUS KU-0902 keyboard.