Traducción Documentation/input.txt (es)

Submitted by kernel-labs on Sat, 2007-03-10 17:26.
Andrés José Borek y Danilo Vladimiro Borek, colaboran amablemente con kernel-labs.org cediéndonos una traducción al castellano, del documento input.txt de la documentación oficial del kernel Linux. Puede ser una buena introducción para el artículo sobre el Input Subsystem que tendremos listo desde kernel-labs en fechas venideras.

Linux Input drivers v1.0


(c) 1999-2001 Vojtech Pavlik
Sponsored by SuSE

Traducido por:
Andrés José Borek <andres.sid@gmail.com>
Danilo Vladimiro Borek <daniexpulsado@gmail.com>

1. Introducción

Esta es una colección de controladores que están diseñados para soportar todos las unidades de entrada bajo Linux. Actualmente es utilizado únicamente para la entrada de USB (mirar 2.5/2.6), en el futuro se espera que reemplace a la mayor parte de los sistemas de entrada, el cual estaría en drivers/input en lugar de estar en drivers/usb.

El centro de los controladores de entrada es el módulo de entrada, generalmente éste es leído antes que cualquier otro módulo - permite la comunicación entre dos grupos de módulos.

1.1 Controladores de Unidades

Estos módulos se comunican con el hardware (vía USB por ejemplo) y proveen de eventos (del ratón y del teclado) al módulo de entrada.

1.2 Manejadores de eventos

Estos módulos toman eventos de entrada y los pasan a las interfaces que los necesiten - tecleos para el kernel, movimientos del ratón vía una interfaz PS/2 simulada para GPM y las X.

2. Uso simple

Para la configuración más común, un teclado USB y un ratón USB, tendrás que cargar los siguientes módulos (o incorporarlos dentro del kernel):
  • input
  • mousedev
  • keybdev
  • usbcore
  • uhci_hcd o ohci_hcd o ehci_hcd
  • usbhid
Después de esto, el teclado USB debería funcionar correctamente siempre, y el ratón USB debería estar disponible como una unidad de carácter major number 13 y minor number 63.

crw-r--r--  1 root    root      13,  63 Mar 28 22:45 mice

Esta unidad debe ser creada.
Los comandos para crearla manualmente son:

cd /dev
mkdir input
mknod input/mice c 13 63

Después debes apuntar GPM (la herramienta de cortar&pegar del modo texto) y XFree a este dispositivo para utilizarlo. GPM debe ser invocado de la siguiente manera:

gpm -t ps2 -m /dev/input/mice

Y en las X:

Section "Pointer"
    Protocol    "ImPS/2"
    Device      "/dev/input/mice"
    ZAxisMapping 4 5
EndSection

Una vez hecho esto, el teclado y el ratón USB deberían funcionar correctamente.

3. Descripción detallada

3.1 Unidades manejadoras

Las unidades manejadoras son módulos que generan eventos. Generalmente son inútiles si no son invocados manualmente, entonces necesitarás utilizar algunos de los módulos de la sección 3.2.

3.1.1 usbhid

usbhid es el más grande y complejo manejador de la suite entera. Debido a que maneja todas la unidades HID, y porque hay una variedad muy amplia de ellos y además las especificaciones de los USB HID no son simples, éste necesita ser grande.

Actualmente maneja ratones USB, joysticks, gamepads, ruedas de manejo de teclado, trackballs, digitizadores.

Sin embargo, los USB también utilizan HID para los controles de monitor, los controles del altavoz, UPSs, LCDs y muchos otros propósitos.

Los monitores y los controles de altavoz pueden ser fáciles de agregar a la interfaz hid/input, pero para los USPs y los monitores LCD no tiene mucho sentido. Por esto la interfaz hiddev fue diseñada. Leer Documentation/usb/hiddev.txt para más información.

El uso del módulo usbhid es muy simple, no toma parámetros, detecta todo automáticamente y cuando una unidad HID es insertada, ésta es detectada apropiadamente.

Sin embargo, porque los dispositivos varían salvajemente, puede suceder que tengas un dispositivo que no funcione correctamente. En ese caso, agrega #define DEBUG al comienzo de hid-core.c y envíame el syslog de entrada.

3.1.2 usbmouse

Para sistemas empotrados, para ratones con descriptores HID no soportados y algún otro uso, cuando el enorme usbhid no es una buena opción, aquí está el controlador usbmouse. Maneja ratones USB solamente. Utiliza un simple protocolo HIDBP. Esto también significa que los ratones deben soportar este protocolo más simple. No hace todo. Si no tienes una buena razón para utilizar este modulo, utiliza el modulo usbhid.

3.1.3 usbkbd

Como usbmouse, este módulo se comunica con los teclados con un protocolo simplificado de HIDBP. Es más chico, pero no soporta teclas especiales extras. Utiliza el usbhid, en lugar de otro, si no hay alguna razón especial para utilizarlo.

3.1.4 wacom

Este es un controlador para Wacom Graphire y las placas Intuos. No para Wacom PenPartner, éste es soportado por el manejador HID. Aunque el Intuos y las placas de Graphire dicen ser placas HID, no lo son, así que necesitan este controlador específico.

3.1.5 iforce

Un controlador para los joysticks y las ruedas de la I-Force, ambos sobre USB y RS232. Ahora está incluido el soporte ForceFeedback, aunque Immersion Corp considera el protocolo como un secreto comercial y no divulga una palabra sobre él.

3.2 Controladores de eventos

Los controladores de eventos envían los eventos desde los dispositivos al espacio de usuario y al núcleo, según sea requerido.

3.2.1 keybdev

keydev es actualmente un 'hack' algo feo, que traduce los eventos de entradas del teclado, en modo raw, a la arquitectura específica (Xlated AT Set2 en x86) y lo pasa dentro de la función handle_scancode del módulo keyboard.c. Esto funciona bastante bien en todas la arquitecturas que el keydev puede generar en modo raw, es posible agregarle otras arquitecturas.

La manera correcta sería pasarle los eventos a keyboard.c directamente, mejor si keyboard.c fuera manejador de eventos. Esto está hecho en el input patch, disponible en la página mencionada abajo.

3.2.2 mousedev

mousedev es también un 'hack' para hacer programas que trabajen con las entradas del ratón. Toma eventos de cualquier ratón o digitalizador/tablas y crea el dispositivo de un ratón estilo PS/2 (en /dev/psaux), disponible en espacio de usuario. Idealmente, los programas podían utilizar un interfaz más razonable, por ejemplo evdev.
Dispositivos mousedev en /dev/input (como se ve arriba) son:

crw-r--r--  1 root    root      13,  32 Mar 28 22:45 mouse0
crw-r--r--  1 root    root      13,  33 Mar 29 00:41 mouse1
crw-r--r--  1 root    root      13,  34 Mar 29 00:41 mouse2
crw-r--r--  1 root    root      13,  35 Apr  1 10:50 mouse3
...
...
crw-r--r--  1 root    root      13,  62 Apr  1 10:50 mouse30
crw-r--r--  1 root    root      13,  63 Apr  1 10:50 mice

Cada dispositivo 'mouse' es asignado a un único ratón o digitalizador, excepto el último -'mice'. Este único dispositivo en modo carácter es compartido por todos los ratones y digitalizadores, y aunque no estén conectados, esta unidad está presente. Esto es útil para ratones USB hotplugging, entonces lo programas pueden abrir la unidad, aunque ningún ratón esté conectado.

CONFIG_INPUT_MOUSEDEV_SCREEN_[XY] en la configuración del kernel es el tamaño de la pantalla (en pixeles) en XFree86. Esto es necesario si deseas utilizar el digitalizador en las X, porque su movimiento es enviado mediante un ratón virtual PS/2, y por consiguiente necesita así, ser escalado. Estos valores no serán utilizados si solamente utilizas un ratón.

