In according to this pdf
ID 39 --> Keyboard Caps Lock (Implemented as a non-locking key; sent as member of an array)
ID 82 --> Keyboard Locking Caps Lock (Implemented as a locking key; sent as a toggle button. Available for legacy support; however, most systems should use the non-locking
version of this key)
I'm losing my mind with "non-locking" words.
What is the difference?
In my mind they are only different codes between legacy and not legacy, but with the same button layout and same function.
This Keyboard Locking Caps Lock (Usage 0007:0082) is not used in practice on any modern keyboard hardware and AFAIK its support is not implemented in any software including Windows.
I think it was modeled after latching Caps Lock (Shift Lock) key that was found on some vintage keyboards.
Example: https://deskthority.net/wiki/Cherry_MX_Lock
Related
I wan to develop my own keypad driver to my own keypad. I have to used GPIO to identify Key Events and used I2c to get scan code.
I am going to develop keypad driver like this.
#include <linux/gpio.h>
#include <linux/interrupt.h>
#define GPIO 1 //gpio PIN
...
if(gpio_request(GPIO, "Description")){
Exception
}
gpio_direction_input(GPIO);
...
int irq = 0;
if((irq = gpio_to_irq(GPIO)) < 0 ){
Exception
}
…
int init_module(){
int result = request_irq(GPIO, handler_func, IRQF_TRIGGER_LOW,"Description", "Device id");
if(result){
Exception
}
}
void handler_func(...){
//get scan code via i2c
}
I need to develop an interface and have to handle following operations
In my keypad, print as "1abc" on the [KEY1] .
1. When press key, display 1st Characters as it is -> "1"
2. Special key combinations are used to input other 3 characters
Eg:
key input operations as follows;
KEY1 (direct press) should display "1"
F1 + KEY1 (simultaneous press) should display "a"
F2 + KEY1 (simultaneous press) should display "b"
F3 + KEY1 (simultaneous press) should display "c"
My problem is how should I develop this interface?
You better follow Analog devices' Keyboard and GPIO Linux Driver. I'm going to link you to some GPIO drivers.
This driver included these features
Configurable keypad size matrix (rows, columns).
Support for switch events.
automatic key repeat.
Lock/Unlock key feature.
ADP5588 Keyboard - GPIO Linux Driver
ADP5589 Keyboard - GPIO Linux Driver
Your question is a bit vague, so I'm going to link you to some pages that describe making such input devices:
Steve Mann's septambic keyer
Building and using a 7 key chording keyboard
What is important for chording is to separate a key press from a key release. These actions send separate scancodes, and most keyboards use them.
If you are specifically interested in the logic, then reading the chorded keyboard wikipedia article may be helpful:
In Engelbart's original mapping, he used five keys: 1,2,4,8,16. The
keys were mapped as follows: a = 1, b = 2, c = 3, d = 4, and so on. If
the user pressed keys 1 + 2 = 3 simultaneously the letter "c"
appeared.
What you need to do is figure out which character is desired by looking at the combination of keys that are pressed down, but only send the character when all keys are released.
So if I pressed keys 1 and 2, then the bits for key 1 and key 2 are set, but the character is only determined and sent when I release all keys, at which point all the key bits are reset.
That is but one way to do it. It's your system, and you can make it arbitrarily complex.
Maybe you want to base it on n-gram frequency and send character phrases instead of single characters. Maybe you want to base it on sequences of letters pressed and released, with arbitrary chord sequence termination, rather than when you release all keys. It's up to you.
If you are using a normal keypad, and not one you built yourself, watch out for problems with key rollover. Basically, most keyboards have limits on which keys can be pressed at the same time.
The answer depends on the kernel version and the architecture that you are using.
If you are using an architecture that is supported in 3.1 or later then you can use the gpio-keys driver to create a keyboard event device file that you can configure in the OpenFirmware device tree and then read from userspace. The advantages of this approach over the approach suggested in the OP are that you do not have to write any new kernel code, and you can write your higher level driver entirely in userspace using a loop that does a blocking read on the device event file. (Now I realize that "not have to write any new kernel code" isn't nearly as cool as writing your own kernel module, so this might not be seen as an advantage by everyone ;-)
Even if you are using an older kernel, you can still use the gpio_keys driver using the older "board file" configuration approach used in the ADP5589 gpio driver suggested as a solution by user3072817. This still gives you the advantage of a device file on which you can do a blocking read from userspace.
To use the newer gpio-key approach you need to add a gpio-keys section to the device tree for your board, which should be located in arch/<your arch>/boot/dts. The syntax for the binding is specified in gpio_keys.txt. You can see an example gpio-keys device tree configuration for the Manga touchscreen on the BeagleBone here. This example also shows a gpio-key userspace driver, written in Python. Remember to compile your kernel with CONFIG_KEYBOARD_GPIO.
Hi I have a SPI touch device with 24 keys, each read will return 3 bytes, containing exact all 24 keys status. My hardware is a custom made beaglebone like device, spi0 is able to read its own write by connecting MISO to MOSI.
Everything (wiring, software) is working perfectly matching this guide: http://communistcode.co.uk/blog/blogPost.php?blogPostID=1
Now my touch device is CS active high device, but it requires to drive the chip select to low and back to high before actual read. I don't seems to have control with SPI cs value, I can only either control it within an actual read phase by specifying CS high or low. From my knowledge I have to use another GPIO to emulate the CS.
Question: any way to control cs freely? (i.e. set 0 or 1 by my code directly?)
I have solved this by pinmux the CS pin to a GPIO, and control it manually prior to actual communication.
Assuming that OS running on host PC is real-time (has no extra delays when handling the input from keyboard) - how much is the value of delay between the moment when the single key is pressed on a keyboard and the moment when the keyboard controller generates an interrupt.
I understand that it vary depending on keyboard connection (ps/2, usb, laptop keyboard) and wire length (not taking into account wireless models). Maybe there are some common calculation already done?
I'm writing a little text mode application using curses on Linux.
For keyboard input I use the curses functions. Key auto-repeats work, e.g. if I hold a key down I get multiple key events until I release the key again.
Is it also possible to distinguish between real key events and those generated by the key repeat logic?
Background: The application is a little data-entry front-end where the user can modify integer numbers of certain parameters. In the long run the application will work without a standard keyboard. I will only have four buttons for data-entry: 'increase', 'decrease', 'ok' and 'cancel'.
Since the number ranges are large I'd like to know if the user holds down a key. If he does so I can scan faster through my numeric range by not incrementing my number by one but by 10 or maybe 100. If the user otoh taps the key the input method should be precise again and just increase/decrease the numbers by one.
Is this possible with the keyboard input functions of curses?
No - curses just receives keys from the terminal. If you really need it you could try to find out if the key repeats are automated or not by looking at the delay between each keypress. However, especially over remote connections, this might not be a good solution as the delay will be affected by network latency.
The best solution might be using UP/DOWN for small steps and PAGEUP/PAGEDOWN for large steps.
When I press a keyboard's key on some GTK application under Linux, what happens exactly? How does a key get received (from which device), interpreted, passed to the program, and then handled?
It's actually rather a complex process...
The keyboard has a 2D matrix of key connections and its own microprocessor or gate array containing a microprocessor. It is constantly scanning the matrix to find out if any keys are pressed. (To save pins, the keys are not individually tested.) The keyboard micro speaks a protocol with the keyboard controller in your CPU and transmits a message indicating a keypress.
The keyboard controller notes the code and interrupts the CPU.
The keyboard driver receives an interrupt, reads the keycode out of a controller register, and places the keycode in a buffer that links the interrupt side of the kernel to the per-process threads. It marks the thread waiting for keyboard input as "runnable"
This thread wakes up. It turns out, this is the X server. The X server reads the keycode from the kernel.
The server will will check to see which window has keyboard focus. The window will be connected to one of various clients.
The server sends an event to the client that displayed that specific window. (Note that to the server, every textbox and such is a "window", not just entire applications.)
The event loop in the client is waiting for the next server event message. This connection could be via TCP or it could be a local Unix feature. It uses read(2) or a socket op to actually get the next event message.
The low-level xlib routine passes the keypress up to higher level widgets, eventually getting to a GTK function of some kind.
The GTK API element hands the character to your program.
I glossed over language mappings, console multiplexing, and a few other things...
Update: So, /dev/input/* and in fact all of the /dev/* things are things called block or character special files. The important thing is that they have no stored data in the filesystem, just a major and minor device number that serve to look up a driver in the kernel in a table. It's almost that simple. If you ls -l /dev/input you will see a major and minor device number instead of a file size. The major number identifies the device driver and the minor number is a sort of instance-number that is passed (within the kernel) as a parameter to the driver.