[linux-dvb] Patch for DigitalNow TinyTwin remote.

[linux-dvb] Patch for DigitalNow TinyTwin remote.

[Stuart]

Hi,

First of all, thanks to those involved in getting the TinyTwin working!

I haven't found any support for the remote control yet so I would like to offer what I've managed to do so far (in case I've done something wrong as this is the first time I've tried to submit a patch).

The remote I'm referring to is pictured here (albeit with a few buttons labeled differently):

http://www.digitalnow.com.au/images/ProRemote.jpg

I extracted an ir table from the .bin file located in:

http://www.digitalnow.com.au/DNTV/TinyTwinRemote4MCE.zip
(listed at the bottom of http://www.digitalnow.com.au/downloads.html)

After changing linux/drivers/media/dvb/dvb-usb/af9015.[ch] I got a response from the remote, however, it would auto-repeat indefinitely. I believe this is caused by no "key up" event with the usbhid driver. To stop usbhid from attaching to the device I've modified a 
couple of files in the kernel. This appears to leave dvb-usb-af9015 in charge of creating events for the remote by polling (is this the correct method to go about it?).

Some keys don't work (I don't know if it's possible to get them working with a revised ir table), they're labeled on the remote as:

Tab, Capture, PIP, L/R, Recall, Zoom-, Red

The included patches apply to the following versions:

af9015: a57ea2073e77
kernel: 2.6.29_rc7

I'm not sure if this is the correct approach, however, it seems to be working for me so any feedback would be appreciated!

Stuart

af9015_tinytwin_remote_patch.diff:
--- orig/linux/drivers/media/dvb/dvb-usb/af9015.c	2009-01-24 09:23:23.000000000 +1100
+++ modified/linux/drivers/media/dvb/dvb-usb/af9015.c	2009-03-13 21:08:05.000000000 +1100
@@ -782,6 +785,16 @@ static int af9015_read_config(struct usb
 					  af9015_ir_table_twinhan;
 					af9015_config.ir_table_size =
 					  ARRAY_SIZE(af9015_ir_table_twinhan);
+				} else if (udev->descriptor.idProduct ==
+				cpu_to_le16(USB_PID_TINYTWIN)) {
+					af9015_properties[i].rc_key_map =
+					  af9015_rc_keys_tinytwin;
+					af9015_properties[i].rc_key_map_size =
+					  ARRAY_SIZE(af9015_rc_keys_tinytwin);
+					af9015_config.ir_table =
+					  af9015_ir_table_tinytwin;
+					af9015_config.ir_table_size =
+					  ARRAY_SIZE(af9015_ir_table_tinytwin);
 				}
 				break;
 			case USB_VID_KWORLD_2:
--- orig/linux/drivers/media/dvb/dvb-usb/af9015.h	2009-01-24 09:23:23.000000000 +1100
+++ modified/linux/drivers/media/dvb/dvb-usb/af9015.h	2009-03-13 21:08:05.000000000 +1100
@@ -127,6 +127,105 @@ enum af9015_remote {
 	AF9015_REMOTE_AVERMEDIA_KS,
 };
 
+/* Tiny Twin */
+static struct dvb_usb_rc_key af9015_rc_keys_tinytwin[] = {
+	{0x00, 0x1e, KEY_1},			/* 1 */
+	{0x00, 0x1f, KEY_2},			/* 2 */
+	{0x00, 0x20, KEY_3},			/* 3 */
+	{0x00, 0x21, KEY_4},			/* 4 */
+	{0x00, 0x22, KEY_5},			/* 5 */
+	{0x00, 0x23, KEY_6},			/* 6 */
+	{0x00, 0x24, KEY_7},			/* 7 */
+	{0x00, 0x25, KEY_8},			/* 8 */
+	{0x00, 0x26, KEY_9},			/* 9 */
+	{0x00, 0x27, KEY_0},			/* 0 */
+	{0x00, 0x28, KEY_ENTER},		/* Enter/ok */
+	{0x00, 0x29, KEY_CANCEL},		/* Cancel */
+	{0x00, 0x2a, KEY_BACK},			/* Back */
+	{0x00, 0x41, KEY_MUTE},			/* Mute */
+	{0x00, 0x42, KEY_VOLUMEDOWN},		/* VOL- */
+	{0x00, 0x43, KEY_VOLUMEUP},		/* VOL+ */
+	{0x00, 0x4b, KEY_CHANNELUP},		/* CH+ */
+	{0x00, 0x4c, KEY_CLEAR},		/* Clear */
+	{0x00, 0x4e, KEY_CHANNELDOWN},		/* CH- */
+	{0x00, 0x4f, KEY_RIGHT},		/* Right */
+	{0x00, 0x50, KEY_LEFT},			/* Left */
+	{0x00, 0x51, KEY_DOWN},			/* Down */
+	{0x00, 0x52, KEY_UP},			/* Up */
+	{0x01, 0x04, KEY_INFO},			/* Preview */
+	{0x01, 0x05, KEY_PREVIOUS},		/* Replay */
+	{0x01, 0x07, KEY_EPG},			/* Info/EPG */
+	{0x01, 0x08, KEY_BLUE},			/* Blue */
+	{0x01, 0x09, KEY_NEXT},			/* Skip */
+	{0x01, 0x0a, KEY_FAVORITES},		/* Favourites */
+	{0x01, 0x0c, KEY_YELLOW},		/* Yellow */
+	{0x01, 0x10, KEY_GREEN},		/* Green */
+	{0x01, 0x12, KEY_LIST},			/* Record List */
+	{0x01, 0x13, KEY_PAUSE},		/* Pause */
+	{0x01, 0x15, KEY_RECORD},		/* REC */
+	{0x01, 0x17, KEY_TEXT},			/* Teletext */
+	{0x03, 0x04, KEY_LANGUAGE},		/* SAP */
+	{0x03, 0x05, KEY_REWIND},		/* FR */
+	{0x03, 0x06, KEY_SUBTITLE},		/* Subtitle/CC */
+	{0x03, 0x09, KEY_FASTFORWARD},		/* FF */
+	{0x03, 0x13, KEY_PLAY},			/* Play */
+	{0x03, 0x16, KEY_STOP},			/* Stop */
+	{0x03, 0x17, KEY_SWITCHVIDEOMODE},	/* A/V */
+	{0x03, 0x1d, KEY_ZOOMIN},		/* Zoom+ */
+	{0x04, 0x28, KEY_ZOOM},			/* Full Screen */
+	{0x04, 0x3d, KEY_SLEEP},		/* Hibernate */
+	{0x0c, 0x28, KEY_POWER},		/* Power */
+};
+
+static u8 af9015_ir_table_tinytwin[] = {
+	0x00, 0xff, 0x16, 0xe9, 0x28, 0x0c, 0x00, /* Power */
+	0x00, 0xff, 0x17, 0xe8, 0x0a, 0x01, 0x00, /* Favourites */
+	0x00, 0xff, 0x1c, 0xe3, 0x07, 0x01, 0x00, /* Info/EPG */
+	0x00, 0xff, 0x04, 0xfb, 0x12, 0x01, 0x00, /* Record List */
+	0x00, 0xff, 0x03, 0xfc, 0x1e, 0x00, 0x00, /* 1 */
+	0x00, 0xff, 0x01, 0xfe, 0x1f, 0x00, 0x00, /* 2 */
+	0x00, 0xff, 0x06, 0xf9, 0x20, 0x00, 0x00, /* 3 */
+	0x00, 0xff, 0x09, 0xf6, 0x21, 0x00, 0x00, /* 4 */
+	0x00, 0xff, 0x1d, 0xe2, 0x22, 0x00, 0x00, /* 5 */
+	0x00, 0xff, 0x1f, 0xe0, 0x23, 0x00, 0x00, /* 6 */
+	0x00, 0xff, 0x0d, 0xf2, 0x24, 0x00, 0x00, /* 7 */
+	0x00, 0xff, 0x19, 0xe6, 0x25, 0x00, 0x00, /* 8 */
+	0x00, 0xff, 0x1b, 0xe4, 0x26, 0x00, 0x00, /* 9 */
+	0x00, 0xff, 0x0c, 0xf3, 0x29, 0x00, 0x00, /* Cancel */
+	0x00, 0xff, 0x15, 0xea, 0x27, 0x00, 0x00, /* 0 */
+	0x00, 0xff, 0x4a, 0xb5, 0x4c, 0x00, 0x00, /* Clear */
+	0x00, 0xff, 0x13, 0xec, 0x2a, 0x00, 0x00, /* Back */
+	0x00, 0xff, 0x4b, 0xb4, 0x52, 0x00, 0x00, /* Up */
+	0x00, 0xff, 0x4e, 0xb1, 0x50, 0x00, 0x00, /* Left */
+	0x00, 0xff, 0x4f, 0xb0, 0x28, 0x00, 0x00, /* Enter/ok */
+	0x00, 0xff, 0x52, 0xad, 0x4f, 0x00, 0x00, /* Right */
+	0x00, 0xff, 0x51, 0xae, 0x51, 0x00, 0x00, /* Down */
+	0x00, 0xff, 0x1e, 0xe1, 0x43, 0x00, 0x00, /* VOL+ */
+	0x00, 0xff, 0x0a, 0xf5, 0x42, 0x00, 0x00, /* VOL- */
+	0x00, 0xff, 0x02, 0xfd, 0x4e, 0x00, 0x00, /* CH- */
+	0x00, 0xff, 0x05, 0xfa, 0x4b, 0x00, 0x00, /* CH+ */
+	0x00, 0xff, 0x11, 0xee, 0x15, 0x01, 0x00, /* REC */
+	0x00, 0xff, 0x14, 0xeb, 0x13, 0x03, 0x00, /* Play */
+	0x00, 0xff, 0x4c, 0xb3, 0x13, 0x01, 0x00, /* Pause */
+	0x00, 0xff, 0x1a, 0xe5, 0x16, 0x03, 0x00, /* Stop */
+	0x00, 0xff, 0x40, 0xbf, 0x05, 0x03, 0x00, /* FR */
+	0x00, 0xff, 0x12, 0xed, 0x09, 0x03, 0x00, /* FF */
+	0x00, 0xff, 0x41, 0xbe, 0x05, 0x01, 0x00, /* Replay */
+	0x00, 0xff, 0x42, 0xbd, 0x09, 0x01, 0x00, /* Skip */
+	0x00, 0xff, 0x50, 0xaf, 0x04, 0x03, 0x00, /* SAP */
+	0x00, 0xff, 0x4d, 0xb2, 0x28, 0x04, 0x00, /* Full Screen */
+	0x00, 0xff, 0x10, 0xef, 0x41, 0x00, 0x00, /* Mute */
+	0x00, 0xff, 0x43, 0xbc, 0x06, 0x03, 0x00, /* Subtitle/CC */
+	0x00, 0xff, 0x45, 0xba, 0x1d, 0x03, 0x00, /* Zoom+ */
+	0x00, 0xff, 0x0f, 0xf0, 0x17, 0x01, 0x00, /* Teletext */
+	0x00, 0xff, 0x08, 0xf7, 0x17, 0x03, 0x00, /* A/V */
+	0x00, 0xff, 0x53, 0xac, 0x10, 0x01, 0x00, /* Green */
+	0x00, 0xff, 0x5f, 0xa0, 0x08, 0x01, 0x00, /* Blue */
+	0x00, 0xff, 0x5e, 0xa1, 0x0c, 0x01, 0x00, /* Yellow */
+	0x00, 0xff, 0x48, 0xb7, 0x04, 0x01, 0x00, /* Preview */
+	0x00, 0xff, 0x07, 0xf8, 0x3d, 0x04, 0x00, /* Hibernate */
+};
+
 /* Leadtek WinFast DTV Dongle Gold */
 static struct dvb_usb_rc_key af9015_rc_keys_leadtek[] = {
 	{ 0x00, 0x1e, KEY_1 },

kernel-2.6.29_rc7_tinytwin_remote_patch.diff:
--- orig/drivers/hid/hid-ids.h	2009-03-13 22:50:05.000000000 +1100
+++ modified/drivers/hid/hid-ids.h	2009-03-13 22:52:10.000000000 +1100
@@ -420,4 +420,7 @@
 #define USB_VENDOR_ID_KYE		0x0458
 #define USB_DEVICE_ID_KYE_GPEN_560	0x5003
 
+#define USB_VENDOR_ID_DIGITALNOW	0x13d3
+#define USB_DEVICE_ID_DIGITALNOW_TINYTWIN	0x3226
+
 #endif
--- orig/drivers/hid/hid-core.c	2009-03-13 22:50:05.000000000 +1100
+++ modified/drivers/hid/hid-core.c	2009-03-13 22:52:47.000000000 +1100
@@ -1629,6 +1629,7 @@ static const struct hid_device_id hid_ig
 	{ HID_USB_DEVICE(USB_VENDOR_ID_WISEGROUP, USB_DEVICE_ID_1_PHIDGETSERVO_20) },
 	{ HID_USB_DEVICE(USB_VENDOR_ID_WISEGROUP, USB_DEVICE_ID_8_8_4_IF_KIT) },
 	{ HID_USB_DEVICE(USB_VENDOR_ID_YEALINK, USB_DEVICE_ID_YEALINK_P1K_P4K_B2K) },
+	{ HID_USB_DEVICE(USB_VENDOR_ID_DIGITALNOW, USB_DEVICE_ID_DIGITALNOW_TINYTWIN) },
 	{ }
 };
 



_______________________________________________
linux-dvb users mailing list
For V4L/DVB development, please use instead linux-media@vger.kernel.org
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] Patch for DigitalNow TinyTwin remote.

