ncurses' blocking mode appears to only allow for blocking on stdin - that is, I have no option of doing some select()-esque thing where getch() blocks until either a key is pressed or e.g. data arrives in a pipe. Am I missing something, or is there some other terminal control library that allows me to do this?
Edit: I'm targeting Linux platforms, although the more general the solution, the better.
There's an experimental configure-option, which is rarely used:
--enable-wgetch-events
Compile with experimental wgetch-events code. See ncurses/README.IZ
Related
My task at the moment is to port a driver for some 16550-compatible chip from QNX to Linux. The chip provides several UARTs, each one seen as a standard 16550 serial port, albeit with some extensions.
Now, in QNX, the whole device driver is packed into a standalone executable, that acts both as a driver and as an initial configurator for the provided UARTs (baud rates, loopback modes etc.) That is just natural in QNX because there device drivers run in user space and are little more than standard executables.
On Linux, OTOH, the driver is now implemented as a kernel module, loadable at will. More, that module is provided by the producer, so I would not want to modify or patch it too much.
For me, the remaining task is to provide some mechanism for setting up those UARTs' parameters. They are seen as /dev/ttyPREFIXX devices. I intend to do that through a standard C-programmed executable calling standard termios (ie tcsetattr() or ioctls) on the serial ports of interest.
Which leads me to the question: is my approach right? And, if yes, then how to achieve a persistent configuration? As I perceive the fact (from this example: http://www.easysw.com/~mike/serial/serial.html), the termios functions act on OPEN devices. In short: they open a device, they set up the parameters, they read or write, then close the port. After closing the port, is the configuration (baud rate etc.) lost? I hope it is not, because it is stored, already, into the hardware.
Can somebodey confirm to me that the configuration is persistent? And, if not, how to achieve that persistence, for the future applications that would open again that port and will expect it with some pre-established parameters? If not, should I modify the module kernel to accept some parameters and, then, do the configuration at the load time?
The approach that I intend for now is to write that C executable that opens the ports, sets up their configuration, then close the ports. I hope the latter applications will see the ports with the desired configuration.
Thank you.
You might want to have a look at stty and setserial. The venerable Serial-HOWTO (wow, when was the last time I actually recommended a HOWTO to anyone?) is probably also a good starting point.
Well, I found the answer here: http://www.gnu.org/software/libc/manual/html_node/Mode-Functions.html#Mode-Functions
Quote: "Although tcgetattr and tcsetattr specify the terminal device with a file descriptor, the attributes are those of the terminal device itself and not of the file descriptor. This means that the effects of changing terminal attributes are persistent; if another process opens the terminal file later on, it will see the changed attributes even though it doesn't have anything to do with the open file descriptor you originally specified in changing the attributes."
This clears the issue.
This may be a stupid question, but is there a way to write to the linux console from within a driver without using printk (i.e. syslog)?
For instance, working in a linux driver, I need to output a single character as an event happens. I'd like to output 'w' as an write event starts, and a 'W' when it finishes. This happens frequently, so sending that through syslog isn't ideal.
Ideally, it would be great if I could just do the equivalent of printf("W") or putc('W') and have that simply go out the default console.
TIA
Mike
Writing to the console isn't something you want to do frequently. If printk is too expensive for you, you shouldn't try the console any way.
But if you insist:
Within printk, printing to the console is handled by call_console_drivers. This function finds the console (registered via register_console) and calls it to print the data. The actual driver depends on what console you're using. The VGA screen is one option, the serial port is another (depending on boot parameters).
You can try to use the functions in console.h to interact with the console directly. I don't know how hard it would be to make it work.
Unfortunately no, as there is no concept of "console" in the kernel (that is a userspace process). You may try other kernel debugging options
I am thinking of creating an arcade machine for fun. Something like this one. I wonder if it's possible to get events from some game, e.g.Super Mario. Assume I finish a level and I want to get that event, with the score and some other data and perform some actions with that data. I am thinking of running the emulator in Windows. Did anybody work on something like this? Are there not too difficult ways to get events and data from old NES games? May be I should run not Windows, but some Linux for that? Well, please share your thoughts about how to do the software part of it.
Modern emulators such as FCEUX make it possible to interact with the running ROM through Lua scripts (see example video). Using this API you could write a Lua script to:
monitor a certain memory location
wait for it to hold some special value (such as level_just_finished)
read out the current score from memory
do something with the score
In order to know which memory locations to check, you will either need to disassemble the ROM or run it through a debugger, or both. As for Super Mario Bros, there's already a commented disassembly available. The FCEUX emulator also has a built-in debugger/disassembler that you can use.
All of this takes a lot of effort and you would need to know Lua, 6502 assembly, and the inner workings of an NES. For your arcade machine, you might be better off just using an emulator such as UberNES, which automatically can track your highscore for many popular titles.
Class NES games don't have standard hooks for achievement reporting. The only options I can think of are the following:
Rebuild the ROMs in question, with your own hooks (which a custom emulator could handle).
Watch the ROM memory footprint directly, and parse the state continually, triggering when you observe some known state.
Both options require that you really understand the internals of a NES ROM.
IRQ...Go for Interrupt_requests..they triger a interrupt...I have read / and seen the code about it somewhere...even x86 also uses IRQs for communciation with various device a simple exmaple:keyboard when a key is pressed a call is made ti PIC and an IRQ is generated and system knows which key is pressed and the same mech is used in NES
I have an application running on Linux, and I find myself wanting windows (!).
The problem is that every 1000 times or so I run into concurrency problems that are consistent with concurrent reading/writing of files. I am fairly sure that this behavior would be prohibited by file locking under Windows, but I don't have any sufficiently fast windows box to check.
There is simply too much file access (too much data) to expect strace to work reliably - the sheer volume of output is likely to change the problem too. It also happens on different files every time. Ideally I would like to change/reconfigure the linux file system to be more restrictive (as in fail-fast) wrt concurrent access.
Are there any tools/settings I can use to achieve this ?
Hmmm. Concurrent access to files is perfectly legitimate on Posix-like systems so there is no kind of "failure" mode associated with it. Is there a reason you can't use file-locking on Linux? It's difficult to tell from your description what the actual problem is (1000 times of what?) but it sounds like the traditional flock() or lockf() system calls might be what you're looking for.
For some reason I thought you were using C++. The following applies if you are.
If you are using multi-threading and fstream IO and custom streambufs or you disabled sync_with_stdio, then yes, the C++ iostreams will act differently from iostreams on Windows.
I ran into this with one of my own projects.
Windows defines a mutex in its iostream sentry. Linux does not. Linux does seem to have locking in its C stdio functions, so usually that works out anyway.
However, I defined a custom debug streambuf that didn't go through stdio and got all sorts of corruption in Linux.
I got around it by using a mutex that is preprocessed out if the OS is Windows.
I want to be able to intercept (and do arbitrary processing on) auto-repeating key presses on Windows. I'd like to know how keyboard auto-repeat is implemented so that I know what options I have. i.e. can I intercept at the:
application,
device driver and/or
hardware level
?
Update: It looks like auto-repeat is (poorly?) generated at the hardware level and then overridden by device drivers (see here).
To modify or filter behavior, you can intercept keys using a hook:
SetWindowsHookEx using WH_KEYBOARD
The hook procedure receives, among others, the repeat count (due to holding down the key)
Note that the low level keyboard hook (WH_KEYBOARD_LL) does not receive the repeat count.
If all your windows are created in the same trhead, you can use a thread-specific hook, and avoid moving the hook procedure to a DLL.
I dimly remember that repeat counts are generated by the keyboard itself and the LL hook sends repeated keydown events - I may be mistaken, though. Under DOS, the key repeat rate and time that was set in BIOS or through a BIOS call did return to default values when a DIN or PS/2 keyboard was unplugged and replugged. I am not sure WHY you need to know exactly.
I suggest that you might want to edit your question... your actual question is "How to suppress auto-repeat on Windows in ${yourLangauge}"...
To which my response is, I haven't got a clue, I've only ever done it in assembler (MASM 80286)... and even then I found a solution on a BBS (does anyone remember them) and just used it. From memory, the intercept has to be done at the device-driver level.
The implementation of autorepeat ($100 says it's assembler) problably won't shed any light on supressing it... that and Microsoft plays those cards very close to it's chest.
Cheers. Keith.
EDIT: I've just thought... techniques may now differ between versions of windows and the plethora of various devices... Oh goodie!
Sounds likes this is "Not programming related", however.
Go to "Accessibility Options" in control panel.
Select "Settings" under "Filter Keys" group, in here, you can switch off repeating keys for that user on that machine.
Hope this is what your looking for.
P.S. Above instructions given for Windows XP.