[vdr] Control VDR with RF remote

[Wolfgang Fritz]

Artur Skawina schrieb:
> Wolfgang Fritz wrote:
>> Artur Skawina schrieb:
>>> Peer Oliver Schmidt wrote:
>>>> Hello Michael,
>>>>
>>>>> Does anybody use RF remote control with VDR instead of IR? How to 
>>>>> configure such remotes?
>>>> I used the ATI RemoteWonder with it. LIRC has support for it.
>>> Or, if your remote is supported by the kernel input layer, you can use
>>> the remote plugin. eg the X10 remotes work nicely this way:
>>>
>>> $ modprobe -v ati-remote
>>> $ EV="/dev/input/"$( cd "/sys/class/input" && grep -l 'X10' event*/device/manufacturer | sed -e 's,/.*,,' )
>>> $ vdr ... -P "remote -i $EV"
>>>
>>> (some remotes such as medion need a small kernel patch in order to handle
>>> all keys and detect autorepeat properly)
>> Can you post this Kernel patch here (or send it to me via mail if it's
>> to big for the list)? I am using the Medion remote since quite a long
>> time with a patched ati-remote driver but I don't remember if I have
>> published the patch or not. And if this is not my patch, it might be
>> better than mine ;-)
> 
> sure, patch vs 2.6.25 below. These are just the minimal changes needed to make 
> ati-remote work w/ one type of medion rf remotes (P/N 20018071). i did this

Mine is P/N 20014751

> years ago, but haven't updated it since, because eventually i'll need to rewrite
> the driver to handle many remotes and map them to different input devices (each
> remote can be set to a different channel/id, but ati-remote lets you only choose
> which ones it listens to and provides a single /dev/input device for all of them).
> 
> Other items on the TODO list: 
> 
> The keymap for medion remotes is different from the one for ati, but as i'm
> currently using mine just for vdr i never needed to fix this up (vdr does its
> own mapping anyway).
> 

I have added an additional table for Medion (selected by product ID),
but this might not work if the different Medion types have the same
product ID.

> There are other types of medion rf remotes, iirc i have 3 or 4 of them, quick tests
> showed they all seem to work w/ this patch, but may need some extra quirks (mostly
> trivial keymap mods, possibly handling of scroll wheel and touchpad). (if you have
> one that doesn't work w/ this patch and can't figure out how to make it work, post
> a link identifying it, and if i have that model i'll do the necessary changes)
> 

> artur
> 
> diff --git a/drivers/input/misc/ati_remote.c b/drivers/input/misc/ati_remote.c
> index f3b86c2..38f3183 100644
> --- a/drivers/input/misc/ati_remote.c
> +++ b/drivers/input/misc/ati_remote.c
> @@ -281,6 +281,21 @@ static const struct {
>  	{KIND_FILTERED, 0xf4, 0x2F, EV_KEY, KEY_END, 1},        /* END */
>  	{KIND_FILTERED, 0xf5, 0x30, EV_KEY, KEY_SELECT, 1},     /* SELECT */
>  
> +	/* Medion-remote keys */
> +	{KIND_FILTERED, 0xf1, 0x2c, EV_KEY, KEY_TV, 1},         /* TV */
> +	{KIND_FILTERED, 0xf6, 0x31, EV_KEY, KEY_VIDEO, 1},      /* (VIDEO DESKTOP) */
> +
> +	{KIND_FILTERED, 0xf7, 0x32, EV_KEY, KEY_RED, 1},        /* <RED> */
> +	{KIND_FILTERED, 0xf8, 0x33, EV_KEY, KEY_GREEN, 1},      /* <GREEN> */
> +	{KIND_FILTERED, 0xf9, 0x34, EV_KEY, KEY_YELLOW, 1},     /* <YELLOW> */
> +	{KIND_FILTERED, 0xfa, 0x35, EV_KEY, KEY_BLUE, 1},       /* <BLUE> */
> +
> +	{KIND_FILTERED, 0xfb, 0x36, EV_KEY, KEY_MOVE, 1},       /* RENAME */
> +	{KIND_FILTERED, 0xfc, 0x37, EV_KEY, KEY_NEW, 1},        /* ACQUIRE IMAGE */
> +	{KIND_FILTERED, 0xfd, 0x38, EV_KEY, KEY_EDIT, 1},       /* EDIT */
> +	{KIND_FILTERED, 0xfe, 0x39, EV_KEY, KEY_SCREEN, 1},     /* FULL SCREEN */
> +	{KIND_FILTERED, 0xff, 0x3a, EV_KEY, KEY_AUDIO, 1},      /* DVD AUDIO */
> +
>  	{KIND_END, 0x00, 0x00, EV_MAX + 1, 0, 0}
>  };
>  
> @@ -405,6 +420,15 @@ static int ati_remote_event_lookup(int rem, unsigned char d1, unsigned char d2)
>  {
>  	int i;
>  
> +	/*
> +	 * Some remotes alternate codes, this makes it easier to detect autorepeat;
> +	 * to keep things simple we simply "undo" the code change here.
> +	 */
> +	if (d2 & 0x80) {
> +	        d1 += 0x80;
> +	        d2 -= 0x80;
> +	}
> +

Interesting. I have to check if my Medion needs this. Autorepeat is
working OK but my solution is more complicated than yours, and this
might be the reason.

>  	for (i = 0; ati_remote_tbl[i].kind != KIND_END; i++) {
>  		/*
>  		 * Decide if the table entry matches the remote input.
> @@ -524,6 +548,19 @@ static void ati_remote_input_report(struct urb *urb)
>  		ati_remote->old_data[1] = data[2];
>  		ati_remote->old_jiffies = now;
>  
> +		/*
> +		 * There apparently are two types of X10 remotes -- some (newer?) models
> +		 * change the data sent for a repeated button press, others send the same
> +		 * bytes again. The following conditional makes the latter kind work;
> +		 * w/o this it's impossible to quickly enter eg. "11" because the driver
> +		 * assumes the button is held down (is autorepeating) and generates
> +		 * "111111" -- the second button press results in five events.
> +		 * This also lowers the autorepeat rate, but as the alternative seems to
> +		 * be spurious key presses...
> +		 */
> +		if (ati_remote->repeat_count > 4)
> +			ati_remote->repeat_count = 0;
> +
>  		/* Ensure we skip at least the 4 first duplicate events (generated
>  		 * by a single keypress), and continue skipping until repeat_delay
>  		 * msecs have passed
>