[Antti Palosaari]

hei Stuart,

Stuart wrote:
> First of all, thanks to those involved in getting the TinyTwin working!
> 
> I haven't found any support for the remote control yet so I would like to offer what I've managed to do so far (in case I've done something wrong as this is the first time I've tried to submit a patch).
> 
> The remote I'm referring to is pictured here (albeit with a few buttons labeled differently):
> 
> http://www.digitalnow.com.au/images/ProRemote.jpg

Same remote as TwinHan AzureWave AD-TU700(704J).
This is just same device as AzureWave.

> I extracted an ir table from the .bin file located in:
> 
> http://www.digitalnow.com.au/DNTV/TinyTwinRemote4MCE.zip
> (listed at the bottom of http://www.digitalnow.com.au/downloads.html)
> 
> After changing linux/drivers/media/dvb/dvb-usb/af9015.[ch] I got a response from the remote, however, it would auto-repeat indefinitely. I believe this is caused by no "key up" event with the usbhid driver. To stop usbhid from attaching to the device I've modified a 
> couple of files in the kernel. This appears to leave dvb-usb-af9015 in charge of creating events for the remote by polling (is this the correct method to go about it?).

Someone should really examine that more. Take some sniffs to see how 
Windows handle that.
http://www.linuxtv.org/pipermail/linux-dvb/2008-November/030292.html
http://linuxtv.org/wiki/index.php/MSI_DigiVox_mini_II_V3.0

> Some keys don't work (I don't know if it's possible to get them working with a revised ir table), they're labeled on the remote as:
> 
> Tab, Capture, PIP, L/R, Recall, Zoom-, Red
> 
> The included patches apply to the following versions:
> 
> af9015: a57ea2073e77
> kernel: 2.6.29_rc7
> 
> I'm not sure if this is the correct approach, however, it seems to be working for me so any feedback would be appreciated!

I am also not sure about HID changes.
And also could you test whether AzureWave IR-tables are OK because 
device looks just same, even remote.

regards
Antti
-- 
http://palosaari.fi/

Re: [linux-dvb] Patch for DigitalNow TinyTwin remote.

[Stuart]

Hi Antti,

> Someone should really examine that more. Take some sniffs to see how
> Windows handle that.
> http://www.linuxtv.org/pipermail/linux-dvb/2008-November/030292.html
> http://linuxtv.org/wiki/index.php/MSI_DigiVox_mini_II_V3.0

I had a look at the links, the problem I had did not stop after pressing a key on the keyboard. Also, with this kernel (2.6.29_rc7) using 'options usbhid quirks=0x13d3:0x3226:0x0004' had no effect, I believe there have been some changes to usbhid in 2.6.28, either way 
the old macro '#define HID_QUIRK_IGNORE 0x00000004' is not in hid.h in this kernel version. The only way to stop it was to unplug the device. (Trying to type rmmod was impossible as the input from the remote would keep coming!)

I'd be happy to have a look in to usb sniffing, are there any decent tutorials on how to do this?

> I am also not sure about HID changes.
> And also could you test whether AzureWave IR-tables are OK because
> device looks just same, even remote.

You're absolutely right! The TinyTwin worked with the AzureWave tables (af9015_rc_keys_twinhan and af9015_ir_table_twinhan).

I can see in af9015.h there is an ir table (af9015_ir_table_twinhan) with 50 entries, a key table (af9015_rc_keys_twinhan) with 53 entries and that while the remote has 53 keys, the device can only handle 50 of them (the first 50 in the ir table if > 50). I've also 
found two ir tables from Windows drivers (one from the supplied CD and the one I previously mentioned for Windows MCE). This is an example entry in an ir table:

 1  ,  2  ,  3  ,  4  ,  5  ,  6  ,  7
0x00, 0xff, 0x16, 0xe9, 0x28, 0x0c, 0x00

I'm assuming columns 3 & 4 correspond to the key pressed and columns 5 & 6 correspond to the code returned when that key is pressed. In all tables, 3 & 4 are the same while 5 & 6 are sometimes different. I'm assuming that 5 & 6 are important if usbhid attaches itself 
to the device, however, if dvb_usb_af9015 attaches itself then they seem somewhat arbitrary as the key table only needs to match the ir table to get the correct key press from af9015_rc_query.

I wrote a simple programme to look at all the ir and key tables. Looking at af9015_rc_keys_twinhan and af9015_ir_table_twinhan in af9015.h shows there is no entry in af9015_ir_table_twinhan for A/V, Zoom+ or Zoom- and there are two entries with '0x00, 0x0e' 
corresponding to KEY_POWER and KEY_INFO (I believe the entry '{ 0x00, 0x0e, KEY_POWER }' should be '{ 0x00, 0x4d, KEY_STOP }') in af9015_rc_keys_twinhan.

I'm not sure if columns 5 & 6 need to be specific values, but I've attached a complete list (53 ir table entries and 53 corresponding key table entries). Of course, we can only use 50 of them at a time!

Also, how does the AzureWave handle the remote? Does it use the usbhid driver or dvb_usb_af9015? If it uses dvb_usb_af9015, then I think the TinyTwin should use it as well and it would be necessary to stop usbhid from attaching to the device.

Regards,

Stuart

Complete key & ir tables:

	{ 0x0c, 0x28, KEY_POWER },		/* Power */
	{ 0x01, 0x0a, KEY_FAVORITES },		/* Favorite List */
	{ 0x01, 0x17, KEY_TEXT },		/* Teletext */
	{ 0x01, 0x04, KEY_INFO },		/* Preview */
	{ 0x01, 0x07, KEY_EPG },		/* Info/EPG */
	{ 0x01, 0x12, KEY_LIST },		/* Record List */
	{ 0x00, 0x1e, KEY_1 },			/* 1 */
	{ 0x00, 0x1f, KEY_2 },			/* 2 */
	{ 0x00, 0x20, KEY_3 },			/* 3 */
	{ 0x00, 0x21, KEY_4 },			/* 4 */
	{ 0x00, 0x22, KEY_5 },			/* 5 */
	{ 0x00, 0x23, KEY_6 },			/* 6 */
	{ 0x00, 0x24, KEY_7 },			/* 7 */
	{ 0x00, 0x25, KEY_8 },			/* 8 */
	{ 0x00, 0x26, KEY_9 },			/* 9 */
	{ 0x00, 0x29, KEY_CANCEL },		/* Cancel */
	{ 0x00, 0x27, KEY_0 },			/* 0 */
	{ 0x00, 0x4c, KEY_CLEAR },		/* Clear */
	{ 0x00, 0x2a, KEY_BACK },		/* Back */
	{ 0x00, 0x2b, KEY_TAB },		/* Tab */
	{ 0x00, 0x52, KEY_UP },			/* Up */
	{ 0x00, 0x50, KEY_LEFT },		/* Left */
	{ 0x00, 0x28, KEY_ENTER },		/* Enter/ok */
	{ 0x00, 0x4f, KEY_RIGHT },		/* Right */
	{ 0x00, 0x51, KEY_DOWN },		/* Down */
	{ 0x00, 0x43, KEY_VOLUMEUP },		/* VOL+ */
	{ 0x00, 0x42, KEY_VOLUMEDOWN },		/* VOL- */
	{ 0x00, 0x4e, KEY_CHANNELUP },		/* CH- */
	{ 0x00, 0x4b, KEY_CHANNELDOWN },	/* CH+ */
	{ 0x01, 0x15, KEY_RECORD },		/* REC */
	{ 0x03, 0x13, KEY_PLAY },		/* Play */
	{ 0x01, 0x13, KEY_PAUSE },		/* Pause */
	{ 0x03, 0x16, KEY_STOP },		/* Stop */
	{ 0x03, 0x05, KEY_REWIND },		/* FR */
	{ 0x03, 0x09, KEY_FASTFORWARD },	/* FF */
	{ 0x01, 0x05, KEY_PREVIOUS },		/* Replay */
	{ 0x01, 0x09, KEY_NEXT },		/* Skip */
	{ 0x00, 0x40, KEY_CAMERA },		/* Capture */
	{ 0x03, 0x04, KEY_LANGUAGE },		/* SAP */
	{ 0x00, 0x3f, KEY_TV2 },		/* PIP */
	{ 0x04, 0x28, KEY_ZOOM },		/* Full Screen */
	{ 0x03, 0x06, KEY_SUBTITLE },		/* Subtitle/CC */
	{ 0x00, 0x41, KEY_MUTE },		/* Mute */
	{ 0x01, 0x41, KEY_AUDIO },		/* L/R */
	{ 0x04, 0x3d, KEY_SLEEP },		/* Hibernate */
	{ 0x03, 0x17, KEY_SWITCHVIDEOMODE },	/* A/V */
	{ 0x05, 0x1a, KEY_AGAIN },		/* Recall */
	{ 0x03, 0x1d, KEY_ZOOMIN },		/* Zoom+ */
	{ 0x03, 0x1f, KEY_ZOOMOUT },		/* Zoom- */
	{ 0x01, 0x14, KEY_RED },		/* Red */
	{ 0x01, 0x10, KEY_GREEN },		/* Green */
	{ 0x01, 0x0c, KEY_YELLOW },		/* Yellow */
	{ 0x01, 0x08, KEY_BLUE },		/* Blue */

	0x00, 0xff, 0x16, 0xe9, 0x28, 0x0c, 0x00, /* Power */
	0x00, 0xff, 0x17, 0xe8, 0x0a, 0x01, 0x00, /* Favorite List */
	0x00, 0xff, 0x0f, 0xf0, 0x17, 0x01, 0x00, /* Teletext */
	0x00, 0xff, 0x48, 0xb7, 0x04, 0x01, 0x00, /* Preview */
	0x00, 0xff, 0x1c, 0xe3, 0x07, 0x01, 0x00, /* Info/EPG */
	0x00, 0xff, 0x04, 0xfb, 0x12, 0x01, 0x00, /* Record List */
	0x00, 0xff, 0x03, 0xfc, 0x1e, 0x00, 0x00, /* 1 */
	0x00, 0xff, 0x01, 0xfe, 0x1f, 0x00, 0x00, /* 2 */
	0x00, 0xff, 0x06, 0xf9, 0x20, 0x00, 0x00, /* 3 */
	0x00, 0xff, 0x09, 0xf6, 0x21, 0x00, 0x00, /* 4 */
	0x00, 0xff, 0x1d, 0xe2, 0x22, 0x00, 0x00, /* 5 */
	0x00, 0xff, 0x1f, 0xe0, 0x23, 0x00, 0x00, /* 6 */
	0x00, 0xff, 0x0d, 0xf2, 0x24, 0x00, 0x00, /* 7 */
	0x00, 0xff, 0x19, 0xe6, 0x25, 0x00, 0x00, /* 8 */
	0x00, 0xff, 0x1b, 0xe4, 0x26, 0x00, 0x00, /* 9 */
	0x00, 0xff, 0x0c, 0xf3, 0x29, 0x00, 0x00, /* Cancel */
	0x00, 0xff, 0x15, 0xea, 0x27, 0x00, 0x00, /* 0 */
	0x00, 0xff, 0x4a, 0xb5, 0x4c, 0x00, 0x00, /* Clear */
	0x00, 0xff, 0x13, 0xec, 0x2a, 0x00, 0x00, /* Back */
	0x00, 0xff, 0x00, 0xff, 0x2b, 0x00, 0x00, /* Tab */
	0x00, 0xff, 0x4b, 0xb4, 0x52, 0x00, 0x00, /* Up */
	0x00, 0xff, 0x4e, 0xb1, 0x50, 0x00, 0x00, /* Left */
	0x00, 0xff, 0x4f, 0xb0, 0x28, 0x00, 0x00, /* Enter/ok */
	0x00, 0xff, 0x52, 0xad, 0x4f, 0x00, 0x00, /* Right */
	0x00, 0xff, 0x51, 0xae, 0x51, 0x00, 0x00, /* Down */
	0x00, 0xff, 0x1e, 0xe1, 0x43, 0x00, 0x00, /* VOL+ */
	0x00, 0xff, 0x0a, 0xf5, 0x42, 0x00, 0x00, /* VOL- */
	0x00, 0xff, 0x02, 0xfd, 0x4e, 0x00, 0x00, /* CH- */
	0x00, 0xff, 0x05, 0xfa, 0x4b, 0x00, 0x00, /* CH+ */
	0x00, 0xff, 0x11, 0xee, 0x15, 0x01, 0x00, /* REC */
	0x00, 0xff, 0x14, 0xeb, 0x13, 0x03, 0x00, /* Play */
	0x00, 0xff, 0x4c, 0xb3, 0x13, 0x01, 0x00, /* Pause */
	0x00, 0xff, 0x1a, 0xe5, 0x16, 0x03, 0x00, /* Stop */
	0x00, 0xff, 0x40, 0xbf, 0x05, 0x03, 0x00, /* FR */
	0x00, 0xff, 0x12, 0xed, 0x09, 0x03, 0x00, /* FF */
	0x00, 0xff, 0x41, 0xbe, 0x05, 0x01, 0x00, /* Replay */
	0x00, 0xff, 0x42, 0xbd, 0x09, 0x01, 0x00, /* Skip */
	0x00, 0xff, 0x54, 0xab, 0x40, 0x00, 0x00, /* Capture */
	0x00, 0xff, 0x50, 0xaf, 0x04, 0x03, 0x00, /* SAP */
	0x00, 0xff, 0x47, 0xb8, 0x3f, 0x00, 0x00, /* PIP */
	0x00, 0xff, 0x4d, 0xb2, 0x28, 0x04, 0x00, /* Full Screem */
	0x00, 0xff, 0x43, 0xbc, 0x06, 0x03, 0x00, /* Subtitle/CC */
	0x00, 0xff, 0x10, 0xef, 0x41, 0x00, 0x00, /* Mute */
	0x00, 0xff, 0x49, 0xb6, 0x41, 0x01, 0x00, /* L/R */
	0x00, 0xff, 0x07, 0xf8, 0x3d, 0x04, 0x00, /* Hibernate */
	0x00, 0xff, 0x08, 0xf7, 0x17, 0x03, 0x00, /* A/V */
	0x00, 0xff, 0x0e, 0xf1, 0x1a, 0x05, 0x00, /* Recall */
	0x00, 0xff, 0x45, 0xba, 0x1d, 0x03, 0x00, /* Zoom+ */
	0x00, 0xff, 0x46, 0xb9, 0x1f, 0x03, 0x00, /* Zoom- */
	0x00, 0xff, 0x18, 0xe7, 0x14, 0x01, 0x00, /* Red */
	0x00, 0xff, 0x53, 0xac, 0x10, 0x01, 0x00, /* Green */
	0x00, 0xff, 0x5e, 0xa1, 0x0c, 0x01, 0x00, /* Yellow */
	0x00, 0xff, 0x5f, 0xa0, 0x08, 0x01, 0x00, /* Blue */


_______________________________________________
linux-dvb users mailing list
For V4L/DVB development, please use instead linux-media@vger.kernel.org
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] Patch for DigitalNow TinyTwin remote.

