Reading from keyboard / dev / input / event 0 or reading from stdin?
I am working on a small C video game library for the Raspberry Pi. I am coding an input system from scratch and after reading and looking at some examples of raw input I got some doubts.
To read the mouse, I just use / dev / input / event 1, I open () this as O_NONBLOCK, I read () input_event (s), and I also read the mouse in a separate pthread. Easy.
For keyboard reading, I've seen some examples that reconfigure stdin to O_NONBLOCK (using fcntl ()), then save and reconfigure keyboard terminals settings (ICANON, ECHO), and in some cases also save and reconfigure keyboard mode using ioctl () ... What's the point of doing all this and not just reading / dev / input / event 0 input_event (s) (just like a mouse)?
Note that I don’t know what these functions do, I just don’t understand why it’s best to do all of this and not just read input_event (s).
source to share
Reading stdin is not limited to reading locally attached keyboards (but has a different limitation, making it mostly unusable for gaming). Then, by reading stdin, you can read the keystrokes from the remote user using a locally connected serial terminal or a terminal emulator (possibly from a remote X server).
For terminal games, it might make sense to use stdin. But then it would be better to use GPM instead of reading / dev / input / event 1 for the mouse. And it might even be better to use ncurses for everything.
Otherwise, you can watch SDL if you don't use it directly, at least to learn different ways to read input.For example, SDL has full support for network transparency using X. This means a game can run on a single computer, but playable on another.
source to share
Extending Fabel's answer - stdin and event1
- are completely different things. From that point on, event1
doesn't have to be a mouse, but could be a different device depending on udev, kernel version, moon phase, etc. - on my (non-Raspberry Pi) system input device Sleep Button
- which has a keyboard interface.In short, you cannot and should not assume that it is a keyboard - or the only keyboard for that matter (for example, YubiKey emulates a keyboard for it, but it's pretty useless as a gaming device, and while 2 keyboards are rarely plugged into the same Raspberry Pi, I don't think it's a good idea to assume such a setup would never happen).
Also, usually input devices can only be read by a privileged user (on older / current systems) or by a "seat" user (on systems without X roots) - if you are not using a bleeding system, this means your game can only be used by as root, which is generally considered a bad idea .
Finally, it only allows the user to play with the evdev subsystem, which should probably be seen as a Linux / X11 implementation detail. If you try to connect over a network (X11, vnc or whaterver) try using the onscreen keyboard or any available input program - you may run into problems.
On the other hand, what you can do is either use standard input directly, use some more portable libraries like readline (which should be enough for rougulike ), or use a graphical server (perhaps indirectly through a library like QT or SDL like X11 is not the best protocol for programming).
source to share
Reading from /dev/input/eventN
only works with GNU / Linux.
Setting up and using stdin works on any system that implements POSIX.1-2008 , in particular Section 11: Common Terminal Interface . So if you need portable code, say, for example, to work on Linux and OS X without rewriting the input system, you would do it like this.
source to share