El Thu, 15 Jul 2010 17:09:01 -0400 "Franco Catrin L." <fcat...@tuxpan.com> escribió:
> [.........] > 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 ese caso, no será mejor corregir en la base el descriptor? > 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. Si bien esto puede funcionar, pero estas corrigiendo el problema por una puerta trasera y no desde el fuente, en tu lugar trataría de corregir el problema en el fondo, ya sea reportando el problema o comunicándome con el o los desarrolladores para que se corrija, así se gana en la comunidad. En el otro caso sólo sales del problema, haciéndolo funcionar pero el problema para el resto sigue vigente. > Saludos Saludos RAB