[Antti Palosaari]

Hei Stuart,
I would like to thank you!

>> Someone should really examine that more. Take some sniffs to see how
>> Windows handle that.
>> http://www.linuxtv.org/pipermail/linux-dvb/2008-November/030292.html
>> http://linuxtv.org/wiki/index.php/MSI_DigiVox_mini_II_V3.0
> 
> I had a look at the links, the problem I had did not stop after pressing a key on the keyboard. Also, with this kernel (2.6.29_rc7) using 'options usbhid quirks=0x13d3:0x3226:0x0004' had no effect, I believe there have been some changes to usbhid in 2.6.28, either way 
> the old macro '#define HID_QUIRK_IGNORE 0x00000004' is not in hid.h in this kernel version. The only way to stop it was to unplug the device. (Trying to type rmmod was impossible as the input from the remote would keep coming!)
> 
> I'd be happy to have a look in to usb sniffing, are there any decent tutorials on how to do this?

take sniff:
http://www.pcausa.com/Utilities/UsbSnoop/default.htm
use parser to sniff:
v4l2-apps/util/parse-sniffusb2.pl

and try to look parsed log. You can see USB-protocol rather easily by 
comparing driver code and sniff.

>> I am also not sure about HID changes.
>> And also could you test whether AzureWave IR-tables are OK because
>> device looks just same, even remote.
> 
> You're absolutely right! The TinyTwin worked with the AzureWave tables (af9015_rc_keys_twinhan and af9015_ir_table_twinhan).
> 
> I can see in af9015.h there is an ir table (af9015_ir_table_twinhan) with 50 entries, a key table (af9015_rc_keys_twinhan) with 53 entries and that while the remote has 53 keys, the device can only handle 50 of them (the first 50 in the ir table if > 50). I've also 
> found two ir tables from Windows drivers (one from the supplied CD and the one I previously mentioned for Windows MCE). This is an example entry in an ir table:

