Hi, I've done a few more tests. If I assign single characters to ku/kd/kr/kl, like "ku=A", it works as expected (when I press A I get a KEY_UP event). It's just multi-character strings that fail. However, I have noticed that if I make it "ku=AA" it will hang slightly after I press the first A (and then I just receive an A key press event instead of KEY_UP because it hasn't seen a second A). So I think that there may be some issue with some wait loop in ncurses...
Antonio On Saturday, July 4th, 2026 at 11:39 AM, Antonio Niño Díaz <[email protected]> wrote: > Hi! > > I've got this almost working, all I need to do right now is to inject special > key presses into the stdin buffer and let ncurses give me the right KEY_* > defines with getch(). Well, I also want to support mouse events, but that's > probably the same thing (adding more escape sequences to stdin). > > I have added the following to my termcaps: > > :ku=\E[A:\ > :kd=\E[B:\ > :kr=\E[C:\ > :kl=\E[D:\ > > So that calling `has_key(KEY_UP)` and such returns 1. > > Also, I've called the following from my test code: > > keypad(stdscr, TRUE); > cbreak(); > timeout(0); > > Then, from my own keyboard driver, whenever I detect I've pressed "up" I add > the characters '\x1B', '[' and 'A' to the stdin buffer the same way I add any > other regular character (like 'g', '!', etc). > > getch() works with regular characters (and with '\n') but it returns me > individual characters of the escape sequence instead of KEY_UP. > > I've also noticed that if there is more than one character in my stdin buffer > ncurses won't behave as expected, so this may be a bug in my keyboard/stdin > driver. I'm just trying to rule out ncurses configuration issues. > > Am I missing something? > > Thanks, > Antonio
