[linux-dvb] Patch for DigitalNow TinyTwin remote.
crope at iki.fi
Wed Apr 22 20:18:45 CEST 2009
I am very thankful to research you have done according to this issue.
> 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
> 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
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
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
More information about the linux-dvb