you are correct, 50 entries is max size.

>  1  ,  2  ,  3  ,  4  ,  5  ,  6  ,  7
> 0x00, 0xff, 0x16, 0xe9, 0x28, 0x0c, 0x00
> 
> I'm assuming columns 3 & 4 correspond to the key pressed and columns 5 & 6 correspond to the code returned when that key is pressed. In all tables, 3 & 4 are the same while 5 & 6 are sometimes different. I'm assuming that 5 & 6 are important if usbhid attaches itself 
> to the device, however, if dvb_usb_af9015 attaches itself then they seem somewhat arbitrary as the key table only needs to match the ir table to get the correct key press from af9015_rc_query.

bytes 1-4 are remote code, 1 & 2 is like device address and 3 & 4 
contains key code. Last 3 bytes are some data returned by chip, HID / 
key code.
http://www.sbprojects.com/knowledge/ir/rc6.htm
http://www.sbprojects.com/knowledge/ir/nec.htm

> I wrote a simple programme to look at all the ir and key tables. Looking at af9015_rc_keys_twinhan and af9015_ir_table_twinhan in af9015.h shows there is no entry in af9015_ir_table_twinhan for A/V, Zoom+ or Zoom- and there are two entries with '0x00, 0x0e' 
> corresponding to KEY_POWER and KEY_INFO (I believe the entry '{ 0x00, 0x0e, KEY_POWER }' should be '{ 0x00, 0x4d, KEY_STOP }') in af9015_rc_keys_twinhan.
> 
> I'm not sure if columns 5 & 6 need to be specific values, but I've attached a complete list (53 ir table entries and 53 corresponding key table entries). Of course, we can only use 50 of them at a time!
> 
> Also, how does the AzureWave handle the remote? Does it use the usbhid driver or dvb_usb_af9015? If it uses dvb_usb_af9015, then I think the TinyTwin should use it as well and it would be necessary to stop usbhid from attaching to the device.

When I added remote support the reason I used polling was that I didn't 
get HID working. I don't know why. And I haven't even sniffed how 
Windows driver handles that - only uploaded ir-table to the device as 
seen from sniffs.

Could you make patch that adds AzureWave remote to the TinyTwin? 2.6.30 
merge windows is now open. I will try to examine this remote issue 
during weekend. Use this tree http://linuxtv.org/hg/~anttip/af9015/

regards
Antti
-- 
http://palosaari.fi/

Re: [linux-dvb] Patch for DigitalNow TinyTwin remote.

[Stuart]

Hi Antti,

> Could you make patch asap to get support for remote?

I'm still working on why the remote doesn't work with usbhid. I've included two 
patches, one applies to af9015 (b0ba0a6dfca1) and the other to kernel 2.6.29 (to 
stop HID from claiming the device and repeating key presses) which will allow 
the remote to work as the AzureWave remote through polling. I haven't fixed up 
the ir/key tables in af9015.h yet.

> take sniff:
> http://www.pcausa.com/Utilities/UsbSnoop/default.htm
> use parser to sniff:
> v4l2-apps/util/parse-sniffusb2.pl
> and try to look parsed log. You can see USB-protocol rather easily by 
> comparing driver code and sniff.

I've taken some usb sniffs, unfortunately parse-sniffusb2.pl didn't give any 
output (so I'm not sure what it should look like) but here's a snippet from 
the remote when pressing '1':

[369218 ms]  <<<  URB 13 coming back  <<<
    00000000: 00 00 1e 00 00 00 00 00
[369218 ms]  >>>  URB 15 going down  >>>
[369218 ms]  <<<  URB 14 coming back  <<<
    00000000: 00 00 1e 00 00 00 00 00
[369218 ms]  >>>  URB 16 going down  >>>
[369308 ms]  <<<  URB 15 coming back  <<<
    00000000: 00 00 00 00 00 00 00 00
[369308 ms]  >>>  URB 17 going down  >>>

>From a usb keyboard I get this:

[16732 ms]  <<<  URB 7 coming back  <<<
    00000000: 00 00 1e 00 00 00 00 00
[16732 ms]  >>>  URB 10 going down  >>>
[16820 ms]  <<<  URB 8 coming back  <<<
    00000000: 00 00 00 00 00 00 00 00
[16820 ms]  >>>  URB 11 going down  >>>

Obviously the incoming URB with '1e' is a key press corresponding to '1' and the 
incoming URB with all '00' is a key release.

> I haven't looked repeating issue yet... and it even does not rise up in
> my Linux box. Don't know why. I have Fedora 10 x86_64 2.7.27.

I've been looking in to this and the further I look the more complicated it 
seems to become!

Using usbmon/debugfs I can see the same behaviour in Windows/Linux for the usb 
keyboard, the remote on the other hand has a lot of traffic from the polling and 
only showed packets corresponding to key presses (no key releases in Linux).

It seems that when a key is pressed on either the keyboard or the remote at some 
point 'hid_irq_in' is called in drivers/hid/usbhid/hid-core.c which in turn 
calls 'hid_input_report' from drivers/hid/hid-core.c which calls 
'hid_report_raw_event' in the same file, this in turn calls the various drivers 
that have claimed the device (input, dev, raw).

If I add the TinyTwin device to hid_blacklist in drivers/hid/hid-core.c and 
write a driver providing a function for raw_event so it is called instead of 
'hid_report_raw_event' I can provide a 'fake' key release which to a degree 
worked, only I would see the keys pressed twice because the af9015 driver 
still generated events as well.

If I disable polling with:

echo "1" > /sys/module/dvb_usb/parameters/disable_rc_polling

I find that pressing a key on the remote generates a key press and then ~17.5 
seconds later the remote generates a key release. Any key presses (pressing any 
key on the remote) before the key release generates another key press for the 
first key, not the one actually pressed!

So far I've found a minor difference between the two firmware sent to the device 
and I'm going through usb sniffs to see what it does under Windows to see if 
this has any effect on the remote....

Regards,

Stuart

af9015-b0ba0a6dfca1_tinytwin_remote.patch:
--- orig/drivers/media/dvb/dvb-usb/af9015.c	2009-03-31 07:57:51.000000000 +1100
+++ new/drivers/media/dvb/dvb-usb/af9015.c	2009-03-31 11:44:16.000000000 +1100
@@ -785,17 +785,14 @@ static int af9015_read_config(struct usb
 				  ARRAY_SIZE(af9015_ir_table_leadtek);
 				break;
 			case USB_VID_VISIONPLUS:
-				if (udev->descriptor.idProduct ==
-				cpu_to_le16(USB_PID_AZUREWAVE_AD_TU700)) {
-					af9015_properties[i].rc_key_map =
-					  af9015_rc_keys_twinhan;
-					af9015_properties[i].rc_key_map_size =
-					  ARRAY_SIZE(af9015_rc_keys_twinhan);
-					af9015_config.ir_table =
-					  af9015_ir_table_twinhan;
-					af9015_config.ir_table_size =
-					  ARRAY_SIZE(af9015_ir_table_twinhan);
-				}
+				af9015_properties[i].rc_key_map =
+				  af9015_rc_keys_twinhan;
+				af9015_properties[i].rc_key_map_size =
+				  ARRAY_SIZE(af9015_rc_keys_twinhan);
+				af9015_config.ir_table =
+				  af9015_ir_table_twinhan;
+				af9015_config.ir_table_size =
+				  ARRAY_SIZE(af9015_ir_table_twinhan);
 				break;
 			case USB_VID_KWORLD_2:
 				/* TODO: use correct rc keys */

kernel-2.6.29_tinytwin_remote_patch.diff:
--- orig/drivers/hid/hid-core.c	2009-03-24 10:12:14.000000000 +1100
+++ new/drivers/hid/hid-core.c	2009-03-31 15:08:13.000000000 +1100
@@ -1629,6 +1629,7 @@ static const struct hid_device_id hid_ig
 	{ HID_USB_DEVICE(USB_VENDOR_ID_WISEGROUP, USB_DEVICE_ID_1_PHIDGETSERVO_20) },
 	{ HID_USB_DEVICE(USB_VENDOR_ID_WISEGROUP, USB_DEVICE_ID_8_8_4_IF_KIT) },
 	{ HID_USB_DEVICE(USB_VENDOR_ID_YEALINK, USB_DEVICE_ID_YEALINK_P1K_P4K_B2K) },
+	{ HID_USB_DEVICE(USB_VENDOR_ID_DIGITALNOW, USB_DEVICE_ID_DIGITALNOW_TINYTWIN) 
},
 	{ }
 };
 
--- orig/drivers/hid/hid-ids.h	2009-03-24 10:12:14.000000000 +1100
+++ new/drivers/hid/hid-ids.h	2009-03-31 15:09:05.000000000 +1100
@@ -420,4 +420,7 @@
 #define USB_VENDOR_ID_KYE		0x0458
 #define USB_DEVICE_ID_KYE_GPEN_560	0x5003
 
+#define USB_VENDOR_ID_DIGITALNOW	0x13d3
+#define USB_DEVICE_ID_DIGITALNOW_TINYTWIN	0x3226
+
 #endif



_______________________________________________
linux-dvb users mailing list
For V4L/DVB development, please use instead linux-media@vger.kernel.org
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] Patch for DigitalNow TinyTwin remote.

[Stuart]

> But the reason I pressure you is that merge window for 2.6.30 is open
> only few days. After that we cannot put new code / functionality until
> 2.6.31 opens and it is very many months from that day.
>
> 1.) I suggest that you make very small patch adding basic support for
> TinyTwin remote (mainly add device IDs to same places as TwinHan).

There are two patches in my last email which I believe achieve this. One simply 
removes the if statement so that the AzureWave IR tables are assigned for the 
TinyTwin. The other adds the TinyTwin to the HID ignore list so that there are 
no repeat key presses. I've included them at the end of this email as well.

> 2.) Make other patch *later* that fix repeating issue. This one can be
> added to the  2.6.30 later (there many release candidates in next
> months) as bug fix.

I've been looking through usb sniffs when plugging the TinyTwin in and can't see 
much that's different. There's a slight difference in the first 4 bytes of each 
packet sent for the firmware, for example the first packet for each:

Linux:   00 51 00 00
Windows: 38 51 00 c0

The IR table download is also sent slightly differently, in Linux it's:

21 .. 00 9a 56 00 00 01 00

from

struct req_t req = {WRITE_MEMORY, 0, 0, 0, 0, 1, NULL};
req.addr = 0x9a56

While Windows is:

21 .. 38 9a 56 4e 80 01 00

which would be

struct req_t req = {WRITE_MEMORY, AF9015_I2C_DEMOD, 0, 4e, 80, 1, NULL};
req.addr = 0x9a56

I'm not sure what req.mbox = 0x4e or req.addr_len = 0x80 mean.

There are also a few addresses either different or missing (0xd508, 0xd73a, 
0xaeff, ...) in various . I'm not sure if any of them could have anything to do 
with how the IR behaves...

I'll try and check these to see if they make any difference when I get a chance.

Regards,

Stuart

af9015-b0ba0a6dfca1_tinytwin_remote.patch:
--- orig/drivers/media/dvb/dvb-usb/af9015.c	2009-03-31 07:57:51.000000000 +1100
+++ new/drivers/media/dvb/dvb-usb/af9015.c	2009-03-31 11:44:16.000000000 +1100
@@ -785,17 +785,14 @@ static int af9015_read_config(struct usb
 				  ARRAY_SIZE(af9015_ir_table_leadtek);
 				break;
 			case USB_VID_VISIONPLUS:
-				if (udev->descriptor.idProduct ==
-				cpu_to_le16(USB_PID_AZUREWAVE_AD_TU700)) {
-					af9015_properties[i].rc_key_map =
-					  af9015_rc_keys_twinhan;
-					af9015_properties[i].rc_key_map_size =
-					  ARRAY_SIZE(af9015_rc_keys_twinhan);
-					af9015_config.ir_table =
-					  af9015_ir_table_twinhan;
-					af9015_config.ir_table_size =
-					  ARRAY_SIZE(af9015_ir_table_twinhan);
-				}
+				af9015_properties[i].rc_key_map =
+				  af9015_rc_keys_twinhan;
+				af9015_properties[i].rc_key_map_size =
+				  ARRAY_SIZE(af9015_rc_keys_twinhan);
+				af9015_config.ir_table =
+				  af9015_ir_table_twinhan;
+				af9015_config.ir_table_size =
+				  ARRAY_SIZE(af9015_ir_table_twinhan);
 				break;
 			case USB_VID_KWORLD_2:
 				/* TODO: use correct rc keys */

kernel-2.6.29_tinytwin_remote_patch.diff:
--- orig/drivers/hid/hid-core.c	2009-03-24 10:12:14.000000000 +1100
+++ new/drivers/hid/hid-core.c	2009-03-31 15:08:13.000000000 +1100
@@ -1629,6 +1629,7 @@ static const struct hid_device_id hid_ig
 	{ HID_USB_DEVICE(USB_VENDOR_ID_WISEGROUP, USB_DEVICE_ID_1_PHIDGETSERVO_20) },
 	{ HID_USB_DEVICE(USB_VENDOR_ID_WISEGROUP, USB_DEVICE_ID_8_8_4_IF_KIT) },
 	{ HID_USB_DEVICE(USB_VENDOR_ID_YEALINK, USB_DEVICE_ID_YEALINK_P1K_P4K_B2K) },
+	{ HID_USB_DEVICE(USB_VENDOR_ID_DIGITALNOW, USB_DEVICE_ID_DIGITALNOW_TINYTWIN) 
},
 	{ }
 };
 
