Bug 19652 - dib0700 - Remote no longer functional since release 2.6.34
Summary: dib0700 - Remote no longer functional since release 2.6.34
Status: RESOLVED OBSOLETE
Alias: None
Product: v4l-dvb
Classification: Unclassified
Component: dvb-usb (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: dvb-usb
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-10-03 19:59 UTC by Michael Meier
Modified: 2013-12-10 22:12 UTC (History)
2 users (show)

See Also:
Kernel Version: 2.6.34
Subsystem:
Regression: No
Bisected commit-id:


Attachments
Output of lsusb with receiver plugged in during boot (2.93 KB, text/plain)
2010-10-10 18:14 UTC, Michael Meier
Details
Output of lsusb after replugging receiver (2.95 KB, text/plain)
2010-10-10 18:15 UTC, Michael Meier
Details
kernel config used for 2.6.36-rc6 (52.80 KB, text/plain)
2010-10-10 18:17 UTC, Michael Meier
Details

Description Michael Meier 2010-10-03 19:59:43 UTC
Since linux release 2.6.34 the remote control input stopped working for my WinTV Nova TD2 DVB-T receiver keeping me from updating my DVR system. dmesg shows "dib0700: rc submit urb failed". Taking a look at the code, in file dib0700_core.c in function dib0700_rc_setup the call to usb_submit_urb failes with return code -EINVAL(-22) because purb->interval == 0. Settings the interval to a hard-coded value before the call restores original function, but it should probably be set dynamically according to the remote query interval.

This behavior was introduced by following commit:


commit 6a2071006b72bf887e38c025c60f98d2998ceacb
Author: Devin Heitmueller <dheitmueller@kernellabs.com>
Date:   Mon Jan 4 02:43:19 2010 -0300

V4L/DVB (13930): dib0700: rework IR logic for firmware 1.20



Furthermore, commit d3c501d1938c56c9998fd51fc8dadb49ddd6110e [V4L/DVB: dib0700: Fix RC protocol logic to properly handle NEC/NECx and RC-5]  breaks passing the right keycode to the input layer. For example, according to the IR keymap in rc-dib0700-rc5.c the codes for "play" and "9" should be 0x1e35 and 0x1e09. Actual values passed to the input layer are 0x1e0035 and 0x1e0009.
Before this commit the keycode was composed this way:

u16 system;
u8 *buf;

buf = (u8 *)purb->transfer_buffer;

poll_reply.system     = (buf[2] << 8) | buf[3];
keycode = poll_reply.system << 8 | poll_reply.data;

and now

union {
  u16 system16;
  struct {
    u8 system;
    u8 not_system;
  };
};

struct dib0700_rc_response *poll_reply;
poll_reply = purb->transfer_buffer;

keycode = poll_reply->system16 << 8 | poll_reply->data;

so that system16 is depending on processor endianess and in this case byte-swapped.

---------

commit d3c501d1938c56c9998fd51fc8dadb49ddd6110e
Author: Mauro Carvalho Chehab <mchehab@redhat.com>
Date:   Sun Aug 1 10:35:49 2010 -0300

V4L/DVB: dib0700: Fix RC protocol logic to properly handle NEC/NECx and RC-5



With these two things fixed my remote is working again but not as good as it was with kernel 2.6.33. The input seems to be lagging, i.e. pushing play/stop/seek in mplayer has an effect about half a second after pushing the key unlike before. Also when pushing a key several times the key repetition starts and produces 10 and more key events even if only pushing the keys 3 times. This seems to be related to commit 72b393106bddc9f0a1ab502b4c8c5793a0441a30 [V4L/DVB: Port dib0700 to rc-core] moving the dib0700 to use the rc-core handler but also removing the module's own key repetition logic which was working fine for me and giving a keyboard-like behavior. 



Hardware used:

Intel essentials D945GCLF2
Hauppauge WinTV Nova TD 2
Firmware: f42f86e2971fd994003186a055813237  dvb-usb-dib0700-1.20.fw
Remote: Hauppauge "snowboard" silver remote / 45 buttons / RC-5 protocol
Comment 1 Michael Meier 2010-10-10 18:13:41 UTC
Today I noticed that the described error message "dib0700: rc submit urb failed" appears only if the receiver was already plugged in when the system boots up. usb_submit_urb is called with xfertype USB_ENDPOINT_XFER_INT in which it fails because interval==0. After replugging the receiver it correctly uses the xfertype USB_ENDPOINT_XFER_BULK and succeeds.
Attached is the output of lsusb -v for both cases which clearly show different endpoint transfer types. This is the case no matter if the device was detected in cold or warm state, even with the dvb modules removed from the kernel completely, so the cause for this behavior lies somewhere else and is not directly related to commit 6a2071006b72bf887e38c025c60f98d2998ceacb. The device that is affected is a WinTV Nova TD (2040:9580) with dual tuner. I also tested this with a WinTV Nova T (2040:7070) with single tuner which is not behaving this way and working as usual.
Comment 2 Michael Meier 2010-10-10 18:14:57 UTC
Created attachment 33022 [details]
Output of lsusb with receiver plugged in during boot
Comment 3 Michael Meier 2010-10-10 18:15:53 UTC
Created attachment 33032 [details]
Output of lsusb after replugging receiver
Comment 4 Michael Meier 2010-10-10 18:17:34 UTC
Created attachment 33042 [details]
kernel config used for 2.6.36-rc6
Comment 5 Michael Meier 2010-10-11 20:15:42 UTC
I just tested it with Windows and it seems like the behavior is the same. I started the system with the receiver plugged in and usbview from the Windows XP DDK lists the endpoint transfer type as "interrupt". After replugging the transfer type changes to "bulk".
Does anyone know what could be the reason for this or can reproduce it on his hardware?

Note You need to log in before you can comment on or make changes to this bug.