Description of problem: The remote control output is detected by rc-keytable -t as before, but will not respond as a keyboard, e.g. where a key is assigned to produce the 1 key in /usr/lib/udev/rc_keymaps/dib0700_rc5, this does not result in this producing 1 on the terminal screen when it is pressed I've recently done a yum update, and result was a sudden and unexplained loss of remote control output - I'm filing under kernel because it is dvb_usb_dib0700 related, but think it's likely to be to be this being impinged on by something else, since I've downgraded the kernel but ithis doesn't fix it. I have a working identical hauppage nova-t-500 and problem is reproduced on this hardware I have a different tv card (leadtek winfast) and the problem is absent Version-Release number of selected component (if applicable): I'm using kernel 3.14.5-200.fc20.x86_64 Problem hardware: lspci Bus 004 Device 002: ID 2040:9950 Hauppauge WinTV Nova-T-500 $ dmesg | grep dvb [ 5.280510] dvb-usb: found a 'Hauppauge Nova-T 500 Dual DVB-T' in cold state, will try to load a firmware [ 5.281501] dvb-usb: downloading firmware from file 'dvb-usb-dib0700-1.20.fw' [ 5.991118] dvb-usb: found a 'Hauppauge Nova-T 500 Dual DVB-T' in warm state. [ 5.991164] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. [ 6.576416] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. [ 7.112398] dvb-usb: schedule remote query interval to 50 msecs. [ 7.112401] dvb-usb: Hauppauge Nova-T 500 Dual DVB-T successfully initialized and connected. [ 7.112552] usbcore: registered new interface driver dvb_usb_dib0700 How reproducible: Always Steps to Reproduce: 1. Do a yum update to get to kernel 3.14.5-200.fc20.x86_64 2. 3. Actual results: Expected results: Additional info:
Apologies - pressed send by accident while doing some further testing. I have just noticed I upgraded libevdev during my yum upgrade and this may be the culprit for the bug. I have downgraded now to libevdev 0.4.1-1.fc20.x86_64 from libevdev-1.2-04compat.1.fc20.x86_64; I will test further and report back
Okay. My mistake, this is anot a libevdev problem, I am still having a lot of difficulty identifying the component that is responsible. Can this bug be transferred to kernel? I have done a yum history and attached it, so the responsible component is somewhere here...
Created attachment 904671 [details] history of the yum update all that caused the problem
Solved, not a bug. For information: there were two causes - 1. something in this update causes ir-keytable to be stricter about the format of the keytable it tries to load, so it should start with e.g. # table rc6_mce, type: RC6 I had manually changed the keytable for the remote control device, and added a comment e.g. #this is my keytable # table rc6_mce, type: RC6 This comment was read as an invalid keytable, and was stopping the keytable from loading at startup Cause 2. Previously, X drivers had taken partial control of the remote control, and this conflicted with ir-keytable. The solution was to disable the remote control in X by adding an instruction to xorg.conf e.g. Section "InputClass" Identifier "MCE USB Keyboard mimic blacklist" Driver "mceusb" MatchProduct "Media Center Ed. eHome Infrared Remote Transceiver (1934:5168)" Option "Ignore" "on" EndSectionto Clearly the latest kernel integrates better with ir-keytable and X, as these lines are no longer needed - in fact, they now also make X ignore any the remote control input as a keyboard. Hope this might be helpful if anyone else experiences the same. Anyway, my problem is solved and this bug is invalid!