¿Sería posible leer los trazos físicos del teclado en node.js?

Tengo una aplicación de nodo que se ejecuta en una pi frambuesa que hace un seguimiento de un montón de jugadores UPnP (Sonos), que me gustaría poder controlar a través de un control remoto físico. Tengo un par de airmouses, que tienen teclados pequeños y botones de volumen que me gustaría usar.

He intentado controlar cómo leer teclas físicas en una máquina Linux y llegué a la conclusión de que necesito leer los eventos del dispositivo de entrada, que en mi caso sería:

/dev/input/by-id/usb-Dell_Dell_QuietKey_Keyboard-event-kbd

Cómo encontrar el dispositivo y cosas por el estilo no es un problema, el problema real es cómo interpretar los datos que lees.

Sé que recibirías una estructura, como esta:

struct input_event {
    struct timeval time;
    unsigned short type;
    unsigned short code;
    unsigned int value;
};

Pero no estoy seguro de cómo iría leyendo esto desde el nodo. Si pudiera ejecutar una aplicación externa que se activaría a partir de pulsaciones de teclas predefinidas y luego invocar una solicitud HTTP en mi nodo, esa sería mi segunda opción, una secuencia de comandos de Python o algún daemon nativo. Sin embargo, he visto algunos demonios de teclas de acceso rápido, pero ninguno de ellos funcionó.

Si, por supuesto, sería bueno si pudiera contenerlo dentro del nodo de alguna manera.

EDITAR: Así que hice algunas pruebas, e hice un fragmento simple:

var fs = require('fs');

var buffer = new Buffer(16);

fs.open('/dev/input/by-id/usb-HJT_Air_Mouse-event-kbd', 'r', function (err, fd) {
    while (true) {
        fs.readSync(fd, buffer, 0, 16, null);
        console.log(buffer)
    }
});

Esto produce algo como esto (para el espacio):

<Buffer a4 3e 5b 51 ab cf 03 00 04 00 04 00 2c 00 07 00>
<Buffer a4 3e 5b 51 c3 cf 03 00 01 00 39 00 01 00 00 00>
<Buffer a4 3e 5b 51 cb cf 03 00 00 00 00 00 00 00 00 00>
<Buffer a4 3e 5b 51 ba 40 06 00 04 00 04 00 2c 00 07 00>
<Buffer a4 3e 5b 51 cd 40 06 00 01 00 39 00 00 00 00 00>
<Buffer a4 3e 5b 51 d2 40 06 00 00 00 00 00 00 00 00 00>

Me doy cuenta de que los primeros cuatro bytes son una especie de marca de tiempo, y los siguientes 3 bytes podrían ser algo así como una cosa de micro / milisegundo.

Otra cosa extraña es que no todas las pulsaciones de tecla producen salida, pero una pulsación posterior puede enviar el doble de datos, y la mayoría de las veces comienza a eliminar datos que se detendrían después de pulsaciones de tecla posteriores (o después de unos 20 segundos). No estoy muy seguro de cómo interpretar eso. He intentado leer la fuente de este demonio.https://github.com/baskerville/shkd/blob/master pero C no es mi lenguaje más fuerte y no puedo identificar cómo lo maneja (o si debería ser manejado). Y ese demonio ni siquiera funcionó para mí (lo compiló en una pi de frambuesa).

Respuestas a la pregunta(2)

Su respuesta a la pregunta