--- orig/drivers/hid/hid-ids.h	2009-03-24 10:12:14.000000000 +1100
+++ new/drivers/hid/hid-ids.h	2009-03-31 15:09:05.000000000 +1100
@@ -420,4 +420,7 @@
 #define USB_VENDOR_ID_KYE		0x0458
 #define USB_DEVICE_ID_KYE_GPEN_560	0x5003
 
+#define USB_VENDOR_ID_DIGITALNOW	0x13d3
+#define USB_DEVICE_ID_DIGITALNOW_TINYTWIN	0x3226
+
 #endif


_______________________________________________
linux-dvb users mailing list
For V4L/DVB development, please use instead linux-media@vger.kernel.org
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] Patch for DigitalNow TinyTwin remote.

[Antti Palosaari]

Hei Stuart,
Mainly I need your signed-off-by tag, please reply with tag.
http://kerneltrap.org/taxonomy/term/245
Signed-off-by: forename surname <email@address>

See comments below,
Stuart wrote:
>> But the reason I pressure you is that merge window for 2.6.30 is open
>> only few days. After that we cannot put new code / functionality until
>> 2.6.31 opens and it is very many months from that day.
>>
>> 1.) I suggest that you make very small patch adding basic support for
>> TinyTwin remote (mainly add device IDs to same places as TwinHan).
> 
> There are two patches in my last email which I believe achieve this. One simply 
> removes the if statement so that the AzureWave IR tables are assigned for the 
> TinyTwin. The other adds the TinyTwin to the HID ignore list so that there are 
> no repeat key presses. I've included them at the end of this email as well.
> 
>> 2.) Make other patch *later* that fix repeating issue. This one can be
>> added to the  2.6.30 later (there many release candidates in next
>> months) as bug fix.
> 
> I've been looking through usb sniffs when plugging the TinyTwin in and can't see 
> much that's different. There's a slight difference in the first 4 bytes of each 
> packet sent for the firmware, for example the first packet for each:
> 
> Linux:   00 51 00 00
> Windows: 38 51 00 c0

I think demodulator address field (0x38) is not valid - it is just don't 
care in that case.

> The IR table download is also sent slightly differently, in Linux it's:
> 
> 21 .. 00 9a 56 00 00 01 00
> 
> from
> 
> struct req_t req = {WRITE_MEMORY, 0, 0, 0, 0, 1, NULL};
> req.addr = 0x9a56
> 
> While Windows is:
> 
> 21 .. 38 9a 56 4e 80 01 00
> 
> which would be
> 
> struct req_t req = {WRITE_MEMORY, AF9015_I2C_DEMOD, 0, 4e, 80, 1, NULL};
> req.addr = 0x9a56

yes, but same here.

> I'm not sure what req.mbox = 0x4e or req.addr_len = 0x80 mean.

hmm, not sure if mbox have meaning. I doubt no meaning, if I remember 
correctly it is also used only by demodulator. Same probably for 
addr_len. But I check those later.

> There are also a few addresses either different or missing (0xd508, 0xd73a, 
> 0xaeff, ...) in various . I'm not sure if any of them could have anything to do 
> with how the IR behaves...

I doubt no.

> I'll try and check these to see if they make any difference when I get a chance.

Thank. You have done rather much work for this :)

> 
> Regards,
> 
> Stuart
> 
> af9015-b0ba0a6dfca1_tinytwin_remote.patch:

This patch is fine, I will apply it when got your signed-off-by.

> kernel-2.6.29_tinytwin_remote_patch.diff:
> --- orig/drivers/hid/hid-core.c	2009-03-24 10:12:14.000000000 +1100
> +++ new/drivers/hid/hid-core.c	2009-03-31 15:08:13.000000000 +1100

> --- orig/drivers/hid/hid-ids.h	2009-03-24 10:12:14.000000000 +1100
> +++ new/drivers/hid/hid-ids.h	2009-03-31 15:09:05.000000000 +1100

I don't like to touch other than dvb-modules :o I will not apply this to 
my tree / pull-request until whole repeating issue is clear. Why it 
comes and why it does not occur every machine.

regards
Antti
-- 
http://palosaari.fi/

_______________________________________________
linux-dvb users mailing list
For V4L/DVB development, please use instead linux-media@vger.kernel.org
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] Patch for DigitalNow TinyTwin remote.

[Stuart]

Patch to provide basic support for DigitalNow TinyTwin Remote.

Signed-off-by: Stuart Hall <mailing-lists@enginuities.com>

af9015-b0ba0a6dfca1_tinytwin_remote.patch
--- orig/drivers/media/dvb/dvb-usb/af9015.c	2009-03-31 07:57:51.000000000 +1100
+++ new/drivers/media/dvb/dvb-usb/af9015.c	2009-03-31 11:44:16.000000000 +1100
@@ -785,17 +785,14 @@ static int af9015_read_config(struct usb
 				  ARRAY_SIZE(af9015_ir_table_leadtek);
 				break;
 			case USB_VID_VISIONPLUS:
-				if (udev->descriptor.idProduct ==
-				cpu_to_le16(USB_PID_AZUREWAVE_AD_TU700)) {
-					af9015_properties[i].rc_key_map =
-					  af9015_rc_keys_twinhan;
-					af9015_properties[i].rc_key_map_size =
-					  ARRAY_SIZE(af9015_rc_keys_twinhan);
-					af9015_config.ir_table =
-					  af9015_ir_table_twinhan;
-					af9015_config.ir_table_size =
-					  ARRAY_SIZE(af9015_ir_table_twinhan);
-				}
+				af9015_properties[i].rc_key_map =
+				  af9015_rc_keys_twinhan;
+				af9015_properties[i].rc_key_map_size =
+				  ARRAY_SIZE(af9015_rc_keys_twinhan);
+				af9015_config.ir_table =
+				  af9015_ir_table_twinhan;
+				af9015_config.ir_table_size =
+				  ARRAY_SIZE(af9015_ir_table_twinhan);
 				break;
 			case USB_VID_KWORLD_2:
 				/* TODO: use correct rc keys */


_______________________________________________
linux-dvb users mailing list
For V4L/DVB development, please use instead linux-media@vger.kernel.org
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] Patch for DigitalNow TinyTwin remote.

[Antti Palosaari]

Stuart wrote:
> Patch to provide basic support for DigitalNow TinyTwin Remote.
> 
> Signed-off-by: Stuart Hall <mailing-lists@enginuities.com>
> 
> af9015-b0ba0a6dfca1_tinytwin_remote.patch

Applied, thanks.

Antti
-- 
http://palosaari.fi/

_______________________________________________
linux-dvb users mailing list
For V4L/DVB development, please use instead linux-media@vger.kernel.org
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] Patch for DigitalNow TinyTwin remote.

[Stuart]

Hi Antti,

You may recall discussing this a while ago, I've been looking in to the problem 
with the DigitalNow TinyTwin remote control and believe I have some idea of what 
is going on.

