0

I am trying to create Linux input device driver and to test things I took at existing gpio-matrix-keypad driver. Using print I know that input_report_key() is called with correct keycode, but it doesn't put a correct character under the cursor.

pr_info("Print: %d\n", keycodes[code]);
input_report_key(input_dev, keycodes[code], new_state[col] & (1 << row));

Also I work with BeagleBone Black using minicom. It seems that kernel is built with required for input options enabled, e.g. CONFIG_INPUT and CONFIG_INPUT_KEYBOARD.

Improve this question
7
  • Can you please give an example for what you are trying to insert and what is inserted instead?
    – ariel marcovitch
    Commented Apr 27 at 18:49
  • @arielmarcovitch it does not insert a character at all. But print gives correct input event code, e.g. KEY_1(numerical value - 2) for keypad key "1". I encoded them myself through Device Tree. Here you can take a look at the bindings. But it seems to me that the issue is not driver-related(since driver program flow is normal), but rather environmental.
    – MegaRaman
    Commented Apr 28 at 11:54
  • Also I've tried to use KEY_NUMERIC_1 instead of KEY_1 but the result remained the same
    – MegaRaman
    Commented Apr 28 at 12:00
  • I understand. Have you tried running evtest to make sure the character isn't written anywhere else? Also, what exactly is your setup? What do you run on your beaglebox? Is it a raw kernel with busybox?
    – ariel marcovitch
    Commented Apr 28 at 12:09
  • @arielmarcovitch Unfortunately, you're absolutely correct. It's just busybox and nothing else. cat /dev/input/eventX prints something unrecognizable on keypress.
    – MegaRaman
    Commented Apr 28 at 14:45

1 Answer 1

Reset to default
0

As we've discussed, the expected keys are inserted to the input subsystem correctly. They aren't getting to you via your serial connection and that's actually what should happen.

See, when you use serial connection, input and output for /dev/console come from /dev/ttyS* instead from a keyboard and a screen. This means the keyboard is not connected to the console or to the serial connection, so keys inserted via the keyboard will not get to you via serial.

However, all input from keyboards in the system get via the kbd input handler (see kbd_handler in drivers/tty/vt/keyboard.c) into vt. vt stands for 'virtual terminal' and it maintains several terminal sessions under the same screen+keyboard setup. These are the terminals you can switch to using ctrl+alt+f* on ubuntu, and these are the terminals under /dev/tty*

The same setup can be simulated by using qemu in -nographic mode. Then simulating keyboard input with sendkey in qemu's monitor, and seeing the output via the screendump monitor command.

To get the information from vt to you you can stick a shell on the vt like this: PS1='shell$ ' setsid sh -c "exec sh -i </dev/tty1 >/dev/ttyS0 2>&1".

Improve this answer
3
  • It seems like you're correct on the part that /dev/console is controlled rather by serial port than the keyboard. Unfortunately the command you provided doesn't work as I don't get any input from /dev/tty1 on a keypress. I tried to do the same on my PC just scheduling input_report_key() using hrtimer and it didn't lead to any input. But in that case input might be controlled through X11 or something that prevents direct access. I'm sorry for not answering.
    – MegaRaman
    Commented May 2 at 20:33
  • Oh since it worked for me in qemu I thought it is close enough to your situation to work... It is possible the the input is going to another vt but doesn't seem very plausible. Too bad I can't get the same setup as yours. Did you try on your PC after you switched to a tty that is not controlled by x11? You don't need to run the command as the input should get to your tty anyway. Can you show me what you did on your PC so I can try to reproduce it?
    – ariel marcovitch
    Commented May 2 at 21:16
  • Yes, switching to 3rd vt did the trick. I've thought that I will never get input_report_key() to work. What interesting I found: doing lsof | grep /dev/input/ on vt, not controlled by x11 returns nothing. But on controlled I get the output. On my board I also don't see anything reading /dev/input. So it is unnecessary for some process to be binded to /dev/input to receive an input. Maybe /dev/tty doesn't get input because, as I said tty returns not a terminal. Will try to attach it using -p flag in minicom.
    – MegaRaman
    Commented May 3 at 17:40

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .