Scan codes for keys

Holger said:
Try x11/xev
Click to expand...
That's not the same. X events, shown by xev, are not scan codes. There is a Linux utility called showkey that is supposed to show the scan codes seen by the kernel. I've never used it. Instead I've used, actually written an MS-DOS app, that read the keystrokes directly from the keyboard controller. Otherwise the BIOS would read the keystrokes for you, giving you the ASCII instead.

The linux showkey utility is not the same as the showkey in FreeBSD ports. The FreeBSD port does not return scan codes like the Linux utility can.

To get the actual keyboard scan codes would require some kernel hacking to create an interface which an app could call to return the code itself rather than its ASCII representation.

Personally, I think it's easier to boot DOS to run some utility that reads output from the keyboard controller directly. DOS runs in real mode, therefore there is no such thing as kernel mode or user mode. It's all "kernel mode." If you want see the scan codes for some diagnostic purpose you're better off using DOS rather than mucking around in the kernel.

Also remember, the keyboard controller only knows about the AT keyboard. USB keyboards don't produce scan codes in the AT keyboard sense. And MS-DOS will not recognize anything USB. (You could try FreeDOS.)
 
Holger said:
Well, then OP might elaborate about what he wants to achieve?
Click to expand...
I'm trying to find out what control character is generated by, for example the BACKSPACE key, in FreeBSD.

Control character - Wikipedia

en.wikipedia.org en.wikipedia.org

In text mode FreeBSD, the character before the cursor is deleted, whereas when in emacs (-nw) this character is interpreted as C-h, but only on one system.

Maybe I have different charsets configured on different systems.
 
Knowing the scancodes might also be relevant if you want to customize a keymap(5) for the console. A way to get the scancodes on FreeBSD would be nice, booting MS-DOS or FreeDOS for such a task feels ... wrong ... somehow.
 
You should be able to get a raw character in your terminal by typing Control+v and then the key of which you want to know the value, i.e. typing Ctrl+v and then [Enter] will show you ^M (carriage return).

After this you can pipe it to hexdump(1). For example:
Code: 
$ echo -n ^M | hexdump
0000000 000d
0000001
where ^M is the raw character and 0d its hexadecimal value.

HTH
 
I think you can do that in few lines of ncurses/C, and it'll be system-portable.

Code: 
initscr();
noecho();
cbreak();
timeout(10);

int ch;
while(1) {
  ch = getch();
  if(ch != ERR) {
    printf("Key : "%s\n", keyname(ch));
    refresh();
  }
}

From head, didn't try. If you put this in a C file make sure you write a SIGINT handler and put endwin() in it, otherwise your console won't reset to original when you kill the program
 
steps said:
A way to get the scancodes on FreeBSD would be nice, booting MS-DOS or FreeDOS for such a task feels ... wrong ... somehow.
Click to expand...

It's also technically wrong because you can set your controller (i8042) to use different set of scan codes. So whatever FreeBSD uses (I'm assuming scan code set 2) is not necessarily what MS-DOS would use. It's also very version dependent.

I'm assuming you are aware that one key (press/release) can be built of sequence of scancodes even within the set (i.e. one scancode != one key event).

I'm busy at the moment but have a look in sys/dev/kbd and sys/dev/atkbdc, you should be able to determine what scancode set FreeBSD sets.
 
cracauer@ said:
Emacs' own `M-x describe-key` is usually enough to solve emacs problems.
Click to expand...
Emacs is the problem! M-x describe-key shows 'C-h-' when Backspace is pressed.

I've just noticed that this only happens in text mode. If I run emacs -nw under X, I don't have a problem, so I need to get used to only running it that way.
 
balanga said:
Emacs is the problem!
Click to expand...
No context needed 😏

But seriously, please read about the XY-problem. It's much more efficient to directly describe the actual problem, which in this case had nothing to do with scan codes. In the original meaning, a scan code is a way to encode a (physical) position in the keyboard matrix, it's derived from "scanning the matrix" by pulling a specific matrix row to low and then checking which column goes low, allowing to deduce which key is pressed in this row (or, of course the other way around with rows/columns exchanged). In today's keyboards, a keyboard processor built into the keyboard is doing that. In a broader sense, although not entirely correct, the term "scan code" is also used for codes sent "over the wire" between the keyboard and the main unit over the "classic" interfaces (XT,AT,PS/2,...). In any case, you won't ever see "scan codes" when talking about userspace applications on a modern OS.
 
zirias@ said:
No context needed 😏

But seriously, please read about the XY-problem. It's much more efficient to directly describe the actual problem, which in this case had nothing to do with scan codes. In the original meaning, a scan code is a way to encode a (physical) position in the keyboard matrix, it's derived from "scanning the matrix" by pulling a specific matrix row to low and then checking which column goes low, allowing to deduce which key is pressed in this row (or, of course the other way around with rows/columns exchanged). In today's keyboards, a keyboard processor built into the keyboard is doing that. In a broader sense, although not entirely correct, the term "scan code" is also used for codes sent "over the wire" between the keyboard and the main unit over the "classic" interfaces (XT,AT,PS/2,...). In any case, you won't ever see "scan codes" when talking about userspace applications on a modern OS.
Click to expand...
I used the term 'scan code' because that is what I was used to saying many years ago with my original PS/2 keyboard. I was simply trying to find out why FreeBSD knew what to do when I pressed Backspace and Emacs didn't. I guess the answer is far more complicated than I want to know.
 
balanga said:
I used the term 'scan code' because that is what I was used to saying many years ago with my original PS/2 keyboard.
Click to expand...
The phenomenon of the XY-problem is not about using terms in a wrong way (and, "scan code" is often used wrong, so I just thought I'd add a short explanation what it really means for those interested ...), but
balanga said:
I was simply trying to find out why FreeBSD knew what to do when I pressed Backspace and Emacs didn't.
Click to expand...
about not mentioning THAT directly, which is, well, the actual problem 😉
 
balanga said:
Emacs is the problem! M-x describe-key shows 'C-h-' when Backspace is pressed.

I've just noticed that this only happens in text mode. If I run emacs -nw under X, I don't have a problem, so I need to get used to only running it that way.
Click to expand...
You do not need to get used to only running it that way. The whole point of Emacs is that you bend it to your will. Just redefine the key to do whatever you want.
 
_martin said:
I'm busy at the moment but have a look in sys/dev/kbd and sys/dev/atkbdc, you should be able to determine what scancode set FreeBSD sets.
Click to expand...

I don't know if there's any other (non intrusive) way of doing this. But if for whatever reason you do need to see the scan codes you can recompile the kernel with the option:
Code: 
options     KBDIO_DEBUG=10
As sys/dev/atkbdc/atkbd.c:L678 has option for that.

Here's an example of me pressing 'a' in my VMware VM:
Code: 
Sep 21 00:24:40 vmfbsd13 kernel: atkbd_read_char(): scancode:0x1e
Sep 21 00:24:40 vmfbsd13 kernel: atkbd_read_char(): scancode:0x9e
Which would be a scan code set 1. For clarification: make code = key pressed, break code = key released. As I mentioned above one event (make/break) can generate more scan codes (that's why keyboard driver keeps an internal state machine). In some specific scenario (I'm not 100% sure without googling) break code is not generated.
 
oOiOo said:
misc/kbdscan is the right tool for that. It works only in console.
Click to expand...
While this tool might be what is OP aiming for (legit answer then) it's not spitting out raw scancodes.

For example kbd driver reads out following bytes from controller when arrow up is pressed (make: e0 48, break: e0 c8):
Code: 
Sep 21 20:57:09 vmfbsd13 kernel: atkbd_read_char(): scancode:0xe0
Sep 21 20:57:09 vmfbsd13 kernel: atkbd_read_char(): scancode:0x48
Sep 21 20:57:09 vmfbsd13 kernel: atkbd_read_char(): scancode:0xe0
Sep 21 20:57:09 vmfbsd13 kernel: atkbd_read_char(): scancode:0xc8

While kbdscan gets
Code: 
Scancode 95 pressed.
Scancode 95 released.
95 being 0x5f.

Even with terminal in raw mode (which this utility does) some translation does happen.
 
You must log in or register to reply here.
Back
Top