> I don't like to touch other than dvb-modules :o I will not apply this to
> my tree / pull-request until whole repeating issue is clear. Why it
> comes and why it does not occur every machine.

I tried a number of things which made no difference until I tried to use the 
device with uhci_hcd rather than ehci_hcd. With uhci_hcd there was a 0.27s delay 
between key press and release rather than 17.5s with ehci_hcd.

I posted a question on linux-usb (which can be found here: 
http://thread.gmane.org/gmane.linux.usb.general/16749) to work out why this 
difference was occurring. Alan kindly pointed out that there is probably some 
buggy firmware as the device appears to set bInterval for the endpoint 
descriptor to 16 regardless of bus speed. This means using uchi_hcd it should be 
polled at 16ms and using ehci_hcd it should be polled at 4096ms (however 
ehci_hcd clips this to 1024ms).

It seems that the latest firmware version 4.95.0 has a strange 17x delay in it 
(16ms x 17 = 272ms or ~0.27s and 1024ms x 17 = 17408ms or ~17.5s). I've found 
that Windows should have a polling interval of 32 uframes or 4ms for a high 
speed device with 6 <= bInterval <= 255. With a 17x delay this becomes 68ms 
which is still small enough to not be a problem.

I've also noticed that there are spurious presses (not reported as events, 
spurious interrupt transfers) seen in both Windows and Linux with the 4.95.0 
firmware.

Using the older firmware (4.65.0, 4.71.0 and 4.73.0) all seem to behave better 
(not perfectly, but better). They still have a buggy bInterval value where the 
full speed value is used for high speed as well (which is masked under Windows) 
however this can be worked around in hid-quirks.c.

So, I guess my questions are, is there a revised firmware fixing any of this? Is 
there any information about the device firmware to possibly work out what the 
firmware is doing and fix it? Is it possible to get information from the 
manufacturer? Is there a contact address I could get in contact with to find 
out?

Thanks in advance,

Stuart


_______________________________________________
linux-dvb users mailing list
For V4L/DVB development, please use instead linux-media@vger.kernel.org
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] Patch for DigitalNow TinyTwin remote.

[Antti Palosaari]

terve Stuart,
I am very thankful to research you have done according to this issue.

Stuart wrote:
> Hi Antti,
> 
> You may recall discussing this a while ago, I've been looking in to the problem 
> with the DigitalNow TinyTwin remote control and believe I have some idea of what 
> is going on.
> 
>> I don't like to touch other than dvb-modules :o I will not apply this to
>> my tree / pull-request until whole repeating issue is clear. Why it
>> comes and why it does not occur every machine.
> 
> I tried a number of things which made no difference until I tried to use the 
> device with uhci_hcd rather than ehci_hcd. With uhci_hcd there was a 0.27s delay 
> between key press and release rather than 17.5s with ehci_hcd.
> 
> I posted a question on linux-usb (which can be found here: 
> http://thread.gmane.org/gmane.linux.usb.general/16749) to work out why this 
> difference was occurring. Alan kindly pointed out that there is probably some 
> buggy firmware as the device appears to set bInterval for the endpoint 
> descriptor to 16 regardless of bus speed. This means using uchi_hcd it should be 
> polled at 16ms and using ehci_hcd it should be polled at 4096ms (however 
> ehci_hcd clips this to 1024ms).
> 
> It seems that the latest firmware version 4.95.0 has a strange 17x delay in it 
> (16ms x 17 = 272ms or ~0.27s and 1024ms x 17 = 17408ms or ~17.5s). I've found 
> that Windows should have a polling interval of 32 uframes or 4ms for a high 
> speed device with 6 <= bInterval <= 255. With a 17x delay this becomes 68ms 
> which is still small enough to not be a problem.
> 
> I've also noticed that there are spurious presses (not reported as events, 
> spurious interrupt transfers) seen in both Windows and Linux with the 4.95.0 
> firmware.
> 
> Using the older firmware (4.65.0, 4.71.0 and 4.73.0) all seem to behave better 
> (not perfectly, but better). They still have a buggy bInterval value where the 
> full speed value is used for high speed as well (which is masked under Windows) 
> however this can be worked around in hid-quirks.c.
> 
> So, I guess my questions are, is there a revised firmware fixing any of this? Is 
> there any information about the device firmware to possibly work out what the 
> firmware is doing and fix it? Is it possible to get information from the 
> manufacturer? Is there a contact address I could get in contact with to find 
> out?

4.95.0 is the newest firmware - I just looked about one month back some 
drivers (also newest AF9015 vendor released one) and almost all have 
that firmware. I have ~same stick (AzureWave) as you have and Fedora 10 
x86 and same fw. It is strange that this repeating issue does not affect 
  me :o I have seen this problem earlier, but don't remember which hw, 
fw and Fedora version was running.
I think hw is very much used Intel 8051 based, it could be nice to see 
decompile from various firmwares. I tried that before but without 
success - probably I don't have experience needed to set-up decompiler 
parameters.
Probably I can try to ask manufacturer also fix for fw, don't know 
what's their response because AF9015 is old chipset and AF9035 is 
current one.

regards
Antti
-- 
http://palosaari.fi/

_______________________________________________
linux-dvb users mailing list
For V4L/DVB development, please use instead linux-media@vger.kernel.org
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] Patch for DigitalNow TinyTwin remote.

[Stuart]

Hi Antti,

> I have ~same stick (AzureWave) as you have and Fedora 10
> x86 and same fw. It is strange that this repeating issue does not affect
>   me :o I have seen this problem earlier, but don't remember which hw,
> fw and Fedora version was running.

The drivers contain firmware that is downloaded at offset 0x5100. Perhaps 
different devices have different firmware below this value, I believe mine is 
V3.0 (I'll explain later).

The only other thing I can think of is to do with polling. You may find slightly 
different behaviour with:

echo "1" > /sys/module/dvb_usb/parameters/disable_rc_polling

Also, if you have debugfs and usbmon then looking at the usbmon output for the 
device when a key is pressed on the remote may be interesting as well (obviously 
with polling disabled).

In case you're interested here's my list:

Kernel: 2.6.29
Distribution: Gentoo
Device: DigitalNow TinyTwin

Driver firmware issues:
4.95.0: 17x delay bug
All: Incorrectly report bInterval as full speed for high speed bus (can be 
worked around using HID quirks).

> I think hw is very much used Intel 8051 based, it could be nice to see
> decompile from various firmwares. I tried that before but without
> success - probably I don't have experience needed to set-up decompiler
> parameters.

It certainly seems to be an 8051/2 style uC. I've managed to download the memory 
up to 0x5100, combine this with the different versions of firmware from the 
drivers and disassemble them.

Looking at the memory downloaded from the device shows 'V3.0' at offset 0x0542, 
leading me to believe that may be the version for the code pre-programmed in to 
this device (as opposed to the driver firmware version).

> Probably I can try to ask manufacturer also fix for fw, don't know
> what's their response because AF9015 is old chipset and AF9035 is
> current one.

It would be best if they could help in some way, if they won't fix the firmware 
then if they could provide some source code that would be fantastic, otherwise 
some documentation would go a long way. I've managed to work out some of the 
simpler things and started to run it through a simulator but it'll take a while 
to work through the code without any documentation/source code!

Cheers,

Stuart


_______________________________________________
linux-dvb users mailing list
For V4L/DVB development, please use instead linux-media@vger.kernel.org
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb