Re: DigitalNow TinyTwin DVB-T tuner (remote control) issues.

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

 



On Wednesday 22 April 2009 00:23:18 Alan Stern wrote:
> > So, my next question is if there's any way for me to reverse the firmware
> > to fix the real problem and if not is there a way to fix the bInterval
> > value for this device? Possibly something like the various hid drivers
> > such as hid-lg.c for hid quirks?
>
> I don't know anything about the device's firmware; you'll probably have
> to complain to the manufacturer and ask them to fix it.  Both the 17x
> behavior and the incorrect bInterval value.

Sorry, I didn't explain myself very well, I was wondering if there is any 
information/are any tutorials on how to work out what the firmware is doing. 
Perhaps disassembling or even decompiling the firmware code. I searched on 
Google but I couldn't find anything useful.

> Yes, you certainly can add a special HID driver for this device.  But
> fixing the firmware would be preferable.

If this can't be fixed in firmware, I've found there is a quirk in 
include/linux/hid.h defined as HID_QUIRK_FULLSPEED_INTERVAL. In 
drivers/hid/usbhid/hid-quirks.c there is a blacklist which includes the Afatech 
AF9016. Since this is the Afatech AF9015 it would appear that this is the next 
best way to handle the problem (I tested it and it seemed to work here).

> I meant all the USB transfers.  Just look at the logs from the Windows
> sniffer and from usbmon, and see what the two systems do differently.
> Maybe Windows ignores the value in the descriptor and polls at
> intervals of 1 ms; then the 17x behavior might still be present but it
> would be undetectable.

Just in case it becomes useful for future reference, I found this link:

http://msdn.microsoft.com/en-us/library/ms793346.aspx

It describes the USB_ENDPOINT_DESCRIPTOR structure for Windows drivers. It 
defines the polling interval for bInterval values for low, full and high speed 
devices.

In this case, high speed devices for 6 <= bInterval <= 255 have a polling 
interval of 32 uframes or 4ms. With the 17x delay this becomes 68ms which is 
close to the 90ms I was seeing from usb sniffs (as you mentioned, they may not 
be that accurate).

Thanks for your help, I'll continue looking in to the firmware issues...

Stuart

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux