El dom, 11-07-2010 a las 00:31 -0400, Alvaro Herrera escribió: > Excerpts from Franco Catrin L.'s message of sáb jul 10 16:15:11 -0400 2010: > > > Un antecedente que me dejó mas picado aún es que estando en GRUB, el > > control remoto funciona perfectamente, todos los botones se reciben como > > si provinieran del teclado, por lo tanto eso aclara más que Linux los > > está filtrando o hace algo para que no le lleguen. > > Hmm, sugerencia: inicia en modo single y ve hasta qué punto puedes > hacerlo andar en un X mínimo (dear old startx), o incluso en mplayer sin > X (-vo aa?). Si funca, es hora de echar a andar servicios uno por uno, > hasta encontrar el que bloquea los eventos.
Ya encontré la causa del problema, les cuento por si alguien se topa con algo parecido: Los eventos se propagan así: dispositivo -> usbhid -> input layer El problema es que por algún motivo, usbhid está descartando algunos eventos que provienen del control y no los propaga a input layer. Una de las causas probables es que el descriptor USB HID del dispositivo esté malo. En BIOS no se usa ese descriptor y probablemente Windows tampoco lo usa, por lo que el dispositivo está OK para sus fabricantes. usbhid prevee esos casos y tiene mecanismos para ignorar estos defectos, pero no he logrado hacer que ignore lo que está malo en este control. usbhid también prevee ese caso, y envía los eventos HID por /dev/hidraw*. Desde ese device si puedo leer los eventos y veo todas las teclas. Para no meter mano en el kernel, voy a hacer una solución ad-hoc en userspace: hidraw -> aplicacion -> /dev/lircd De esta forma puedo mapear todas las teclas del control a lo que yo quiera, y para las aplicaciones compatibles con lircd quedará oculta esta complejidad (alguien dijo abstracción?). Afortunadamente inputlirc es un buen punto de partida para implementar esta solución. Saludos -- Franco Catrin L. http://www.tuxpan.com/fcatrin TUXPAN Software S.A.