Re: Solucionado! (Re: Ayuda con Control Remoto USB HID y/o adaptador infrarojo.)

2010-07-19 Por tema Ricardo Albarracin B.
El Mon, 19 Jul 2010 00:18:59 -0400
Franco Catrin L. fcat...@tuxpan.com escribió:

 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
 
Eso sí, que bien que lo hayas resuelto, parchado y reportado.

Al final es mejor para todos. Good.

Atentamente.
+---+-+
| Ricardo Albarracin B. | email: ral...@gmail.com |
+---+-+


Solucionado! (Re: Ayuda con Control Remoto USB HID y/o adaptador infrarojo.)

2010-07-18 Por tema Franco Catrin L.
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.