3 ms·
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 ev
by klodolph 5y ago
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.)
- pengaru 5y agoI suspect the author may have some experience implementing ad-hoc buttons via GPIO polling from userspace, and maybe used getch() in doing so.
- klodolph 5y agoThe 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.
- pengaru 5y agoThey might have meant to write getc() or getchar()...
- klodolph 5y agoThat would make no sense at all. I think the comparison to getch() is the natural one here.
- pengaru 5y agoI 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.