Mousedev generará cualquier PS/2, ImPS/2 (Microsoft IntelliMouse) o el protocolo ExplorerPS/2 (IntelliMouse Explorer), dependiendo de los datos que el programa desee leer. Puedes poner el GPM en las X para cualquiera de ellos. Necesitarás ImPS2 si deseas hacer uso de la rueda del ratón USB y ExplorerPS/2 si deseas utilizar botones extras (más de 5).

3.2.3 joydev

Los instrumentos joydev v0.x y v0.1 de la api de los joysticks en Linux, como drivers/char/joystick/joystick.c utilizados en cualquier versión. Ver joystick-api.txt en el subdirectorio de documentación para más detalles. Tan pronto esté conectado un joystick, se puede acceder en /dev/input:

crw-r--r--  1 root    root      13,  0 Apr  1 10:50 js0
crw-r--r--  1 root    root      13,  1 Apr  1 10:50 js1
crw-r--r--  1 root    root      13,  2 Apr  1 10:50 js2
crw-r--r--  1 root    root      13,  3 Apr  1 10:50 js3
...

Y así sucesivamente hasta js31.

3.2.4 evdev

evedev es una interfaz genérica de entrada de eventos. Ésta pasa los eventos generados en la cadena del kernel a los programas, con los timestamps. La API se está desarrollando, pero ahora puede ser utilizada. Está descrito en la sección 5.

Esta puede ser la manera para que GPM y las X tomen eventos de teclado y del ratón. Permite multihead en X sin ninguna ayuda específica del multihead del núcleo.
Las unidades están en /dev/input:


crw-r--r--  1 root    root      13,  64 Apr  1 10:49 event0
crw-r--r--  1 root    root      13,  65 Apr  1 10:50 event1
crw-r--r--  1 root    root      13,  66 Apr  1 10:50 event2
crw-r--r--  1 root    root      13,  67 Apr  1 10:50 event3

Y así sucesivamente hasta event31.

4. Verificando si funciona

Presionar un par de teclas puede ser suficiente para comprobar que el teclado USB funciona y si está conectado correctamente al manejador en el kernel. Haciendo un cat /dev/input/mouse0 (c, 13, 32) para verificar que el ratón esté emulado, al mover el ratón deberían aparecer una serie de caracteres.

Puedes verificar que el joystick esté emulado con la utilidad jstest, disponible en el paquete joystick (leer Documentation/input/joystick.txt).

Puedes testear las unidades de evento con la utilidad evtetst disponible en los archivos del proyecto CVS LinuxConsole (mirar la url abajo).

5. Interfaz de eventos

Si quieras agregar soporte a una unidad de manejo de eventos en cualquier aplicación (X, gpm, svgalib, ...) yo vojtech@ucw.cz estaré feliz de brindarte cualquier tipo de ayuda que pueda. Aquí va una descripción del estado actual de las cosas, el cual va a ser ampliado, pero no va a cambiar la incompatibilidad con el tiempo.

Puedes utilizar lecturas de bloqueo y no bloqueo, también select() en el controlador /dev/input/eventX, y siempre obtendrás un número entero de los eventos leídos. Su disposición es:

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

time es el timestamp, devuelve el momento en el cuál sucedió el evento. type es por ejemplo EV_REL para el momento relativo, REL_KEY para las teclas presionadas. Más tipos están definidos en include/linux/input.h.

code es el código del evento, por ejemplo REL_X o KEY_BACKSPACE, nuevamente la lista completa está en include/linux/input.h.

value es el valor que el evento lleva. Cualquier cambio relativo para EV_REL, cualquier valor absoluto para EV_ABS (joysticks ...), o 0 para cualquier lanzamiento de EV_KEY, 1 para tecla presionada y 2 para autorepetido.
printer-friendly version | login to post comments