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 |
+---+-+


Re: Ayuda con Control Remoto USB HID y/o adaptador infrarojo.

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

Saludos
-- 
Franco Catrin L. http://www.tuxpan.com/fcatrin
TUXPAN Software S.A.



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.



Re: Ayuda con Control Remoto USB HID y/o adaptador infrarojo.

2010-07-16 Por tema Ricardo Albarracin B.
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


Ayuda con Control Remoto USB HID y/o adaptador infrarojo.

2010-07-10 Por tema Franco Catrin L.
Hola!!

Hace varios días estoy peleando con un control remoto en Linux, y llegó
un punto en donde no sé qué más mirar.  Algo se me debe estar pasando y
en esto influye mi poco entendimiento de los subsistemas input, irda,
lirc y usb/hid.

Se trata de lo siguiente:

Tengo un control remoto que se usa con un adaptador USB [1]. El
adaptador se comunica con el control remoto via infrarojo:

USB - adaptador USB - señal infraroja - control remoto.

Al enchufar el adaptador, éste se reporta como un dispositivo HID
múltiple y el sistema lo reconoce como si fueran tres generadores de
eventos : puntero del mouse, botones del mouse y teclado.

Estando en X, lo unico que funciona es el puntero del mouse, y las
teclas no realizan ninguna acción.  Me compré este control con la
seguridad de que si era HID y se comportaba como un teclado, el
adaptador USB mandaría eventos estándares al sistema y para él se
trataría de un vil teclado.   Pero parece que no es tan así para Linux o
X.

Hay una aplicación llamada xev que me muestra los eventos que recibe X y
ahí puedo ver claramente que no le llega nada cuando apreto los botones,
salvo unos 4 o 5 botones que si mandan comandos (comandos multimedia) +
el cursor del mouse.

Enredándome más en el asunto, vi que lirc se puede configurar para que
la fuente de eventos sea la capa input de Linux, asi que creé una
configuración para leer los eventos por ahí y obtengo el mismo resultado
(monitoreando con irw).

Vi que habían algunos conflictos entre HAL y lirc, por lo que agregué
unas lineas para que HAL ignorara mi dispositivo : Mismo resultado.

Lo que creo que está pasando es que los eventos generados por el
adaptador no están llegando a las capas superiores y algun componente
del sistema se acabrona con ellos.  Aquí es donde me limitan los
conocimientos. [2]

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.

Espero que alguien de esta lista me pueda echar una mano con esto,
aunque estoy evaluando también otra opción...

Revisando lirc, vi que hay una configuración para usar el control remoto
Motorola DRC800[3] es el que incluye VTR con sus productos.  Vi que
algunos lo estaban usando con un adaptador infrarojo casero conectado
por puerto serial, pero para mi aplicación yo no dispongo de puertos
seriales. [4]


Me conseguí un adaptador modelo UZIrDA [5] para hacer pruebas.  Lo
puedo usar via irda para transferir archivos a un celular, pero no tengo
idea de como enlazarlo con lirc.  Mi esperanza es que via adaptadores
irda soportados por linux pueda usar el control remoto de Motorola.

Alguien tiene experiencia al respecto?

Saludos y gracias de antemano.

[1] http://tinyurl.com/27reu2z
[2] http://www.lirc.org/html/devinput.html 
[3] http://tinyurl.com/264rnjb
[4] http://lirc.sourceforge.net/remotes/motorola/ 
[5] http://tinyurl.com/279lypr 
-- 
Franco Catrin L.  TUXPAN Software
http://www.tuxpan.com/fcatrin



Re: Ayuda con Control Remoto USB HID y/o adaptador infrarojo.

2010-07-10 Por tema Alvaro Herrera
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.