Control VDR with RF remote

Message ID 487908A3.8060504@o2.pl
State New
Headers

Commit Message

Artur Skawina July 12, 2008, 7:40 p.m. UTC
  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
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).

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
  

Comments

Wolfgang Fritz July 13, 2008, 8:01 a.m. UTC | #1
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
>
  
Artur Skawina July 13, 2008, 10:25 a.m. UTC | #2
Wolfgang Fritz wrote:
> Artur Skawina schrieb:
>> 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

afaict it looks exactly like the one i'm using.

>> 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.

I have at least four different types of medion remotes, each with a different
layout and features; they all work w/ the same receiver so selecting based on
usb ids won't work. I don't remember if the keymaps were incompatible though.
In any case, i'm assuming the ati remote will work w/ a medion receiver and v/v...
A per-channel module parameter is probably required.

>> +	/*
>> +	 * 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.

well, the key code changes could be used to distinguish autorepeat from a
repeated keypress, but i found the autorepeat rate to be high enough
(for a remote) and just ignore them, as above.

artur
  

Patch

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;
+	}
+
 	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