[linux-dvb] Patch for DigitalNow TinyTwin remote.

Stuart mailing-lists at enginuities.com
Tue Mar 31 16:04:03 CEST 2009


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





More information about the linux-dvb mailing list