ATi Remote key repeat

  Chris Jones wrote:
> Does anyone know how I can control the repeat rate of my ATi Remote Bob
> (which appears as a regular keyboard in /dev/input)? It's a great
> remote, but at the moment (Ubuntu Dapper) I basically can't use it
> because each button press prodces 4 or 5 events, so I can't use the OSD.

is this an x10 remote using the kernel ati_remote driver? if yes, you can try the attached patch.
A Medion remote i have was unusable w/o this change; eg. pressing the same key twice resulted in six events: one for the first key press and five for the second. Switching to channel '11' or moving two lines down triggers this...
With the patch the (pseudo-)auto-repeat rate goes down 5x, but the remote becomes usable. I don't have any ati remotes so i can't tell if this problem affects them. (the patch also adds some extra keycodes for the medion remote)

artur
  

On Tue, Jun 27, 2006 at 12:35:55PM +0200, Artur Skawina wrote:
> Chris Jones wrote:
> >Does anyone know how I can control the repeat rate of my ATi Remote Bob
> >(which appears as a regular keyboard in /dev/input)? It's a great
> >remote, but at the moment (Ubuntu Dapper) I basically can't use it
> >because each button press prodces 4 or 5 events, so I can't use the OSD.
> 
> is this an x10 remote using the kernel ati_remote driver? if yes, you can 
> try the attached patch.
> A Medion remote i have was unusable w/o this change; eg. pressing the same 
> key twice resulted in six events: one for the first key press and five for 
> the second. Switching to channel '11' or moving two lines down triggers 
> this...

I wonder why you can't just use the IR frame repeat rate as the key repeat
rate.  If the key repeat is disconnected from frame repeat, it is hard to
scroll down a menu, say, by exactly 7 steps.

I and Darren Salt patched the cx88 driver (of the new Hauppauge Nova-T)
to do that, but sadly it seems that the patches will not make it to the
v4l hg tree.  The patches map the RC5 frame repeat rate of 113 ms to
key repeat.  The first repeated frame is discarded in order to get some
delay before initial repeat.  The repeat rate feels okay.

	Marko
	http://www.iki.fi/~msmakela/software/vdr/
  

On Tue, Jun 27, 2006 at 12:07:34PM +0100, Chris Jones wrote:
> > I wonder why you can't just use the IR frame repeat rate as the key
> 
> I'm not sure exactly what that is, but since the device is presented as a
> "standard" input device, might I be able to use some system tool to control
> the repeat rate?

I was referring to the kernel module that implements the input device driver
for the infrared receiver.

	Marko
  

On Tue, Jun 27, 2006 at 12:22:02PM +0100, Chris Jones wrote:
> On 12:15:22 pm 27/06/2006 Marko  Mäkelä  <marko.makela@hut.fi> wrote:
> > I was referring to the kernel module that implements the input device
> > driver for the infrared receiver.
> 
> This is an RF receiver, not IR. Or is it really just transmitting IR
> commands over RF?

The protocol is likely entirely different.  I'm sorry, my suggestion of
simply mapping repeated packets to key-repeat events is inappropriate
for RF communications, where packet loss or corruption is much more probable
than in IR communications.  According to a comment in the beginning of
ati_remote.c, "The hardware generates 5 events for the first keypress".

	Marko
  

Hi

On Tue, 2006-06-27 at 12:07 +0100, Chris Jones wrote:
> I'm not at home at the moment, but I believe it is indeed the x10 remote.

Just to confirm, it is:

Bus 001 Device 004: ID 0bc7:0004 X10 Wireless Technology, Inc. X10
Receiver

and is using the ati_remote driver

Cheers,
  

Chris Jones wrote:
>>>  A Medion remote i have was unusable w/o this change; eg. pressing
>>>  the same key twice resulted in six events: one for the first key
> 
> I get many events from just pressing the key once. I used to be able to tap
> the keys very quickly and just get a single event, but I think the
> behaviour has changed with the newer kernel in Dapper (or one of the
> updates of it, I'm not sure exactly when this started because I don't use
> the remote all the time)

Hmm, one thing to check would be whether the HZ value of the kernels changed -- i think i saw similar behavior after changing HZ from 1000 to 250 with no other changes to the driver. Apparently FILTER_TIME was set very close to the limit and changing the delay slightly (it is 50*1000**-1=50ms for HZ==1000, but only 48ms (12*250**-1) for HZ==250) breaks the drivers autorepeat detection. The patch i sent fixed this too (for the HZ==250 case).

> I'm not sure exactly what that is, but since the device is presented as a
> "standard" input device, might I be able to use some system tool to control
> the repeat rate? All I can find thus far is kbdrate, which doesn't seem to
> let me specify which input device I want it to alter.

Unfortunately the device seems to send 5 events for every key press, which makes it hard for the driver to determine if you just pressed a key twice or just held the key down for a bit longer (it receives 10 events in both cases). It tries to guess, but gets it wrong for some cases. Basically it reports the first keypress, then ignores the next four. Then if it receives the same key again it starts reporting every event. Which might be fine if you're holding the key down, but isn't if you pressed the same button a second time. And since it tries to measure the delay between events, even a small error in timing could make things go wrong. At least this is what's happening w/ one of the medion remotes i have, i don't have any ati hw to test.
The newer models of the ati and medion remotes may not have this problem, as they apparently alternate the keycodes, hopefully making it easier to detect autorepeat w/o guessing (iow pressing a button a second time results in a different keycode).

artur
  

On Tue, Jun 27, 2006 at 02:13:25PM +0100, Chris Jones wrote:
> No probs - at this stage I'm grateful for as much input (no pun intended ;)
> on the issue as I can get, because I'm a bit stumped! I'd really like to
> avoid patches if possible, if only because between the various xine and vdr
> patches and packages, keeping current is proving rather time intensive!

Testing CVS releases of softdevice and DirectFB can be even more time
intensive, but it can also be very rewarding.

> Hmm, that's very interesting. I guess I should start reading the source.

It's not that hard to make simple modifications to kernel modules.

BTW, I found out that the vdr-remote plugin reduces the key-repeat rate
by using some timer magic.  On IR remotes using the RC5 code, the inherent
repeat rate is 113.8 ms.  Using vdr-remote plugin, the rate was something
like half or third of that.  With softdevice and DirectFB linux-input
driver and with my kernel patch, I get all RC5 frames (except the first
repeated one that I discard on purpose) mapped to vdr key events.

	Marko