How to get the actual keyboard device given the output of /proc/bus/input/devices

I wrote this a long time ago. It's a script that sits between the user's input and an interactive program, and allows the input to be intercepted. I used it to escape to the shell to check filenames when running old Fortran programs that asked lots of questions. You could easily modify it to intercept particular inputs and sanitize them.

#!/usr/bin/perl

# shwrap.pl - Wrap any process for convenient escape to the shell.

use strict;
use warnings;

# Provide the executable to wrap as an argument
my $executable = shift;

my @escape_chars = ('#');             # Escape to shell with these chars
my $exit = 'bye';                     # Exit string for quick termination

open my $exe_fh, "|$executable @ARGV" or die "Cannot pipe to program $executable: $!";

# Set magic buffer autoflush on...
select((select($exe_fh), $| = 1)[0]);

# Accept input until the child process terminates or is terminated...
while ( 1 ) {
   chomp(my $input = <STDIN>);

   # End if we receive the special exit string...
   if ( $input =~ m/$exit/ ) {
      close $exe_fh;
      print "$0: Terminated child process...\n";
      exit;
   }

   foreach my $char ( @escape_chars ) {
      # Escape to the shell if the input starts with an escape character...
      if ( my ($command) = $input =~ m/^$char(.*)/ ) {
         system $command;
      }
      # Otherwise pass the input on to the executable...
      else {
         print $exe_fh "$input\n";
      }
   }
}

A simple example test program you can try it out on:

#!/usr/bin/perl

while (<>) {
   print "Got: $_";
}

It represent the bitmask for events supported by the device.

Sample of devices entry for a AT Keyboard:

I: Bus=0011 Vendor=0001 Product=0001 Version=ab41
N: Name="AT Translated Set 2 keyboard"
P: Phys=isa0060/serio0/input0
S: Sysfs=/devices/platform/i8042/serio0/input/input2
U: Uniq=
H: Handlers=sysrq kbd event2 
B: PROP=0
B: EV=120013
B: KEY=20000 200 20 0 0 0 0 500f 2100002 3803078 f900d401 feffffdf ffefffff ffffffff fffffffe
B: MSC=10
B: LED=7

The B in front stands for bitmap, N, P, S, U, H are simply first letter in corresponding name value and I is for ID. In ordered fashion:

• I => @id: id of the device (struct input_id)
  • Bus     => id.bustype
  • Vendor  => id.vendor
  • Product => id.product
  • Version => id.version
• N => name of the device.
• P => physical path to the device in the system hierarchy.
• S => sysfs path.
• U => unique identification code for the device (if device has it).
• H => list of input handles associated with the device.
• B => bitmaps
  • PROP => device properties and quirks.
  • EV   => types of events supported by the device.
  • KEY  => keys/buttons this device has.
  • MSC  => miscellaneous events supported by the device.
  • LED  => leds present on the device.

Bitmasks

As you know computers deal in binary, so:

1 = 0001
2 = 0010
3 = 0011
4 = 0100
5 = 0101
...

So if i have a bitmap with value 5 that one would hold bits 0 and 2 in other word one can give each number a name and check if they correspond to a value.

E.g.

A = 1,  001
B = 2,  010
C = 4,  100

Then if I have MYVAR = 5 which is 101 in binary this would check out:

MYVAR & A == TRUE   (101 & 001 => 001)
MYVAR & B == FALSE  (101 & 010 => 000)
MYVAR & C == TRUE   (101 & 100 => 100 )

Thus my var has A and C.

The kernel uses a bit more sophisticated/complex way, and set bits by offset. One reason being that more bits then is available in one computer (CPU) integer is used. For example look at the KEY bitmap.

So, if we say:

A = 0
B = 1
C = 6
...

And then

target = 0;
set_bit(A, target);  => target ==      0001
set_bit(C, target);  => target == 0100 0001

Decoding 120013

The value 120013 is a hexadecimal. As binary it gives us:

0x120013 == 0001 0010 0000 0000 0001 0011 binary
               1    2    0    0    1    3

Numbered from right they are:

   2            1               <= offset (10's)
3210 9876 5432 1098 7654 3210   <= offset (counted from right)
0001 0010 0000 0000 0001 0011   <= binary

Set bits are:
   0, 1, 4, 17, 20

Then check input-event-codes.h you find that they correspond to:

   0  EV_SYN (0x00)
   1  EV_KEY (0x01)
   4  EV_MSC (0x04)
  17  EV_LED (0x11)
  20  EV_REP (0x14)

To check what they mean a quick introduction is given by Kernel documentation.

* EV_SYN:
  - Used as markers to separate events. Events may be separated in time or in
    space, such as with the multitouch protocol.

* EV_KEY:
  - Used to describe state changes of keyboards, buttons, or other key-like
    devices.

* EV_MSC:
  - Used to describe miscellaneous input data that do not fit into other types.

* EV_LED:
  - Used to turn LEDs on devices on and off.

* EV_REP:
  - Used for autorepeating devices.

This, "EDIT 2 (continued):" in particular, might be of interest.