Yes, I think the article's description of getch() as being inadequate due to a lack of debouncing is a bit weird. I would think that debouncing would be done even earlier, in the keyboard itself, since the debouncing you need is necessarily specific to the actual hardware. While USB HID keyboards are state-based (they transmit a packet listing which keys are pressed), the PS/2 protocol is event-based, and transmits "make" and "break" messages for key-press and key-release events, respectively.

(That said, I wouldn't be surprised if debouncing were done in the driver. I just think it's the wrong place for it.)

I suspect the author may have some experience implementing ad-hoc buttons via GPIO polling from userspace, and maybe used getch() in doing so.

The thing about getch() is that there's not really one standard getch(). There's a Windows version of getch() which is compatible with, notably, Borland's version for DOS (I think), and then various people have reimplemented getch() for other systems.

They might have meant to write getc() or getchar()...

That would make no sense at all. I think the comparison to getch() is the natural one here.

I suppose, from the linux perspective going through curses for this use case, in the same sentence mentioning "debouncing" seems awkward, but it does at least provide a polling api. Honestly I have no idea what they're talking about there.

> And you don't need root if your program's user is in the input group on most distros.

It's complicated. Being in the input group is part of it, but to actually get the access you need to interface with the freedesktop-derived multiseat stack, which is as clunky as everything else that comes from the fd.o folks.