I am writing my own kernel in c. Now I want to code a Console to interact with the Kernel. It should work like the normal Terminal on Linux. How can I get a input over the Keyboard ? Do I have to use Keyboard specific drivers ?
You need to write a driver in your kernel for the keyboard. Assuming a standard PC, the 8042 keyboard controller is pretty well documented (see http://wiki.osdev.org/%228042%22_PS/2_Controller for example). You'll also need to write a driver for the display, and again assuming VGA it is pretty well documented (see http://wiki.osdev.org/VGA_Hardware). Then you'll have to write all of the terminal stuff that sits in between to connect the two.
Related
There are some cases when it is needed to see the full log of Linux kernel panic.
But it often can't be done through the regular terminal in display.
I thought that it should be done through the COM-port, but can't figure out:
How can I do that?
What is the reason of working well through COM-port, but not through terminal in my display?
UPD: I use debian-based custom Linux (4.9 kernel) with HDMI-display.
Related: How to get a Linux panic output to a USB serial console when system has also a display adapter
Simple direct connected console / VTY use the graphics card to convert character bytes (0 - 255) into display character cells. 80x25 is a common format. This is very simple and not hard for a crashing kernel to manage. Just copy some memory around.
The graphical console is more complicated because the kernel now has to locate the font bitmap for a character and copy the bitmap onto the display. It also needs to handle scrolling with more memory copies, or IOCTL calls into the graphics driver, etc.
A console running in a Gnome or KDE GUI session is very complicated. The kernel isn't involved in drawing it at all and doesn't know how.
The more complex the output process is, the less likely that a kernel that is already crashing can manage it successfully.
Serial port output is once again very simple. A buffered UART makes it a bit more complicated, but if a crashing kernel wants to ignore that and simply output bytes at a 9,600 line rate, any serial port will work with that without needing buffers or interrupt management.
I'm working on a small C videogames library for the Raspberry Pi. I'm coding the input system from scratch and after reading and seeing some examples about raw input reading, I got some doubts.
For mouse reading, I just use /dev/input/event1, I open() it as O_NONBLOCK, I read() input_event(s) and I also put the mouse reading in a separate pthread. Easy.
For keyboard reading, I saw some examples that reconfigure stdin to O_NONBLOCK (using fcntl()), then save and reconfigure keyboard termios attibutes (ICANON, ECHO), and some example also save and reconfigure keyboard mode with ioctl(). What's the point of doing all that stuff instead of just reading /dev/input/event0 input_event(s) (same way as mouse)?
Note that I undestand what those functions do, I just don't undestand why should be better to do all that stuff instead of just reading input_event(s).
Reading stdin is not limited to reading locally connected keyboards (but has other limitation making it mostly unsuitable for games). Then reading stdin you could be reading keystrokes from a user logged in remotely, using a locally connected serial terminal or a terminal emulator (possibly operated from a remote X server).
For terminal based games it might make sense to use stdin. But then it would probably be better to use GPM instead of reading /dev/input/event1 for the mouse. And possibly even better to use ncurses for everything.
Otherwise you might want to look at SDL, if not for using it directly, at least for learning about different ways to read input. For example, SDL has full support for network transparency using X. Which means a game can execute on one computer but be played on another.
Expanding on Fabel answer - standard input and event1 are entirely different things. Starting from that the event1 does not have to be mouse but can be an other device depending on udev, kernel version, phase of moon etc. - on my (non Raspberry Pi) system it's input device Sleep Button - which has a keyboard interface. In short you cannot and should not assume it's keyboard - or the only keyboard for that matter (for example also YubiKey emulates the keyboard for it's function but it's rather useless as gaming device, and while 2 keyboards are rarely connected to same Raspberry Pi I don't think it's good idea to assume such setup never happens).
Furthermore typically input devices can be read only by privileged user (on older/current systems) or by user holding a 'seat' (on rootless X systems) - assuming you're not using bleeding edge system it means your game can only by used by root user which is usually considered a bad idea.
Finally it only allows for user to play using a evdev subsystem, which probably should be considered Linux/X11 implementation detail. If you try to connect via network (X11, vnc or whaterver), try to use on-screen keyboard or any accessible input program - you might 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 sufficient for rougulike) or use graphics server (probably indirectly via library like QT or SDL as X11 is not the nicest protocol to program against).
Reading from /dev/input/eventN works only on GNU/Linux.
Configuring and using stdin works on any system implementing POSIX.1-2008, specifically chapter 11: General Terminal Interface. So if you want portable code, like say to work on Linux and OS X without rewriting the input system, you'd do it this way.
I'm writing a Windows kernel driver in C and I need to send and receive data over a serial device, specifically COM3. I am stuck on the CreateFile, ReadFile, and WriteFile functions, as these seem to be user space functions that will not work in the kernel. Am I mistaken? Or if not, what is the best way to open and use a serial port from within the Windows kernel?
Many thanks.
You need ZwCreateFile, ZwReadFile and ZwWriteFile functions for working in kernel mode.
You are writing a driver then You must have to write kernel module for windows .
check this
http://www.codeproject.com/Articles/9504/Driver-Development-Part-1-Introduction-to-Drivers
One more thing once you have finished the driver you need a application to test it.
so you need a user space application to test it.
I have just managed to write my first windows driver (havent registered it yet- but i managed to get the things created!).
I wondered if someone can give me a high overview of how I could achieve the following:
I would like to write a driver which will implement some behaviour when a network packet is received by the computer, before windows does what it does with the packet, i'd like to take this data and output it to the console of a C or C++ program.
Lets assume I have a C/C++ program written, which has a console. How does the C/C++ program interact with the driver I wrote which is hooking the network activity? Is it simply some C code which calls my drivers, the function returns the data as an object and then I can use that object to display in the console?
Thank you in advance for any possible replies
You don't need a driver for this task. Use packet sniffer library like PCap (actually you'll need WinPCap). It's really simple to capture packets and print them to console.
Alternative way is raw socket. But desktop Windows (as opposite to Windows Server) limits raw socket functionality.
If you really want a driver, or have a requirement to manipulate or filter packets before they hit the windows network stack you need to look into filter drivers.
This filter driver can then expose a device file on which your user space application can then read/write. The windows DDK contains examples.
I'm desperately looking for some C sample source code that describes how to implement a HID client using Bluez. More specifically, I would like to know how to write an application that sends keyboard inputs over bluetooth to another Linux system. (Really, the fact that the receiver is running Linux/Bluez shouldn't matter.)
-Cheers
hidclient http://anselm.hoffmeister.be/computer/hidclient/index.html.en ?
Shamelessly copying from a previous answer of mine:
Some time ago I found this project:
http://nohands.sourceforge.net/index.html
They emulate a full-blown headset with
audio and keyboard controls on the
Linux bluetooth stack. If they can
emulate something like that, you would
probably be able to emulate something
simpler like a keyboard.
Here is full example apply to keyboard and mouse include get report set report virtual unplug function. the client hid is slave side...
http://fatalfeel.blogspot.tw/2013/09/hid-client-of-bluez.html
and you can refer to bluez/android/hidhost.c(Master side) see how to connect to slave