| Message ID | 20161116105256.GA9998@shambles.local (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Wed, Nov 16, 2016 at 09:52:58PM +1100, Vincent McIntyre wrote: > I have a fairly old dvico dual digital 4 tuner and remote. > There seem to be some issues with support for it, can I help fix them? > > I am using ir-keytable 1.10.0-1 on Ubuntu 16.04 LTS, > with kernel 4.4.0-47-generic (package version 4.4.0-47-generic) > > The remote's keymapping is the one in /lib/udev/rc_keymaps/dvico_mce; > kernel support for the device is in media/usb/dvb-usb/cxusb.c. > > Mostly it works, in that I get correct keycodes back from evtest > and ir-keytable -t. But I want to change some of the keycode mappings > and that is not working. I suspect the problem here is rc-core is not used and legacy_dvb_usb_setkeycode has a bug (it has several problems). It would be nicer if we could move it rc-core, but for that to work we need to know what scancodes remote sends (and in what protocol). A scancode of 0xfe47 is not a valid RC5 scancode. Would it be possible to test the remote with another device (say an usb mce receiver or so) and see what scancodes it sends? Then we can translate the keymap to a real one and make the cxusb driver send correct scancodes to rc-core. Sean -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Nov 17, 2016 at 01:45:26PM +0000, Sean Young wrote: > On Wed, Nov 16, 2016 at 09:52:58PM +1100, Vincent McIntyre wrote: > > I have a fairly old dvico dual digital 4 tuner and remote. > > There seem to be some issues with support for it, can I help fix them? > > > > I am using ir-keytable 1.10.0-1 on Ubuntu 16.04 LTS, > > with kernel 4.4.0-47-generic (package version 4.4.0-47-generic) > > > > The remote's keymapping is the one in /lib/udev/rc_keymaps/dvico_mce; > > kernel support for the device is in media/usb/dvb-usb/cxusb.c. > > > > Mostly it works, in that I get correct keycodes back from evtest > > and ir-keytable -t. But I want to change some of the keycode mappings > > and that is not working. > > I suspect the problem here is rc-core is not used and > legacy_dvb_usb_setkeycode has a bug (it has several problems). > > It would be nicer if we could move it rc-core, but for that to work > we need to know what scancodes remote sends (and in what protocol). > A scancode of 0xfe47 is not a valid RC5 scancode. So are you saying that the hex codes in the rc_map_dvico_mce_table struct are invalid (at least in some cases)? How can I tell what protocol is in use? 0x00010001 doesn't mean much to me; I did search the linux source for the code but didn't find any helpful matches. > Would it be possible to test the remote with another device (say an > usb mce receiver or so) and see what scancodes it sends? Then we can > translate the keymap to a real one and make the cxusb driver send > correct scancodes to rc-core. Great idea. Do you mean something like [1]? Or the (presumably generic) receiver that comes with [2]? Would a FLIRC work? Probably dumb question - in this machine I also have an iMon Remote (152c:ffdc) and Leadtek WinFast DTV Dongle Dual Do you think either of those would be helpful? I tried evtest with them and the remote, no responses. # ir-keytable Found /sys/class/rc/rce0/ (/dev/input/event5) with: Driver imon, table rc-imon-mce Supported protocols: rc-6 Enabled protocols: rc-6 Name: iMON Remote (15c2:ffdc) bus: 3, vendor/product: 15c2:ffdc, version: 0x0000 Repeat delay = 500 ms, repeat period = 125 ms Found /sys/class/rc/rc1/ (/dev/input/event16) with: Driver dvb_usb_af9035, table rc-empty Supported protocols: nec Enabled protocols: Name: Leadtek WinFamst DTV Dongle Dual bus: 3, vendor/product: 0413:6a05, version: 0x0200 Repeat delay = 500 mss, repeat period = 125 ms Thanks Vince [1] http://www.ebay.com.au/itm/New-HP-USB-MCE-IR-Wireless-Receiver-Windows-7-Vista-/261127073131 [2] https://www.jaycar.com.au/home-theatre-pc-remote-control/p/XC4939 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Nov 18, 2016 at 11:14:25PM +1100, Vincent McIntyre wrote: > On Thu, Nov 17, 2016 at 01:45:26PM +0000, Sean Young wrote: > > On Wed, Nov 16, 2016 at 09:52:58PM +1100, Vincent McIntyre wrote: > > > I have a fairly old dvico dual digital 4 tuner and remote. > > > There seem to be some issues with support for it, can I help fix them? > > > > > > I am using ir-keytable 1.10.0-1 on Ubuntu 16.04 LTS, > > > with kernel 4.4.0-47-generic (package version 4.4.0-47-generic) > > > > > > The remote's keymapping is the one in /lib/udev/rc_keymaps/dvico_mce; > > > kernel support for the device is in media/usb/dvb-usb/cxusb.c. > > > > > > Mostly it works, in that I get correct keycodes back from evtest > > > and ir-keytable -t. But I want to change some of the keycode mappings > > > and that is not working. > > > > I suspect the problem here is rc-core is not used and > > legacy_dvb_usb_setkeycode has a bug (it has several problems). > > > > It would be nicer if we could move it rc-core, but for that to work > > we need to know what scancodes remote sends (and in what protocol). > > A scancode of 0xfe47 is not a valid RC5 scancode. > > So are you saying that the hex codes in the rc_map_dvico_mce_table > struct are invalid (at least in some cases)? Most likely the remote produces IR in a standard protocol (e.g. rc5, rc6). If we first get the keymap right then the remote can be used with any IR receiver that can deal with its protocol; conversely, if we know what protocol the IR receiver can receive, and we make it produce the scancodes in the right format, it can then be used with any remote that uses the protocol it understands. So at the moment we don't know what protocol it is, and even if it is rc5 then some bit shifting might be needed to make it into a proper rc5 scancode (both driver and keymap). > How can I tell what protocol is in use? > 0x00010001 doesn't mean much to me; I did search the linux source > for the code but didn't find any helpful matches. At the moment it's not easy to determine what protocol an remote uses; I would like to change that but for now, the following is probably the easiest way. cd /sys/class/rc/rc1 # replace rc1 with your receiver for i in $(<protocols); do echo +$i > protocols; done echo 3 > /sys/module/rc_core/parameters/debug journal -f -k Protocol numbers are defined in enum rc_type, see include/media/rc-map.h > > Would it be possible to test the remote with another device (say an > > usb mce receiver or so) and see what scancodes it sends? Then we can > > translate the keymap to a real one and make the cxusb driver send > > correct scancodes to rc-core. > > Great idea. Do you mean something like [1]? Yes, it would be a receiver like that. > Or the (presumably generic) receiver that comes with [2]? It's not clear what usb receiver it uses. > Would a FLIRC work? I hadn't heard of flirc, looks like it doesn't have a kernel driver. Maybe I'll go and get one. :) > Probably dumb question - in this machine I also have > an iMon Remote (152c:ffdc) > and Leadtek WinFast DTV Dongle Dual > Do you think either of those would be helpful? > I tried evtest with them and the remote, no responses. > > # ir-keytable > Found /sys/class/rc/rce0/ (/dev/input/event5) with: > Driver imon, table rc-imon-mce > Supported protocols: rc-6 > Enabled protocols: rc-6 > Name: iMON Remote (15c2:ffdc) > bus: 3, vendor/product: 15c2:ffdc, version: 0x0000 > Repeat delay = 500 ms, repeat period = 125 ms > Found /sys/class/rc/rc1/ (/dev/input/event16) with: > Driver dvb_usb_af9035, table rc-empty > Supported protocols: nec > Enabled protocols: > Name: Leadtek WinFamst DTV Dongle Dual > bus: 3, vendor/product: 0413:6a05, version: 0x0200 > Repeat delay = 500 mss, repeat period = 125 ms Looks like it's neither rc6 nor nec then. If you don't have the right receiver then all of this a bit academic. Maybe it's possible to port to rc-core with the existing scancodes. Thanks Sean > > Thanks > Vince > > [1] http://www.ebay.com.au/itm/New-HP-USB-MCE-IR-Wireless-Receiver-Windows-7-Vista-/261127073131 > [2] https://www.jaycar.com.au/home-theatre-pc-remote-control/p/XC4939 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Nov 18, 2016 at 05:40:34PM +0000, Sean Young wrote: > > > > So are you saying that the hex codes in the rc_map_dvico_mce_table > > struct are invalid (at least in some cases)? > > Most likely the remote produces IR in a standard protocol (e.g. rc5, rc6). > If we first get the keymap right then the remote can be used with any > IR receiver that can deal with its protocol; conversely, if we know > what protocol the IR receiver can receive, and we make it produce the > scancodes in the right format, it can then be used with any remote that > uses the protocol it understands. > > So at the moment we don't know what protocol it is, and even if it is > rc5 then some bit shifting might be needed to make it into a proper > rc5 scancode (both driver and keymap). > > > How can I tell what protocol is in use? > > 0x00010001 doesn't mean much to me; I did search the linux source > > for the code but didn't find any helpful matches. > > At the moment it's not easy to determine what protocol an remote uses; > I would like to change that but for now, the following is probably > the easiest way. > > cd /sys/class/rc/rc1 # replace rc1 with your receiver > for i in $(<protocols); do echo +$i > protocols; done > echo 3 > /sys/module/rc_core/parameters/debug > journal -f -k Ah. Here we have a problem. The device (/dev/input/event15) doesn't have a corresponding rcX node, see ir-keytable output below. I had it explained to me like this: A "HID" device is basically any input device that resembles a keyboard or mouse (Human Interface Device). The label may also cover things like joysticks, etc. It does /not/ include remotes, so it seems, since "remote" can cover a wide variety of input devices. Some remotes can emulate fully or partially keyboard keypresses which is why they can be treated as HID devices. Of course, not all the keys may be mapped correctly or at all. > Protocol numbers are defined in enum rc_type, see include/media/rc-map.h > > > > Would it be possible to test the remote with another device (say an > > > usb mce receiver or so) and see what scancodes it sends? Then we can > > > translate the keymap to a real one and make the cxusb driver send > > > correct scancodes to rc-core. > > > > Great idea. Do you mean something like [1]? > > Yes, it would be a receiver like that. > > > Or the (presumably generic) receiver that comes with [2]? > > It's not clear what usb receiver it uses. > > > Would a FLIRC work? > > I hadn't heard of flirc, looks like it doesn't have a kernel driver. Maybe > I'll go and get one. :) > > > Probably dumb question - in this machine I also have > > an iMon Remote (152c:ffdc) > > and Leadtek WinFast DTV Dongle Dual > > Do you think either of those would be helpful? > > I tried evtest with them and the remote, no responses. > > > > # ir-keytable > > Found /sys/class/rc/rce0/ (/dev/input/event5) with: > > Driver imon, table rc-imon-mce > > Supported protocols: rc-6 > > Enabled protocols: rc-6 > > Name: iMON Remote (15c2:ffdc) > > bus: 3, vendor/product: 15c2:ffdc, version: 0x0000 > > Repeat delay = 500 ms, repeat period = 125 ms > > Found /sys/class/rc/rc1/ (/dev/input/event16) with: > > Driver dvb_usb_af9035, table rc-empty > > Supported protocols: nec > > Enabled protocols: > > Name: Leadtek WinFamst DTV Dongle Dual > > bus: 3, vendor/product: 0413:6a05, version: 0x0200 > > Repeat delay = 500 mss, repeat period = 125 ms > > Looks like it's neither rc6 nor nec then. > > If you don't have the right receiver then all of this a bit academic. > Maybe it's possible to port to rc-core with the existing scancodes. I may have given bad information here - I need to check whether the IR receivers for these devices are properly connected. That might be why there was no response... Thanks for your help so far Vince -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Nov 18, 2016 at 05:40:34PM +0000, Sean Young wrote: > > > > # ir-keytable > > Found /sys/class/rc/rce0/ (/dev/input/event5) with: > > Driver imon, table rc-imon-mce > > Supported protocols: rc-6 > > Enabled protocols: rc-6 > > Name: iMON Remote (15c2:ffdc) > > bus: 3, vendor/product: 15c2:ffdc, version: 0x0000 > > Repeat delay = 500 ms, repeat period = 125 ms > > Found /sys/class/rc/rc1/ (/dev/input/event16) with: > > Driver dvb_usb_af9035, table rc-empty > > Supported protocols: nec > > Enabled protocols: > > Name: Leadtek WinFamst DTV Dongle Dual > > bus: 3, vendor/product: 0413:6a05, version: 0x0200 > > Repeat delay = 500 mss, repeat period = 125 ms So I checked on the ir receivers and found the rc1 device ir receiver was indeed blocked (haven't checked rc0 properly, time is short) I tested it with evtest and the remote that comes with the device # evtest /dev/input/event16 Input driver version is 1.0.1 Input device ID: bus 0x3 vendor 0x413 product 0x6a05 version 0x200 Input device name: "Leadtek WinFast DTV Dongle Dual" Supported events: Event type 0 (EV_SYN) Event type 1 (EV_KEY) Event code 28 (KEY_ENTER) Event code 103 (KEY_UP) Event code 105 (KEY_LEFT) Event code 106 (KEY_RIGHT) Event code 108 (KEY_DOWN) Event code 111 (KEY_DELETE) Event code 113 (KEY_MUTE) Event code 114 (KEY_VOLUMEDOWN) Event code 115 (KEY_VOLUMEUP) Event code 119 (KEY_PAUSE) Event code 128 (KEY_STOP) Event code 142 (KEY_SLEEP) Event code 152 (KEY_SCREENLOCK) Event code 161 (KEY_EJECTCD) Event code 164 (KEY_PLAYPAUSE) Event code 167 (KEY_RECORD) Event code 168 (KEY_REWIND) Event code 174 (KEY_EXIT) Event code 207 (KEY_PLAY) Event code 208 (KEY_FASTFORWARD) Event code 210 (KEY_PRINT) Event code 212 (KEY_CAMERA) Event code 224 (KEY_BRIGHTNESSDOWN) Event code 225 (KEY_BRIGHTNESSUP) Event code 226 (KEY_MEDIA) Event code 352 (KEY_OK) Event code 356 (KEY_POWER2) Event code 358 (KEY_INFO) Event code 365 (KEY_EPG) Event code 366 (KEY_PVR) Event code 368 (KEY_LANGUAGE) Event code 369 (KEY_TITLE) Event code 370 (KEY_SUBTITLE) Event code 372 (KEY_ZOOM) Event code 373 (KEY_MODE) Event code 377 (KEY_TV) Event code 385 (KEY_RADIO) Event code 386 (KEY_TUNER) Event code 387 (KEY_PLAYER) Event code 389 (KEY_DVD) Event code 392 (KEY_AUDIO) Event code 393 (KEY_VIDEO) Event code 398 (KEY_RED) Event code 399 (KEY_GREEN) Event code 400 (KEY_YELLOW) Event code 401 (KEY_BLUE) Event code 402 (KEY_CHANNELUP) Event code 403 (KEY_CHANNELDOWN) Event code 407 (KEY_NEXT) Event code 412 (KEY_PREVIOUS) Event code 425 (KEY_PRESENTATION) Event code 512 (KEY_NUMERIC_0) Event code 513 (KEY_NUMERIC_1) Event code 514 (KEY_NUMERIC_2) Event code 515 (KEY_NUMERIC_3) Event code 516 (KEY_NUMERIC_4) Event code 517 (KEY_NUMERIC_5) Event code 518 (KEY_NUMERIC_6) Event code 519 (KEY_NUMERIC_7) Event code 520 (KEY_NUMERIC_8) Event code 521 (KEY_NUMERIC_9) Event code 522 (KEY_NUMERIC_STAR) Event code 523 (KEY_NUMERIC_POUND) Event type 4 (EV_MSC) Event code 4 (MSC_SCAN) Key repeat handling: Repeat type 20 (EV_REP) Repeat code 0 (REP_DELAY) Value 500 Repeat code 1 (REP_PERIOD) Value 125 Properties: Testing ... (interrupt to exit) <volumedown pressed> Event: time 1479509081.158426, type 4 (EV_MSC), code 4 (MSC_SCAN), value 35a Event: time 1479509081.158426, -------------- SYN_REPORT ------------ <volumeup pressed> Event: time 1479509084.658351, type 4 (EV_MSC), code 4 (MSC_SCAN), value 35e Event: time 1479509084.658351, -------------- SYN_REPORT ------------ ^C I tried to load a keymap but got another segfault # ir-keytable -p nec -d /dev/input/event16 -w /lib/udev/rc_keymaps/rc6_mce Read rc6_mce table Wrote 63 keycode(s) to driver Segmentation fault (core dumped) Can't find a -dbg package so can't give you a useful backtrace at the moment. Anyway: trying the same evtest with the dvico remote evtest /dev/input/event16 <volumedown> Event: time 1479509251.174361, type 4 (EV_MSC), code 4 (MSC_SCAN), value 105 Event: time 1479509251.174361, -------------- SYN_REPORT ------------ <volumeup> Event: time 1479509254.174403, type 4 (EV_MSC), code 4 (MSC_SCAN), value 115 Event: time 1479509254.174403, -------------- SYN_REPORT ------------ So something is connecting via IR. Out of time now, more later Vince -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Nov 18, 2016 at 05:40:34PM +0000, Sean Young wrote: > > At the moment it's not easy to determine what protocol an remote uses; > I would like to change that but for now, the following is probably > the easiest way. > > cd /sys/class/rc/rc1 # replace rc1 with your receiver > for i in $(<protocols); do echo +$i > protocols; done > echo 3 > /sys/module/rc_core/parameters/debug > journal -f -k > > Protocol numbers are defined in enum rc_type, see include/media/rc-map.h I tried this with the rc1 device as a test. I get this odd result: # cat protocols nec # echo '+nec' > protocols bash: echo: write error: Invalid argument and ir-keytable still shows no protocols enabled # ir-keytable Found /sys/class/rc/rc0/ (/dev/input/event5) with: Driver imon, table rc-imon-mce Supported protocols: rc-6 Enabled protocols: rc-6 Name: iMON Remote (15c2:ffdc) bus: 3, vendor/product: 15c2:ffdc, version: 0x0000 Repeat delay = 500 ms, repeat period = 125 ms Found /sys/class/rc/rc1/ (/dev/input/event16) with: Driver dvb_usb_af9035, table rc-empty Supported protocols: nec Enabled protocols: Name: Leadtek WinFast DTV Dongle Dual bus: 3, vendor/product: 0413:6a05, version: 0x0200 Repeat delay = 500 ms, repeat period = 125 ms I messed around some more with ir-keytable and got more segfaults if I try to use the -d argument. # ir-keytable -d /dev/input/event16 -p NEC -p RC6 -w /lib/udev/rc_keymaps/rc6_mce Read rc6_mce table Wrote 63 keycode(s) to driver Segmentation fault (core dumped) -s at least doesn't segfault, but doesn't advance the cause. # ir-keytable -s rc1 -p NEC -p RC6 -w /lib/udev/rc_keymaps/rc6_mce Read rc6_mce table Wrote 63 keycode(s) to driver /sys/class/rc/rc1//protocols: Invalid argument Couldn't change the IR protocols # ir-keytable -s rc1 -p NEC -w /lib/udev/rc_keymaps/winfast Read winfast table Wrote 56 keycode(s) to driver /sys/class/rc/rc1//protocols: Invalid argument Couldn't change the IR protocols Vince -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
--- dvico_mce 2016-11-13 22:50:11.442092350 +1100 +++ testfile 2016-11-16 20:46:29.361411631 +1100 @@ -38,7 +38,7 @@ 0xfe03 KEY_0 0xfe1f KEY_ZOOM 0xfe43 KEY_REWIND -0xfe47 KEY_PLAYPAUSE +0xfe47 KEY_PAUSE 0xfe4f KEY_FASTFORWARD 0xfe57 KEY_MUTE 0xfe0d KEY_STOP
Hi, I have a fairly old dvico dual digital 4 tuner and remote. There seem to be some issues with support for it, can I help fix them? I am using ir-keytable 1.10.0-1 on Ubuntu 16.04 LTS, with kernel 4.4.0-47-generic (package version 4.4.0-47-generic) The remote's keymapping is the one in /lib/udev/rc_keymaps/dvico_mce; kernel support for the device is in media/usb/dvb-usb/cxusb.c. Mostly it works, in that I get correct keycodes back from evtest and ir-keytable -t. But I want to change some of the keycode mappings and that is not working. # cat >testfile 0xfe47 KEY_PAUSE ^D # ir-keytable -v -d /dev/input/event15 -w testfile Parsing testfile keycode file parsing 0xfe47=KEY_PAUSE: value=119 Opening /dev/input/event15 Input Protocol version: 0x00010001 fe47=0077 Wrote 1 keycode(s) to driver So far so good, yes? But evtest still reports the same keycode for the key I tried to modify. # evtest <select device 15> <press PLAYPAUSE key on remote> Event: time 1479206112.262746, type 1 (EV_KEY), code 164 (KEY_PLAYPAUSE), value 1 Event: time 1479206112.262746, -------------- SYN_REPORT ------------ Event: time 1479206112.262760, type 1 (EV_KEY), code 164 (KEY_PLAYPAUSE), value 0 Event: time 1479206112.262760, -------------- SYN_REPORT ------------ # irkeytable -r -d /dev/input/event15 |grep PAUSE Enabled protocols: unknown rc-5 sony nec sanyo mce-kbd rc-6 sharp xmp scancode 0xfe02 = KEY_PAUSE (0x77) scancode 0xfe47 = KEY_PLAYPAUSE (0xa4) I thought that I might need to clear and replace the entire table to get things working. This is where the problems really start. First trying to clear the table causes an infinite loop. # ir-keytable -d /dev/input/event15 -c Opening /dev/input/event15 Input Protocol version: 0x00010001 Deleting entry 1 Deleting entry 2 Deleting entry 3 Deleting entry 4 .... Deleting entry 2114689 Deleting entry 2114690 ^C Then I tried to load a modified version of dvico_mce The whole file was there, with just this change: The program seems to parse the modified file ok but then segaults while reading from the input device. # ir-keytable -v -d /dev/input/event15 -w testfile Parsing testfile keycode file parsing 0xfe02=KEY_TV: value=377 parsing 0xfe0e=KEY_MP3: value=391 parsing 0xfe1a=KEY_DVD: value=389 parsing 0xfe1e=KEY_FAVORITES: value=364 parsing 0xfe16=KEY_SETUP: value=141 parsing 0xfe46=KEY_POWER2: value=356 parsing 0xfe0a=KEY_EPG: value=365 parsing 0xfe49=KEY_BACK: value=158 parsing 0xfe4d=KEY_MENU: value=139 parsing 0xfe51=KEY_UP: value=103 parsing 0xfe5b=KEY_LEFT: value=105 parsing 0xfe5f=KEY_RIGHT: value=106 parsing 0xfe53=KEY_DOWN: value=108 parsing 0xfe5e=KEY_OK: value=352 parsing 0xfe59=KEY_INFO: value=358 parsing 0xfe55=KEY_TAB: value=15 parsing 0xfe0f=KEY_PREVIOUSSONG: value=165 parsing 0xfe12=KEY_NEXTSONG: value=163 parsing 0xfe42=KEY_ENTER: value=28 parsing 0xfe15=KEY_VOLUMEUP: value=115 parsing 0xfe05=KEY_VOLUMEDOWN: value=114 parsing 0xfe11=KEY_CHANNELUP: value=402 parsing 0xfe09=KEY_CHANNELDOWN: value=403 parsing 0xfe52=KEY_CAMERA: value=212 parsing 0xfe5a=KEY_TUNER: value=386 parsing 0xfe19=KEY_OPEN: value=134 parsing 0xfe0b=KEY_1: value=2 parsing 0xfe17=KEY_2: value=3 parsing 0xfe1b=KEY_3: value=4 parsing 0xfe07=KEY_4: value=5 parsing 0xfe50=KEY_5: value=6 parsing 0xfe54=KEY_6: value=7 parsing 0xfe48=KEY_7: value=8 parsing 0xfe4c=KEY_8: value=9 parsing 0xfe58=KEY_9: value=10 parsing 0xfe13=KEY_ANGLE: value=371 parsing 0xfe03=KEY_0: value=11 parsing 0xfe1f=KEY_ZOOM: value=372 parsing 0xfe43=KEY_REWIND: value=168 parsing 0xfe47=KEY_PAUSE: value=119 parsing 0xfe4f=KEY_FASTFORWARD: value=208 parsing 0xfe57=KEY_MUTE: value=113 parsing 0xfe0d=KEY_STOP: value=128 parsing 0xfe01=KEY_RECORD: value=167 parsing 0xfe4e=KEY_POWER: value=116 Read dvico_mce table Opening /dev/input/event15 Input Protocol version: 0x00010001 fe4e=0074 fe01=00a7 fe0d=0080 fe57=0071 fe4f=00d0 fe47=0077 fe43=00a8 fe1f=0174 fe03=000b fe13=0173 fe58=000a fe4c=0009 fe48=0008 fe54=0007 fe50=0006 fe07=0005 fe1b=0004 fe17=0003 fe0b=0002 fe19=0086 fe5a=0182 fe52=00d4 fe09=0193 fe11=0192 fe05=0072 fe15=0073 fe42=001c fe12=00a3 fe0f=00a5 fe55=000f fe59=0166 fe5e=0160 fe53=006c fe5f=006a fe5b=0069 fe51=0067 fe4d=008b fe49=009e fe0a=016d fe46=0164 fe16=008d fe1e=016c fe1a=0185 fe0e=0187 fe02=0179 Wrote 45 keycode(s) to driver Segmentation fault (core dumped) Is this just operator error? What further diagnostics would help? Vince PS evtest reports this about the device: # evtest /dev/input/event15 Input driver version is 1.0.1 Input device ID: bus 0x3 vendor 0xfe9 product 0xdb78 version 0x827b Input device name: "IR-receiver inside an USB DVB receiver" Supported events: Event type 0 (EV_SYN) Event type 1 (EV_KEY) ...<elided>... Event code 403 (KEY_CHANNELDOWN) Properties: Testing ... (interrupt to exit) ^C -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html