The description of the opcode FX0A is:
Wait for a keypress and store the result in register VX
My question is if a key is already pressed while the opcode is called, is it considered a keypress? Or will it not be considered a keypress until the key is released and then pressed again?
In other words, do I need to wait until a value of a key is pressed, or until a value is set from not_pressed to pressed?
Fx0A - LD Vx, K
Wait for a key press, store the value of the key in Vx. All execution stops until a key is pressed, then the
value of that key is stored in Vx.
(Source)
If we take this literally, "wait for a key press" would imply no previous input, but to simply wait right here and now for a key.
Though perhaps you should just make it configurable in your application.
Related
I have a Linux distribution, and I'd like to be able to detects a wide range of keys, but I can't figure out how to distinguish the press of the Escape key, versus a key detected as keypress.
If I use this:
require 'io/console'
puts STDIN.raw { STDIN.getc }
and press, say, Arrow up, the interpreter will return immediately \e, then on subsequent getc calls, without pressing any key, it will return the remaining chars of the escape sequence ([ and A).
The problem is that, after the first getc call, I don't know if the user has actually pressed Esc, or another key which generates an escape sequence.
Is it possible to make the distinction between the two cases, without multiple getc invocations?
I don't think so, because the character input is done at a higher level than the physical keyboard. That is, by design, an ESC character read by getc is an ESC character, no matter how on the keyboard it was input (or not input on the keyboard at all, for example, by redirection).
I don't think Ruby out of the box has a way to detect hardware events such as keyboard presses. There is IOCTL for lower level device access, but I don't know how to use it for your purpose. But even if you could, how would you handle alternate keyboard layouts? What you expect to be an ESC key might be mapped to a different character.
There is a read_nonblock method on $stdin that you might use to see if there is an additional character in the buffer immediately after reading the ESC key. If so, it's likely that a special character other than ESC was pressed. If not, it's likely the ESC key was pressed.
Given this statement:
if (GetKeyState(VK_CAPITAL) & 0x8000)
{
cout << "caps lock" << endl;
}
It works fine if I press caps lock alone, or along with any key except ctrl. I was thinking it's because ctrl is a modifier, but this works fine when holding shift. Is there something I'm missing?
GetKeyState() provides the synchronized state of the keyboard. The state of all the keys when the key was pressed. It can take a while before your program sees it, Windows provides type-ahead, so it is important that the state of all keys is known to reliably detect whether Shift, Alt, Ctrl were down at the time.
The synchronized state gets updated when you call GetMessage(). Done in the boilerplate message loop of a Windows program.
But since you use cout, you probably wrote a console mode program and don't use a message loop at all. So it doesn't update. And you'll have to use GetAsyncKeyState(). No buffering at all, so you have to call it often. Do note that the console also has a way to retrieve keystrokes with buffering supported. Probably what you really want/should do when you write code like this. Watch out for input redirection.
I'm basically trying to figure this out because I want to use my iMac as an external monitor for my macbook air. I also want to use the iMac keyboard for my macbook air however for some reason, Apple has decided that once you press and hold Command F2 to activate Target Display Mode (meaning it is now an external monitor) that the keyboard paired with the iMac cannot be unpaired with the iMac.
To work around this I thought I would just pair the keyboard with the macbook air initially (leaving the iMac without a keyboard) and create an Applescript macro that would simulate the keyboard pressing and holding the Command F2 for five seconds eliminating the need to go buy another Apple keyboard.
Here's what I have so far and it doesn't work. It's telling me F2 is not right. I'm pretty sure F2's key code is 120.
tell application "System Events"
key down Command
key down F2
delay 5
key up Command
key up F2
end tell
Does anyone know how I might accomplish this?
Observations as of OS X 10.9.1:
There's a problem with the way you're sending F2 (you need to use (key code 120) instead of just 120), but the larger problem is that key up/down only works as expected with modifier keys.
While NON-modifier keys can be sent (using (key code <n>) syntax), the up / down aspect is ignored, making both key down (key code <n>) and key up (key code <n>) statements effectively the same as key code <n> (i.e., a Key Down event immediately followed by a Key Up event is sent).
There's a suggested workaround here, based on repeatedly sending keystrokes in short sequence - it's worth a try, but from a technical perspective it's not the same as keeping a key [combination] held down, so I'm not sure it'll work.
Adapted to your situation (and replacing key down with key code), we get:
tell application "System Events"
set now to the seconds of the (current date)
set later to now + 5
if later > 60 then set later to later - 60
key down command
# Workaround: send F2 repeatedly.
repeat while the seconds of the (current date) is not later
key code 120
end repeat
key up command
end tell
As I said: this may not work; also note that the loop is "tight" meaning that it'll make your machine pretty busy (if sending keys repeatedly, but not necessarily as fast as possible is an option, you could insert a short delay).
Some optional background info:
The key up and key down commands, while also requiring the System Events context, are NOT exposed in the System Events.sdef, the app's dictionary (only key code and keystroke are listed) - this may indicate that Apple doesn't officially support them.
On OS X 10.9.1 (unlike on OS X 10.8 - don't know about earlier versions) there is a bizarre bug where an extra "a" keypress is sent whenever you use key down with a (keycode <n>) specifier.
Ways of determining key-code values (gleaned from various other SO answers, mostly here):
Key Codes, a free GUI app for interactive use - very handy.
The following header file on your system (list of codes in hex format):
/System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/Headers/Events.h
List of decimal codes (incomplete):
I've started a project to do something similar, namely monitor the iMac and automatically trigger target display mode and toggle off bluetooth when a Macbook is connected. You can download it from https://github.com/duanefields/VirtualKVM.
Recently, I ran into a situation where I would like to use threaded IRQ's for a Keypad driver. For some background on threaded IRQ handlers:
http://lwn.net/Articles/302043/
From what I understand, every time an IRQ would occur the IRQ handler thread would be woken up. So, if i press KEY A, it wakes up the thread and it runs through to completion. Now, what would be the behavior should i press KEY B, when the handler thread is still running while servicing the IRQ from KEY A... Would the IRQ from KEY B be ignored ?
What would be the expected behavior ?
Ideally the system would always acknowledge the sequence of Key A->Key B.
However to acknowledge that a key was pressed, the system must do something at the point at which each key is pressed, I.e. when the keyboard interrupt occurs - at a minimum it must record the key presses, perhaps in a queue.
And from the perspective of a single processor, it can only do one thing at a time, so if it is in the middle of recording key press A, then it can't at the same time record key press B.
It would either have to abandon A and record B instead, or it would have to ignore B.
Thus the goal of interrupt handling is to minimise the amount of time the processor spends doing the minimum it needs to for acknowledging any given interrupt.
The goal of threaded interrupts is to push more of the work to separate threads, so that the minimum needed for acknowledging an interrupt is reduced, and therefore the time spent handling the interrupt (where it can't handle any other interrupts at the same time) is reduced.
Even then there is still no theoretical guarantee that the processor won't have to discard or ignore interrupts, but it does make it a lot less likely in practice.
For your specific example of key presses, if you were somehow able to be quick enough to press B before the processor had completed its minimum handling of A, then since both interrupts are from the same source, and therefore have the same priority, B would be ignored, and it would appear to you as if B was never pressed.
The way it works with interrupts is that processor will call an enabled interrupt over and over again until application clears the corresponding interrupt flag. So what you do is disable that particular interrupt in the hardware handler and wake up your thread. When hardware handler exits, interrupt flags will be set but the interrupt will not be called again. So you then in your thread checkeach flag and clear it as you go. When you detect that a flag for a keypress is set, you read out the key and then clear it. If a new key is pressed after you read data register and there is no fifo in hardware then that key press will be lost. You then clear the interrupt flag and enable the hardware interrupt again. The idea is that this process happens so fast that there is no way to lose a key because your thread will always run sooner than human can press another key.
In the situation such as usb (ie if you write a usb driver that communicates with pc) you have the option to tell usb peripheral when you are done reading data so it can tell the host it can accept more data. In that situation you can never lose data because you will read data out and clear the flag and only then tell the peripheral that you are ready. All the time until then the peripheral will tell the host that it is not ready so no data will be clocked in over the usb bus.
Currently I am working on a project which has following setup.
AVR micro-controller
IDE - AVR Studio
Operating system - FreeRTOS
For input I am using a keypad matrix of 4x3. I have already coded for 4x3 keypad to take inputs as numbers. But now I want to make it alpha-numeric. Like we see in our mobile phone keypads.
Example - Key 2 will be used to take input for 2,a,b,c. Single press key 2, we will get number 2, double press key 2 then we will get 'a', tripple press key 2 then we will get 'b' and fourtimes press key 2 then we will get 'd' on scree.
I hope all of you understood what I mean above. Can anybody give some code idea in C to implement this type of functionality?
You most likely just need to keep track of the system time of the last key press and compare it to the system time of the next key press. If the current key is the same key as the last press and the time between presses is small (say, under one second), replace the current input character with the next character in the list of characters for that key. If the time difference is more than one second, or if a different key was pressed, accept the current character and add a new character, starting at the first character in the list for the key.
see the issue is when you press 2(say) in xxx sec time later after 30 millisec if you check and find that 2 is pressed then there are two cases.
case1> the pressed key is new and is same as previous
case2> the pressed key is same as previous and it is pressed from xxx till now contineously.