[linux-dvb] Re: cinergyT2 remote, repeat handling, keycodes WAS:(Re:Re: cinergyT2: which kernel/usb module to use?)

[Holger Waechtler <holger@qanu.de>]

Stefan Lucke wrote:

> Quoting Holger Waechtler:
>
>  
> > Hi Stefan,
> >
> > Stefan Lucke wrote:
> >
> >    
> > > On Montag, 29. November 2004 10:40, Holger Waechtler wrote:
> > >
> > >
> > >      
> > > > Stefan Lucke wrote:
> > > >
> > > >   
> > > >        
> > > > > Yes IR works. Key repeat rate is much to high. Pressing "1" and to "2" is
> > > > > written multiple times upon a short hit.
> > > > >
> > > > >
> > > > >     
> > > > >          
> > > > The device should just report the raw keycodes it receives from the 
> > > > remote control without touching them. Please read the comment in the 
> > > > code about the sketchy keyrepeat implementation, if you want a 
> > > > host-controllable keyrepeat rate you just need to properly implement the 
> > > > input-device keyrepeat timer initialisation and then report keyrepeat 
> > > > events instead of repeating up/down events to the applications.
> > > >   
> > > >        
> > > I just worked around that, by ignoring the first few repeat event codes,
> > > see attached file.
> > >
> > >
> > >      
> > The linux input infrastructure handles this properly for you by 
> > setting/modifying/canceling a repeat timer -- please have a look in the 
> > input and event implementation in the kernel (you would now have to send 
> > repeat events instead of repeating key up/downs...)
> >    
> At the moment I won't dig that deep into driver programming.
>
> Thats not the major problem. The real problem is, not all keycodes
> arrive at application side :-( even they were reported via syslog.
> Numbers, up, down, left and right are ok.
>  
please use evtest like Johannes suggested.

> By the way, is it possible to wakeup the computer via an usb event ?
> That didn't work for me although wakeup via usb is set in bios.
>  
Hmm, don't know for sure. Is the suspend() callback of the 2.6. USB 
stack called in this case? If so you may want to remove 
stopping/restarting the query_rc work queue in suspend()/resume(), then 
it may work. Can you please let us know whether this is the case?

If so we can keep the RC queries (although maybe a little slower than 
usual, e.g. at a rate of 0.5sec or so - ) running in sleep mode. Or even 
set the bulk_read() timeout to several seconds and just wait until an 
event arrives from the receiver.

Holger