El dom, 18-07-2010 a las 17:31 -0400, Franco Catrin L. escribió: > El vie, 16-07-2010 a las 22:49 -0400, Ricardo Albarracin B. escribió: > > 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. > > Por restricciones de tiempo creo que sólo reportaré el problema > adjuntando todos los datos que se necesitan para solucionarlo. > > Ya le dediqué más horas de lo que esperaba al tema y en el fondo lo que > yo quiero es tener el control remoto andando. > > > En el otro caso sólo sales del problema, haciéndolo funcionar pero el > > problema para el resto sigue vigente. > > "ni" > > Otros podrán usar la misma solución que espero aplicar. >
yayayaya.. tu eres el culpable Ricardo. Al final me metí a ver cuál era el problema y efectivamente era un Report Descriptor malo. Gracias a las indicaciones en [1] pude recompilar el modulo rápidamente para poner traza y ver exactamente dónde estaba el problema. Ahora sólo me queda la tarea de enviar el patch [2] para que el control funcione out-of-the-box. [1] https://wiki.ubuntu.com/KernelCustomBuild [2] http://www.tuxpan.com/fcatrin/files/aureal.patch -- Franco Catrin L. http://www.tuxpan.com/fcatrin TUXPAN Software S.A.