Mailing List archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[linux-dvb] Re: NEWSTRUCT and Remote Control



Holger Waechtler wrote:
> Oliver Endriss wrote:
> > I 'm currently writing lirc support for /dev/input/event
> > and there is still the problem that autorepeat does not work with
> > the hauppauge remote control. Is there a chance to get this fixed?
>
> Hmm, first a question, why do you still want to use lirc? Isn't it
> easier to write a new input plugin with about 30 lines of code for
> your application? You could bypass then the lircd
> installation/configuration and would get runtime remote control
> configurability for free.

For now, I need the remote control for vdr.
It might be easier to write a plugin which feeds /dev/input/eventX into 
vdr, but I intend to use some nice features of lirc, i.e. controlling 
several applications with the same remote control.

> anyway, maybe it's always not the worst idea to have another
> compatibility wrapper layer...

The new lirc extension is just another driver compiled into lircd. 
/dev/lirc is not used! It simply takes the codes from /dev/input/eventX 
and feeds them into lircd. This way it should be possible to use any 
/dev/input/* device to control lirc. The driver itself is very short.
The hard thing is understanding the lirc source code :-)

> >>Oliver Endriss wrote:
> >>>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.
> >
> > There was *no* problem with the old firmware, because the lirc
> > driver generated autorepeat events, depending on the delay between
> > key_down and key_up events.
>
> Hmm, could you please explain this more exactly?

Ok, I'll try.
1. If I press a key on my hauppauge remote control, the *old* firmware 
emits a key-down event. When I release the key, a key-up event is 
generated.
2. lirc_dvb.c: Whenever irb_dequeue() is called it returns the last 
event received. get_key() calls irb_dequeue().
3. The /dev/lirc driver calls get_key() every X milliseconds (polling).

Together this has the nice effect that lircd gets a down-down-down-.... 
sequence as long as I hold down the key on the remote control.
When I release the key, up-up-up-... is generated, but this is simply 
ignored by lircd. 

summary:
key:       hold down      release        keypress    
firmware:  down           up             down-up
/dev/lirc: down-down-down-up-up-up-up-...down-up-up-up-up-...

> >>Hmm, the remote control I have generates an event every 1/5th
> >> second, so you still get keyrepeats.
> >
> > Obviously, the hauppauge remote control doesn't behave this way :-(
> >
> >>Maybe we have to enable the repeat
> >>option in the linux input driver for Hauppauge remote controls...
> >
> > Hmm. The problem is that new firmware doesn't send any key_up
> > events. Therefore it is not possible to do autorepeat in the driver
> > because you don't know whether the key is held down or not. With
> > the hauppauge remote control you always get just a single key_down
> > event.
>
> I will try to find out what the real problem is next days and then
> fix it. The Hauppauge keymap should become the default after bootup,
> too...

The new firmware doesn't generate up events. Therefore it is not 
possible to implement the repeat function in the driver.

key:                hold down    release        keypress    
firmware:           down                        down
/dev/input/eventX:  down-up                     down-up

> >>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.
> >
> > I see two possible solutions:
> > (a) Autorepeat in firmware for the hauppauge remote control.
> > (b) NEWSTRUCT firmware sends key_up events as the old firmware did.
> >     This way, autorepeat can be done by the (input or lirc) driver.
>
> I prefer (b), but we might have to modify the firmware in either
> case, I'm not yet sure. I definitely don't want to support
> up/down/up/down style key repeats, this would make any event
> compression impossible.
>
> > Is it possible to fix this?
>
> (I hope so:)
>
> Maybe I find some time next week, I want to write a driver for the
> ALPS DVB-T frontend used on the new Technotrend cards, too. Then
> there are some problems with VDR I have to look into and I have to
> work a little for our internal Convergence projects, too;)

Great! This is not a high priority problem, of course.

BTW, I just discovered that the 0(zero) key behaves strange :-)
key:       1  0  2  0  0  0  0 ...
firmware   1  0  2  0  -  0  - ...
The 2nd/4th/6th... 0-key is ignored ('-'). Looks like a bug in the 
keycode processing (when the special value 0x00000000 is encountered). 
There is no difference whether you use the old or new firmware.

Oliver


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



Home | Main Index | Thread Index