[linux-dvb] Re: NEWSTRUCT and Remote Control

[Oliver Endriss <o.endriss@gmx.de>]

On Wednesday 04 September 2002 14:01, Holger Waechtler wrote:
> Oliver Endriss wrote:
> > On Wednesday 04 September 2002 12:28, Holger Waechtler wrote:
> >>Oliver Endriss wrote:
> >>>[...]
> >>
> >>hmm, I just tested again with the new firmware, it works fine for
> >> me. Anyway, I found a typo in the README concerning the usage of
> >> av7110_loadkeys. For the Hauppauge remote control you should use:
> >>
> >>$ ./av7110_loadkeys [-i] hauppauge.rc5 > /proc/av7110_ir
> >
> > Bingo! It works after *redirecting* the output of av7110_loadkeys
> > to /proc/av7110_ir. Thank you for the hint!
> >
> > Just two suggestions:
> > Please update the usage string of av7110_loadkeys, too.
> > Perhaps you could add a line or two to the README file
> > stating that there is absolutely *no* kernel output if the protocol
> > and/or inversion settings are incorrect.
>
> ok, I'll do so.
>
> > I just played around with evtest and found the following:
> > Approx. 0,5 sec after the key-down event you always get a key-up
> > event, no matter whether you hold down the key or not. Apparently,
> > the new firmware generates only key-up events. Is this ok?
>
> it generates key-down events.

My mistake: Should read 'the new firmware generates only key-down 
events'.

> When you lost the IR connection you
> definitely want to create an artificial key-up event to prevent
> endless keyrepeats from the linux input driver.

I totally agree. The old firmware did this, too (see below).

> > The old firmware generated both down _and_ up events, so it was
> > possible to implement something like a auto-repeat function if you
> > hold down the key for more than a second.
>
> The old firmware generated an up-event after each down-event. If you
> want this behaviour you can simply ignore the up-events and process
> only down's.
>
> Hmm, the remote control I have generates an event every 1/5th second,
> so you still get keyrepeats. Maybe we have to enable the repeat
> option in the linux input driver for Hauppauge remote controls...
>
> A proper keyrepeat-sequence looks like this:
> key-down-down-...-down-up. Only in this way the application can
> distinguish between a
> "double-clicked" key and a repeat because of a not-yet-released key.
> This convention is used by other keyboard and input drivers, too. We
> changed this behaviour to make it easy for applications to use the
> same input event loop for keyboards and remote controls.

That's exactly the way it should be, but see below...

The Hauppauge remote control  behaves the following way:

Old firmware:
Hold down key '1':
| Sep  4 14:25:41 orion kernel: GPIO0 irq 8 4
| Sep  4 14:25:41 orion kernel: GPIO0 irq 08
| Sep  4 14:25:41 orion kernel: av7110: ircommand = 80000001
| Sep  4 14:25:41 orion kernel: GPIO0 irq exit 0
| Sep  4 14:25:41 orion kernel: #########80000001######### key 01
|  pressed (keycode 2)

Note that there is *no* repetition of key-down events!

Now release the key:
| Sep  4 14:25:42 orion kernel: GPIO0 irq 8 4
| Sep  4 14:25:42 orion kernel: GPIO0 irq 08
| Sep  4 14:25:42 orion kernel: av7110: ircommand = 00000001
| Sep  4 14:25:42 orion kernel: GPIO0 irq exit 0
| Sep  4 14:25:42 orion kernel: #########00000001######### key 01
| released (keycode 2)

The same occurres if the infrared signal gets blocked (still holding 
down the key). Signal loss generates a key-up event.

New firmware:
Hold down key '1':
| Sep  4 14:28:54 orion kernel: GPIO0 irq 8 4
| Sep  4 14:28:54 orion kernel: GPIO0 irq 08
| Sep  4 14:28:54 orion kernel: av7110: ircommand = 80000001
| Sep  4 14:28:54 orion kernel: GPIO0 irq exit 0
| Sep  4 14:28:54 orion kernel: #########80000001######### key 01
| pressed (keycode 2)

Also *no* repetition. 

If I block the infrared signal nothing happens. When I unblock the 
signal again a new down-event is generated. 

HTH

Oliver


-- 
Info:
To unsubscribe send a mail to listar@linuxtv.org with "unsubscribe linux-dvb" as subject.