Re: ir-keytable: infinite loops, segfaults
On 3/1/17, Sean Young wrote: > > Sorry Vincent, but are you sure you're running the patch with the > & 0xff mask? That should have solved it. > er, no. Some kind of build issue. Once I applied your media_build patch and then the latest kernel patch you sent, this is what the test run looks like. # 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: 0x Repeat delay = 500 ms, repeat period = 125 ms Found /sys/class/rc/rc1/ (/dev/input/event15) with: Driver dvb_usb_cxusb, table rc-dvico-mce Supported protocols: nec Enabled protocols: Name: IR-receiver inside an USB DVB re bus: 3, vendor/product: 0fe9:db78, version: 0x827b Repeat delay = 500 ms, repeat period = 125 ms Found /sys/class/rc/rc2/ (/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 # ir-keytable -r -t -d /dev/input/event15 scancode 0x0101 = KEY_RECORD (0xa7) scancode 0x0102 = KEY_TV (0x179) scancode 0x0103 = KEY_0 (0x0b) scancode 0x0105 = KEY_VOLUMEDOWN (0x72) scancode 0x0107 = KEY_4 (0x05) scancode 0x0109 = KEY_CHANNELDOWN (0x193) scancode 0x010a = KEY_EPG (0x16d) scancode 0x010b = KEY_1 (0x02) scancode 0x010d = KEY_STOP (0x80) scancode 0x010e = KEY_MP3 (0x187) scancode 0x010f = KEY_PREVIOUSSONG (0xa5) scancode 0x0111 = KEY_CHANNELUP (0x192) scancode 0x0112 = KEY_NEXTSONG (0xa3) scancode 0x0113 = KEY_ANGLE (0x173) scancode 0x0115 = KEY_VOLUMEUP (0x73) scancode 0x0116 = KEY_SETUP (0x8d) scancode 0x0117 = KEY_2 (0x03) scancode 0x0119 = KEY_OPEN (0x86) scancode 0x011a = KEY_DVD (0x185) scancode 0x011b = KEY_3 (0x04) scancode 0x011e = KEY_FAVORITES (0x16c) scancode 0x011f = KEY_ZOOM (0x174) scancode 0x0142 = KEY_ENTER (0x1c) scancode 0x0143 = KEY_REWIND (0xa8) scancode 0x0146 = KEY_POWER2 (0x164) scancode 0x0147 = KEY_PLAYPAUSE (0xa4) scancode 0x0148 = KEY_7 (0x08) scancode 0x0149 = KEY_BACK (0x9e) scancode 0x014c = KEY_8 (0x09) scancode 0x014d = KEY_MENU (0x8b) scancode 0x014e = KEY_POWER (0x74) scancode 0x014f = KEY_FASTFORWARD (0xd0) scancode 0x0150 = KEY_5 (0x06) scancode 0x0151 = KEY_UP (0x67) scancode 0x0152 = KEY_CAMERA (0xd4) scancode 0x0153 = KEY_DOWN (0x6c) scancode 0x0154 = KEY_6 (0x07) scancode 0x0155 = KEY_TAB (0x0f) scancode 0x0157 = KEY_MUTE (0x71) scancode 0x0158 = KEY_9 (0x0a) scancode 0x0159 = KEY_INFO (0x166) scancode 0x015a = KEY_TUNER (0x182) scancode 0x015b = KEY_LEFT (0x69) scancode 0x015e = KEY_OK (0x160) scancode 0x015f = KEY_RIGHT (0x6a) Enabled protocols: unknown other rc-5 sanyo mce-kbd rc-6 sharp xmp Testing events. Please, press CTRL-C to abort. # 1 1488461383.614660: event type EV_MSC(0x04): scancode = 0x10b 1488461383.614660: event type EV_KEY(0x01) key_down: KEY_1(0x0002) 1488461383.614660: event type EV_SYN(0x00). 1488461383.865435: event type EV_KEY(0x01) key_up: KEY_1(0x0002) 1488461383.865435: event type EV_SYN(0x00). # 2 1488461394.150608: event type EV_MSC(0x04): scancode = 0x117 1488461394.150608: event type EV_KEY(0x01) key_down: KEY_2(0x0003) 1488461394.150608: event type EV_SYN(0x00). 1488461394.401431: event type EV_KEY(0x01) key_up: KEY_2(0x0003) 1488461394.401431: event type EV_SYN(0x00). # 8 1488461400.870636: event type EV_MSC(0x04): scancode = 0x14c 1488461400.870636: event type EV_KEY(0x01) key_down: KEY_8(0x0009) 1488461400.870636: event type EV_SYN(0x00). 1488461401.121430: event type EV_KEY(0x01) key_up: KEY_8(0x0009) 1488461401.121430: event type EV_SYN(0x00). # 9 1488461409.598593: event type EV_MSC(0x04): scancode = 0x158 1488461409.598593: event type EV_KEY(0x01) key_down: KEY_9(0x000a) 1488461409.598593: event type EV_SYN(0x00). 1488461409.849430: event type EV_KEY(0x01) key_up: KEY_9(0x000a) 1488461409.849430: event type EV_SYN(0x00). # vol_dn 1488461418.530615: event type EV_MSC(0x04): scancode = 0x105 1488461418.530615: event type EV_KEY(0x01) key_down: KEY_VOLUMEDOWN(0x0072) 1488461418.530615: event type EV_SYN(0x00). 1488461418.781443: event type EV_KEY(0x01) key_up: KEY_VOLUMEDOWN(0x0072) 1488461418.781443: event type EV_SYN(0x00). # vol_up 1488461428.490659: event type EV_MSC(0x04): scancode = 0x115 1488461428.490659: event type EV_KEY(0x01) key_down: KEY_VOLUMEUP(0x0073) 1488461428.490659: event type EV_SYN(0x00). 1488461428.741432: event type EV_KEY(0x01) key_up: KEY_VOLUMEUP(0x0073) 1488461428.741432: event type EV_SYN(0x00). # down arrow 1488461441.650689: event type EV_MSC(0x04): scancode = 0x153 1488461441.650689: event type EV_KEY(0x01) key_down: KEY_DOWN(0x006c) 1488461441.650689: event type EV_SYN(0x00). 1488461441.901433: event type EV_KEY(0x01) key_up: KEY_DOWN(0x006c)
Re: ir-keytable: infinite loops, segfaults
On Sat, Feb 25, 2017 at 02:08:39AM +1100, Vincent McIntyre wrote: > On 2/22/17, Sean Young wrote: > > > So it's still using the old keymap. I've attached a new one. > > That works, thanks. > > >> # vol down > >> 1487676637.746348: event type EV_MSC(0x04): scancode = 0x0105 > >> 1487676637.746348: event type EV_SYN(0x00). > >> # vol up > >> 1487676642.746321: event type EV_MSC(0x04): scancode = 0x0115 > >> 1487676642.746321: event type EV_SYN(0x00). > > > > Oops, that's a bug. 0x should be 0x. I've attached a new version of > > the patch which should fix that. > > > > I am still getting the high bits set. I checked the code and the patch > was correctly applied, > I see where you are applying a 0xff mask to the ircode values. > > > Test run: > # 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: 0x > Repeat delay = 500 ms, repeat period = 125 ms > Found /sys/class/rc/rc1/ (/dev/input/event15) with: > Driver dvb_usb_cxusb, table rc-dvico-mce > Supported protocols: nec > Enabled protocols: > Name: IR-receiver inside an USB DVB re > bus: 3, vendor/product: 0fe9:db78, version: 0x827b > Repeat delay = 500 ms, repeat period = 125 ms > Found /sys/class/rc/rc2/ (/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 > > # ir-keytable -r -t -d /dev/input/event15 > scancode 0x0101 = KEY_RECORD (0xa7) > scancode 0x0102 = KEY_TV (0x179) > scancode 0x0103 = KEY_0 (0x0b) > scancode 0x0105 = KEY_VOLUMEDOWN (0x72) > scancode 0x0107 = KEY_4 (0x05) > scancode 0x0109 = KEY_CHANNELDOWN (0x193) > scancode 0x010a = KEY_EPG (0x16d) > scancode 0x010b = KEY_1 (0x02) > scancode 0x010d = KEY_STOP (0x80) > scancode 0x010e = KEY_MP3 (0x187) > scancode 0x010f = KEY_PREVIOUSSONG (0xa5) > scancode 0x0111 = KEY_CHANNELUP (0x192) > scancode 0x0112 = KEY_NEXTSONG (0xa3) > scancode 0x0113 = KEY_ANGLE (0x173) > scancode 0x0115 = KEY_VOLUMEUP (0x73) > scancode 0x0116 = KEY_SETUP (0x8d) > scancode 0x0117 = KEY_2 (0x03) > scancode 0x0119 = KEY_OPEN (0x86) > scancode 0x011a = KEY_DVD (0x185) > scancode 0x011b = KEY_3 (0x04) > scancode 0x011e = KEY_FAVORITES (0x16c) > scancode 0x011f = KEY_ZOOM (0x174) > scancode 0x0142 = KEY_ENTER (0x1c) > scancode 0x0143 = KEY_REWIND (0xa8) > scancode 0x0146 = KEY_POWER2 (0x164) > scancode 0x0147 = KEY_PLAYPAUSE (0xa4) > scancode 0x0148 = KEY_7 (0x08) > scancode 0x0149 = KEY_BACK (0x9e) > scancode 0x014c = KEY_8 (0x09) > scancode 0x014d = KEY_MENU (0x8b) > scancode 0x014e = KEY_POWER (0x74) > scancode 0x014f = KEY_FASTFORWARD (0xd0) > scancode 0x0150 = KEY_5 (0x06) > scancode 0x0151 = KEY_UP (0x67) > scancode 0x0152 = KEY_CAMERA (0xd4) > scancode 0x0153 = KEY_DOWN (0x6c) > scancode 0x0154 = KEY_6 (0x07) > scancode 0x0155 = KEY_TAB (0x0f) > scancode 0x0157 = KEY_MUTE (0x71) > scancode 0x0158 = KEY_9 (0x0a) > scancode 0x0159 = KEY_INFO (0x166) > scancode 0x015a = KEY_TUNER (0x182) > scancode 0x015b = KEY_LEFT (0x69) > scancode 0x015e = KEY_OK (0x160) > scancode 0x015f = KEY_RIGHT (0x6a) > Enabled protocols: other jvc sony nec sanyo mce-kbd rc-6 sharp xmp > Testing events. Please, press CTRL-C to abort. > # '1' > 1487948112.709532: event type EV_MSC(0x04): scancode = 0x010b > 1487948112.709532: event type EV_SYN(0x00). > # '2' > 1487948137.229455: event type EV_MSC(0x04): scancode = 0x0117 > 1487948137.229455: event type EV_SYN(0x00). > # '8' > 1487948233.341489: event type EV_MSC(0x04): scancode = 0x014c > 1487948233.341489: event type EV_SYN(0x00). > # '9' > 1487948248.417547: event type EV_MSC(0x04): scancode = 0x0158 > 1487948248.417547: event type EV_SYN(0x00). > # volume_down > 1487948270.537497: event type EV_MSC(0x04): scancode = 0x0105 > 1487948270.537497: event type EV_SYN(0x00). > # volume_up > 1487948464.425435: event type EV_MSC(0x04): scancode = 0x0115 > 1487948464.425435: event type EV_SYN(0x00). Sorry Vincent, but are you sure you're running the patch with the & 0xff mask? That should have solved it. Sean
Re: ir-keytable: infinite loops, segfaults
On 2/22/17, Sean Young wrote: > So it's still using the old keymap. I've attached a new one. That works, thanks. >> # vol down >> 1487676637.746348: event type EV_MSC(0x04): scancode = 0x0105 >> 1487676637.746348: event type EV_SYN(0x00). >> # vol up >> 1487676642.746321: event type EV_MSC(0x04): scancode = 0x0115 >> 1487676642.746321: event type EV_SYN(0x00). > > Oops, that's a bug. 0x should be 0x. I've attached a new version of > the patch which should fix that. > I am still getting the high bits set. I checked the code and the patch was correctly applied, I see where you are applying a 0xff mask to the ircode values. Test run: # 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: 0x Repeat delay = 500 ms, repeat period = 125 ms Found /sys/class/rc/rc1/ (/dev/input/event15) with: Driver dvb_usb_cxusb, table rc-dvico-mce Supported protocols: nec Enabled protocols: Name: IR-receiver inside an USB DVB re bus: 3, vendor/product: 0fe9:db78, version: 0x827b Repeat delay = 500 ms, repeat period = 125 ms Found /sys/class/rc/rc2/ (/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 # ir-keytable -r -t -d /dev/input/event15 scancode 0x0101 = KEY_RECORD (0xa7) scancode 0x0102 = KEY_TV (0x179) scancode 0x0103 = KEY_0 (0x0b) scancode 0x0105 = KEY_VOLUMEDOWN (0x72) scancode 0x0107 = KEY_4 (0x05) scancode 0x0109 = KEY_CHANNELDOWN (0x193) scancode 0x010a = KEY_EPG (0x16d) scancode 0x010b = KEY_1 (0x02) scancode 0x010d = KEY_STOP (0x80) scancode 0x010e = KEY_MP3 (0x187) scancode 0x010f = KEY_PREVIOUSSONG (0xa5) scancode 0x0111 = KEY_CHANNELUP (0x192) scancode 0x0112 = KEY_NEXTSONG (0xa3) scancode 0x0113 = KEY_ANGLE (0x173) scancode 0x0115 = KEY_VOLUMEUP (0x73) scancode 0x0116 = KEY_SETUP (0x8d) scancode 0x0117 = KEY_2 (0x03) scancode 0x0119 = KEY_OPEN (0x86) scancode 0x011a = KEY_DVD (0x185) scancode 0x011b = KEY_3 (0x04) scancode 0x011e = KEY_FAVORITES (0x16c) scancode 0x011f = KEY_ZOOM (0x174) scancode 0x0142 = KEY_ENTER (0x1c) scancode 0x0143 = KEY_REWIND (0xa8) scancode 0x0146 = KEY_POWER2 (0x164) scancode 0x0147 = KEY_PLAYPAUSE (0xa4) scancode 0x0148 = KEY_7 (0x08) scancode 0x0149 = KEY_BACK (0x9e) scancode 0x014c = KEY_8 (0x09) scancode 0x014d = KEY_MENU (0x8b) scancode 0x014e = KEY_POWER (0x74) scancode 0x014f = KEY_FASTFORWARD (0xd0) scancode 0x0150 = KEY_5 (0x06) scancode 0x0151 = KEY_UP (0x67) scancode 0x0152 = KEY_CAMERA (0xd4) scancode 0x0153 = KEY_DOWN (0x6c) scancode 0x0154 = KEY_6 (0x07) scancode 0x0155 = KEY_TAB (0x0f) scancode 0x0157 = KEY_MUTE (0x71) scancode 0x0158 = KEY_9 (0x0a) scancode 0x0159 = KEY_INFO (0x166) scancode 0x015a = KEY_TUNER (0x182) scancode 0x015b = KEY_LEFT (0x69) scancode 0x015e = KEY_OK (0x160) scancode 0x015f = KEY_RIGHT (0x6a) Enabled protocols: other jvc sony nec sanyo mce-kbd rc-6 sharp xmp Testing events. Please, press CTRL-C to abort. # '1' 1487948112.709532: event type EV_MSC(0x04): scancode = 0x010b 1487948112.709532: event type EV_SYN(0x00). # '2' 1487948137.229455: event type EV_MSC(0x04): scancode = 0x0117 1487948137.229455: event type EV_SYN(0x00). # '8' 1487948233.341489: event type EV_MSC(0x04): scancode = 0x014c 1487948233.341489: event type EV_SYN(0x00). # '9' 1487948248.417547: event type EV_MSC(0x04): scancode = 0x0158 1487948248.417547: event type EV_SYN(0x00). # volume_down 1487948270.537497: event type EV_MSC(0x04): scancode = 0x0105 1487948270.537497: event type EV_SYN(0x00). # volume_up 1487948464.425435: event type EV_MSC(0x04): scancode = 0x0115 1487948464.425435: event type EV_SYN(0x00). Cheers Vince
Re: ir-keytable: infinite loops, segfaults
On Wed, Feb 22, 2017 at 12:07:07AM +1100, Vincent McIntyre wrote: > On 2/21/17, Sean Young wrote: > >> $ sudo cat /sys/class/rc/rc1/protocols > >> nec > >> $ sudo sh > >> # echo "+rc-5 +nec +rc-6 +jvc +sony +rc-5-sz +sanyo +sharp +xmp" > > >> /sys/class/rc/rc1/protocols > >> bash: echo: write error: Invalid argument > >> # cat /sys/class/rc/rc1/protocols > >> nec > >> In kern.log I got: > >> kernel: [ 2293.491534] rc_core: Normal protocol change requested > >> kernel: [ 2293.491538] rc_core: Protocol switching not supported > >> > >> # echo "+nec" > /sys/class/rc/rc1/protocols > >> bash: echo: write error: Invalid argument > >> kernel: [ 2390.832476] rc_core: Normal protocol change requested > >> kernel: [ 2390.832481] rc_core: Protocol switching not supported > > > > That is expected. Does the the keymap actually work? > > > > ir-keytable -r -t > > Kind of important information, yes. Answer: not sure. I can see it > receiving something but none of the keys I pressed caused any reaction > on the application (mythtv) > > # 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: 0x > Repeat delay = 500 ms, repeat period = 125 ms > Found /sys/class/rc/rc1/ (/dev/input/event11) with: > Driver dvb_usb_cxusb, table rc-dvico-mce > Supported protocols: nec > Enabled protocols: > Name: IR-receiver inside an USB DVB re > bus: 3, vendor/product: 0fe9:db78, version: 0x827b > Repeat delay = 500 ms, repeat period = 125 ms > Found /sys/class/rc/rc2/ (/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 > > # ir-keytable -r -t -d /dev/input/event11 > scancode 0xfe01 = KEY_R (0x13) > scancode 0xfe02 = KEY_TV (0x179) > scancode 0xfe03 = KEY_0 (0x0b) > scancode 0xfe05 = KEY_VOLUMEDOWN (0x72) > scancode 0xfe07 = KEY_4 (0x05) > scancode 0xfe09 = KEY_CHANNELDOWN (0x193) > scancode 0xfe0a = KEY_EPG (0x16d) > scancode 0xfe0b = KEY_1 (0x02) > scancode 0xfe0d = KEY_ESC (0x01) > scancode 0xfe0e = KEY_MP3 (0x187) > scancode 0xfe0f = KEY_PREVIOUSSONG (0xa5) > scancode 0xfe11 = KEY_CHANNELUP (0x192) > scancode 0xfe12 = KEY_NEXTSONG (0xa3) > scancode 0xfe13 = KEY_ANGLE (0x173) > scancode 0xfe15 = KEY_VOLUMEUP (0x73) > scancode 0xfe16 = KEY_SETUP (0x8d) > scancode 0xfe17 = KEY_2 (0x03) > scancode 0xfe19 = KEY_OPEN (0x86) > scancode 0xfe1a = KEY_DVD (0x185) > scancode 0xfe1b = KEY_3 (0x04) > scancode 0xfe1e = KEY_FAVORITES (0x16c) > scancode 0xfe1f = KEY_ZOOM (0x174) > scancode 0xfe42 = KEY_ENTER (0x1c) > scancode 0xfe43 = KEY_REWIND (0xa8) > scancode 0xfe46 = KEY_POWER2 (0x164) > scancode 0xfe47 = KEY_P (0x19) > scancode 0xfe48 = KEY_7 (0x08) > scancode 0xfe49 = KEY_ESC (0x01) > scancode 0xfe4c = KEY_8 (0x09) > scancode 0xfe4d = KEY_M (0x32) > scancode 0xfe4e = KEY_POWER (0x74) > scancode 0xfe4f = KEY_FASTFORWARD (0xd0) > scancode 0xfe50 = KEY_5 (0x06) > scancode 0xfe51 = KEY_UP (0x67) > scancode 0xfe52 = KEY_CAMERA (0xd4) > scancode 0xfe53 = KEY_DOWN (0x6c) > scancode 0xfe54 = KEY_6 (0x07) > scancode 0xfe55 = KEY_TAB (0x0f) > scancode 0xfe57 = KEY_MUTE (0x71) > scancode 0xfe58 = KEY_9 (0x0a) > scancode 0xfe59 = KEY_INFO (0x166) > scancode 0xfe5a = KEY_TUNER (0x182) > scancode 0xfe5b = KEY_LEFT (0x69) > scancode 0xfe5e = KEY_ENTER (0x1c) > scancode 0xfe5f = KEY_RIGHT (0x6a) So it's still using the old keymap. I've attached a new one. > Enabled protocols: other sony nec sanyo mce-kbd rc-6 sharp xmp > Testing events. Please, press CTRL-C to abort. > # pressed '1' key > 1487676458.742329: event type EV_MSC(0x04): scancode = 0x010b > 1487676458.742329: event type EV_SYN(0x00). > # '2' > 1487676481.742284: event type EV_MSC(0x04): scancode = 0x0117 > 1487676481.742284: event type EV_SYN(0x00). > # '8' > 1487676504.842250: event type EV_MSC(0x04): scancode = 0x014c > 1487676504.842250: event type EV_SYN(0x00). > # '9' > 1487676506.542243: event type EV_MSC(0x04): scancode = 0x0158 > 1487676506.542243: event type EV_SYN(0x00). > # right-arrow > 1487676551.942312: event type EV_MSC(0x04): scancode = 0x015f > 1487676551.942312: event type EV_SYN(0x00). > # vol down > 1487676637.746348: event type EV_MSC(0x04): scancode = 0x0105 > 1487676637.746348: event type EV_SYN(0x00). > # vol up > 1487676642.746321: event type EV_MSC(0x04): scancode = 0x0115 > 1487676642.746321: event type EV_SYN(0x00). Oops, that's a bug. 0x should be 0x. I've attached a new version of the patch which should fix that. Sean From: Sean Young Subject: [PATCH] [media] cxusb: dvico remotes are nec Adjus
Re: ir-keytable: infinite loops, segfaults
On 2/21/17, Sean Young wrote: > Hi Vincent, > ... > > On the cxusb the protocol is now nec, and that is the only protocol it > supports, you can't change it. > doh! ok well that's all good then. >> $ sudo cat /sys/class/rc/rc1/protocols >> nec >> $ sudo sh >> # echo "+rc-5 +nec +rc-6 +jvc +sony +rc-5-sz +sanyo +sharp +xmp" > >> /sys/class/rc/rc1/protocols >> bash: echo: write error: Invalid argument >> # cat /sys/class/rc/rc1/protocols >> nec >> In kern.log I got: >> kernel: [ 2293.491534] rc_core: Normal protocol change requested >> kernel: [ 2293.491538] rc_core: Protocol switching not supported >> >> # echo "+nec" > /sys/class/rc/rc1/protocols >> bash: echo: write error: Invalid argument >> kernel: [ 2390.832476] rc_core: Normal protocol change requested >> kernel: [ 2390.832481] rc_core: Protocol switching not supported > > That is expected. Does the the keymap actually work? > > ir-keytable -r -t Kind of important information, yes. Answer: not sure. I can see it receiving something but none of the keys I pressed caused any reaction on the application (mythtv) # 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: 0x Repeat delay = 500 ms, repeat period = 125 ms Found /sys/class/rc/rc1/ (/dev/input/event11) with: Driver dvb_usb_cxusb, table rc-dvico-mce Supported protocols: nec Enabled protocols: Name: IR-receiver inside an USB DVB re bus: 3, vendor/product: 0fe9:db78, version: 0x827b Repeat delay = 500 ms, repeat period = 125 ms Found /sys/class/rc/rc2/ (/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 # ir-keytable -r -t -d /dev/input/event11 scancode 0xfe01 = KEY_R (0x13) scancode 0xfe02 = KEY_TV (0x179) scancode 0xfe03 = KEY_0 (0x0b) scancode 0xfe05 = KEY_VOLUMEDOWN (0x72) scancode 0xfe07 = KEY_4 (0x05) scancode 0xfe09 = KEY_CHANNELDOWN (0x193) scancode 0xfe0a = KEY_EPG (0x16d) scancode 0xfe0b = KEY_1 (0x02) scancode 0xfe0d = KEY_ESC (0x01) scancode 0xfe0e = KEY_MP3 (0x187) scancode 0xfe0f = KEY_PREVIOUSSONG (0xa5) scancode 0xfe11 = KEY_CHANNELUP (0x192) scancode 0xfe12 = KEY_NEXTSONG (0xa3) scancode 0xfe13 = KEY_ANGLE (0x173) scancode 0xfe15 = KEY_VOLUMEUP (0x73) scancode 0xfe16 = KEY_SETUP (0x8d) scancode 0xfe17 = KEY_2 (0x03) scancode 0xfe19 = KEY_OPEN (0x86) scancode 0xfe1a = KEY_DVD (0x185) scancode 0xfe1b = KEY_3 (0x04) scancode 0xfe1e = KEY_FAVORITES (0x16c) scancode 0xfe1f = KEY_ZOOM (0x174) scancode 0xfe42 = KEY_ENTER (0x1c) scancode 0xfe43 = KEY_REWIND (0xa8) scancode 0xfe46 = KEY_POWER2 (0x164) scancode 0xfe47 = KEY_P (0x19) scancode 0xfe48 = KEY_7 (0x08) scancode 0xfe49 = KEY_ESC (0x01) scancode 0xfe4c = KEY_8 (0x09) scancode 0xfe4d = KEY_M (0x32) scancode 0xfe4e = KEY_POWER (0x74) scancode 0xfe4f = KEY_FASTFORWARD (0xd0) scancode 0xfe50 = KEY_5 (0x06) scancode 0xfe51 = KEY_UP (0x67) scancode 0xfe52 = KEY_CAMERA (0xd4) scancode 0xfe53 = KEY_DOWN (0x6c) scancode 0xfe54 = KEY_6 (0x07) scancode 0xfe55 = KEY_TAB (0x0f) scancode 0xfe57 = KEY_MUTE (0x71) scancode 0xfe58 = KEY_9 (0x0a) scancode 0xfe59 = KEY_INFO (0x166) scancode 0xfe5a = KEY_TUNER (0x182) scancode 0xfe5b = KEY_LEFT (0x69) scancode 0xfe5e = KEY_ENTER (0x1c) scancode 0xfe5f = KEY_RIGHT (0x6a) Enabled protocols: other sony nec sanyo mce-kbd rc-6 sharp xmp Testing events. Please, press CTRL-C to abort. # pressed '1' key 1487676458.742329: event type EV_MSC(0x04): scancode = 0x010b 1487676458.742329: event type EV_SYN(0x00). # '2' 1487676481.742284: event type EV_MSC(0x04): scancode = 0x0117 1487676481.742284: event type EV_SYN(0x00). # '8' 1487676504.842250: event type EV_MSC(0x04): scancode = 0x014c 1487676504.842250: event type EV_SYN(0x00). # '9' 1487676506.542243: event type EV_MSC(0x04): scancode = 0x0158 1487676506.542243: event type EV_SYN(0x00). # right-arrow 1487676551.942312: event type EV_MSC(0x04): scancode = 0x015f 1487676551.942312: event type EV_SYN(0x00). # vol down 1487676637.746348: event type EV_MSC(0x04): scancode = 0x0105 1487676637.746348: event type EV_SYN(0x00). # vol up 1487676642.746321: event type EV_MSC(0x04): scancode = 0x0115 1487676642.746321: event type EV_SYN(0x00). # cat /sys/class/rc/rc1/protocols nec All the above was done with the system booted with this in /etc/rc.local /usr/bin/ir-keytable -s rc1 -c /usr/bin/ir-keytable -s rc1 -w /etc/rc_keymaps/dvico-remote After I disabled the rc.local script and rebooted: # ir-keytable Found /sys/class/rc/rc0/ (/dev/input/event10) with: Driver imon, table rc-imon-mce Supported protocols: rc-6
Re: ir-keytable: infinite loops, segfaults
Hi Vincent, Thanks for testing this. On Fri, Feb 17, 2017 at 12:05:50AM +1100, Vincent McIntyre wrote: > Hi again > > after you kindly fixed media_build for me I applied the nec protocol > patch and tried again. > > $ sudo 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: 0x > Repeat delay = 500 ms, repeat period = 125 ms > Found /sys/class/rc/rc1/ (/dev/input/event11) with: > Driver dvb_usb_cxusb, table rc-dvico-mce > Supported protocols: nec > Enabled protocols: > Name: IR-receiver inside an USB DVB re > bus: 3, vendor/product: 0fe9:db78, version: 0x827b > Repeat delay = 500 ms, repeat period = 125 ms > Found /sys/class/rc/rc2/ (/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 > > $ sudo ir-keytable -v --sysdev rc1 > Found device /sys/class/rc/rc0/ > Found device /sys/class/rc/rc1/ > Found device /sys/class/rc/rc2/ > Input sysfs node is /sys/class/rc/rc0/input8/ > Event sysfs node is /sys/class/rc/rc0/input8/event5/ > Parsing uevent /sys/class/rc/rc0/input8/event5/uevent > /sys/class/rc/rc0/input8/event5/uevent uevent MAJOR=13 > /sys/class/rc/rc0/input8/event5/uevent uevent MINOR=69 > /sys/class/rc/rc0/input8/event5/uevent uevent DEVNAME=input/event5 > Parsing uevent /sys/class/rc/rc0/uevent > /sys/class/rc/rc0/uevent uevent NAME=rc-imon-mce > /sys/class/rc/rc0/uevent uevent DRV_NAME=imon > input device is /dev/input/event5 > /sys/class/rc/rc0/protocols protocol rc-6 (enabled) > 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: 0x > Repeat delay = 500 ms, repeat period = 125 ms > Input sysfs node is /sys/class/rc/rc1/input17/ > Event sysfs node is /sys/class/rc/rc1/input17/event11/ > Parsing uevent /sys/class/rc/rc1/input17/event11/uevent > /sys/class/rc/rc1/input17/event11/uevent uevent MAJOR=13 > /sys/class/rc/rc1/input17/event11/uevent uevent MINOR=75 > /sys/class/rc/rc1/input17/event11/uevent uevent DEVNAME=input/event11 > Parsing uevent /sys/class/rc/rc1/uevent > /sys/class/rc/rc1/uevent uevent NAME=rc-dvico-mce > /sys/class/rc/rc1/uevent uevent DRV_NAME=dvb_usb_cxusb > input device is /dev/input/event11 > /sys/class/rc/rc1/protocols protocol nec (disabled) > Found /sys/class/rc/rc1/ (/dev/input/event11) with: > Driver dvb_usb_cxusb, table rc-dvico-mce > Supported protocols: nec > Enabled protocols: > Name: IR-receiver inside an USB DVB re > bus: 3, vendor/product: 0fe9:db78, version: 0x827b > Repeat delay = 500 ms, repeat period = 125 ms > Input sysfs node is /sys/class/rc/rc2/input19/ > Event sysfs node is /sys/class/rc/rc2/input19/event16/ > Parsing uevent /sys/class/rc/rc2/input19/event16/uevent > /sys/class/rc/rc2/input19/event16/uevent uevent MAJOR=13 > /sys/class/rc/rc2/input19/event16/uevent uevent MINOR=80 > /sys/class/rc/rc2/input19/event16/uevent uevent DEVNAME=input/event16 > Parsing uevent /sys/class/rc/rc2/uevent > /sys/class/rc/rc2/uevent uevent NAME=rc-empty > /sys/class/rc/rc2/uevent uevent DRV_NAME=dvb_usb_af9035 > input device is /dev/input/event16 > /sys/class/rc/rc2/protocols protocol nec (disabled) > Found /sys/class/rc/rc2/ (/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 > > So only rc0 has any protocols enabled. Let's try to enable nec on rc1 > > $ sudo /usr/bin/ir-keytable -s rc1 -c > Old keytable cleared > $ sudo /usr/bin/ir-keytable -s rc1 -w /etc/rc_keymaps/dvico-remote > Read dvico_mce table > Wrote 45 keycode(s) to driver > Invalid protocols selected > Couldn't change the IR protocols > $ sudo /usr/bin/ir-keytable -s rc1 -p nec -v > Found device /sys/class/rc/rc0/ > Found device /sys/class/rc/rc1/ > Found device /sys/class/rc/rc2/ > Input sysfs node is /sys/class/rc/rc1/input17/ > Event sysfs node is /sys/class/rc/rc1/input17/event11/ > Parsing uevent /sys/class/rc/rc1/input17/event11/uevent > /sys/class/rc/rc1/input17/event11/uevent uevent MAJOR=13 > /sys/class/rc/rc1/input17/event11/uevent uevent MINOR=75 > /sys/class/rc/rc1/input17/event11/uevent uevent DEVNAME=input/event11 > Parsing uevent /sys/class/rc/rc1/uevent > /sys/c
Fwd: [regression] dvb_usb_cxusb (was Re: ir-keytable: infinite loops, segfaults)
Hi list I missed you in the cc: field... -- Forwarded message -- From: Vincent McIntyre Date: Thu, 16 Feb 2017 23:51:05 +1100 Subject: Re: [regression] dvb_usb_cxusb (was Re: ir-keytable: infinite loops, segfaults) To: Sean Young On 2/16/17, Sean Young wrote: > > The problem is that DVB_USB_CXUSB Kconfig has this line: > select DVB_SI2168 if MEDIA_SUBDRV_AUTOSELECT > The make_kconfig.pl script transforms this into a dependency, but > DVB_SI2168 is only available when compiling against kernel 4.7 or later. > I think only one select line needs to match, so I created this patch. > > Please apply this patch against media_build, you might need to do make > clean before building again. Awsome - build is working again, thank you. See the other thread for my progress report. > Thanks, > > Sean > > > From: Sean Young > Date: Wed, 15 Feb 2017 14:58:00 + > Subject: [PATCH] only one select Kconfig needs to match Tested-by: vincent.mcint...@gmail.com > --- > v4l/scripts/make_kconfig.pl | 20 +++- > 1 file changed, 19 insertions(+), 1 deletion(-) > > diff --git a/v4l/scripts/make_kconfig.pl b/v4l/scripts/make_kconfig.pl > index ba8c134..a11f820 100755 > --- a/v4l/scripts/make_kconfig.pl > +++ b/v4l/scripts/make_kconfig.pl > @@ -169,6 +169,7 @@ sub depends($$) > push @{$depends{$key}}, $deps; > } > > +my %selectdepends = (); > sub selects($$$) > { > my $key = shift; > @@ -181,7 +182,7 @@ sub selects($$$) > # Transform "select X if Y" into "depends on !Y || X" > $select = "!($if) || ($select)"; > } > - push @{$depends{$key}}, $select; > + push @{$selectdepends{$key}}, $select; > } > > # Needs: > @@ -228,6 +229,23 @@ sub checkdeps() > return 0; > } > } > + my $selectdeps = $selectdepends{$key}; > + if ($selectdeps) { > + my $found = 0; > + foreach (@$selectdeps) { > + next if($_ eq ''); > + if (eval(toperl($_))) { > + $found = 1; > + last; > + } > + } > + if ($found == 0) { > + print "Disabling $key, select dependency '$_' > not met\n" if $debug; > + $allconfig{$key} = 0; > + return 0; > + } > + } > + > return 1; > } > > -- > 2.7.4 Vince
Re: ir-keytable: infinite loops, segfaults
The dmesg... dmesg.txt.gz Description: GNU Zip compressed data
Re: ir-keytable: infinite loops, segfaults
Hi again after you kindly fixed media_build for me I applied the nec protocol patch and tried again. $ sudo 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: 0x Repeat delay = 500 ms, repeat period = 125 ms Found /sys/class/rc/rc1/ (/dev/input/event11) with: Driver dvb_usb_cxusb, table rc-dvico-mce Supported protocols: nec Enabled protocols: Name: IR-receiver inside an USB DVB re bus: 3, vendor/product: 0fe9:db78, version: 0x827b Repeat delay = 500 ms, repeat period = 125 ms Found /sys/class/rc/rc2/ (/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 $ sudo ir-keytable -v --sysdev rc1 Found device /sys/class/rc/rc0/ Found device /sys/class/rc/rc1/ Found device /sys/class/rc/rc2/ Input sysfs node is /sys/class/rc/rc0/input8/ Event sysfs node is /sys/class/rc/rc0/input8/event5/ Parsing uevent /sys/class/rc/rc0/input8/event5/uevent /sys/class/rc/rc0/input8/event5/uevent uevent MAJOR=13 /sys/class/rc/rc0/input8/event5/uevent uevent MINOR=69 /sys/class/rc/rc0/input8/event5/uevent uevent DEVNAME=input/event5 Parsing uevent /sys/class/rc/rc0/uevent /sys/class/rc/rc0/uevent uevent NAME=rc-imon-mce /sys/class/rc/rc0/uevent uevent DRV_NAME=imon input device is /dev/input/event5 /sys/class/rc/rc0/protocols protocol rc-6 (enabled) 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: 0x Repeat delay = 500 ms, repeat period = 125 ms Input sysfs node is /sys/class/rc/rc1/input17/ Event sysfs node is /sys/class/rc/rc1/input17/event11/ Parsing uevent /sys/class/rc/rc1/input17/event11/uevent /sys/class/rc/rc1/input17/event11/uevent uevent MAJOR=13 /sys/class/rc/rc1/input17/event11/uevent uevent MINOR=75 /sys/class/rc/rc1/input17/event11/uevent uevent DEVNAME=input/event11 Parsing uevent /sys/class/rc/rc1/uevent /sys/class/rc/rc1/uevent uevent NAME=rc-dvico-mce /sys/class/rc/rc1/uevent uevent DRV_NAME=dvb_usb_cxusb input device is /dev/input/event11 /sys/class/rc/rc1/protocols protocol nec (disabled) Found /sys/class/rc/rc1/ (/dev/input/event11) with: Driver dvb_usb_cxusb, table rc-dvico-mce Supported protocols: nec Enabled protocols: Name: IR-receiver inside an USB DVB re bus: 3, vendor/product: 0fe9:db78, version: 0x827b Repeat delay = 500 ms, repeat period = 125 ms Input sysfs node is /sys/class/rc/rc2/input19/ Event sysfs node is /sys/class/rc/rc2/input19/event16/ Parsing uevent /sys/class/rc/rc2/input19/event16/uevent /sys/class/rc/rc2/input19/event16/uevent uevent MAJOR=13 /sys/class/rc/rc2/input19/event16/uevent uevent MINOR=80 /sys/class/rc/rc2/input19/event16/uevent uevent DEVNAME=input/event16 Parsing uevent /sys/class/rc/rc2/uevent /sys/class/rc/rc2/uevent uevent NAME=rc-empty /sys/class/rc/rc2/uevent uevent DRV_NAME=dvb_usb_af9035 input device is /dev/input/event16 /sys/class/rc/rc2/protocols protocol nec (disabled) Found /sys/class/rc/rc2/ (/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 So only rc0 has any protocols enabled. Let's try to enable nec on rc1 $ sudo /usr/bin/ir-keytable -s rc1 -c Old keytable cleared $ sudo /usr/bin/ir-keytable -s rc1 -w /etc/rc_keymaps/dvico-remote Read dvico_mce table Wrote 45 keycode(s) to driver Invalid protocols selected Couldn't change the IR protocols $ sudo /usr/bin/ir-keytable -s rc1 -p nec -v Found device /sys/class/rc/rc0/ Found device /sys/class/rc/rc1/ Found device /sys/class/rc/rc2/ Input sysfs node is /sys/class/rc/rc1/input17/ Event sysfs node is /sys/class/rc/rc1/input17/event11/ Parsing uevent /sys/class/rc/rc1/input17/event11/uevent /sys/class/rc/rc1/input17/event11/uevent uevent MAJOR=13 /sys/class/rc/rc1/input17/event11/uevent uevent MINOR=75 /sys/class/rc/rc1/input17/event11/uevent uevent DEVNAME=input/event11 Parsing uevent /sys/class/rc/rc1/uevent /sys/class/rc/rc1/uevent uevent NAME=rc-dvico-mce /sys/class/rc/rc1/uevent uevent DRV_NAME=dvb_usb_cxusb input device is /dev/input/event11 /sys/class/rc/rc1/protocols protocol nec (disabled) Opening /dev/input/event11 Input Protocol version: 0x00010001 /sys/class/rc/rc1//protocols: Invalid argument Couldn't change the IR pro
Re: [regression] dvb_usb_cxusb (was Re: ir-keytable: infinite loops, segfaults)
On Wed, Feb 08, 2017 at 10:30:30PM +1100, Vincent McIntyre wrote: > Hi > > I have been working with Sean on figuring out the protocol used by a > dvico remote. > I thought the patch he sent was at fault but I backed it out and tried again. > > I've attached a full dmesg but the core of it is when dvb_usb_cxusb > tries to load: > > [7.858907] WARNING: You are using an experimental version of the > media stack. > As the driver is backported to an older kernel, it doesn't > offer > enough quality for its usage in production. > Use it with care. >Latest git patches (needed if you report a bug to > linux-media@vger.kernel.org): > 47b037a0512d9f8675ec2693bed46c8ea6a884ab [media] > v4l2-async: failing functions shouldn't have side effects > 79a2eda80c6dab79790c308d9f50ecd2e5021ba3 [media] > mantis_dvb: fix some error codes in mantis_dvb_init() > c2987aaf0c9c2bcb0d4c5902d61473d9aa018a3d [media] > exynos-gsc: Avoid spamming the log on VIDIOC_TRY_FMT > [7.861968] dvb_usb_af9035 1-4:1.0: prechip_version=83 > chip_version=02 chip_type=9135 > [7.887476] dvb_usb_cxusb: disagrees about version of symbol Sorry about not getting back to you sooner, life got in the way. The problem here is that the dvb-usb-cxusb did not get selected, so it was not recompiled. The problem is that DVB_USB_CXUSB Kconfig has this line: select DVB_SI2168 if MEDIA_SUBDRV_AUTOSELECT The make_kconfig.pl script transforms this into a dependency, but DVB_SI2168 is only available when compiling against kernel 4.7 or later. I think only one select line needs to match, so I created this patch. Please apply this patch against media_build, you might need to do make clean before building again. Thanks, Sean From: Sean Young Date: Wed, 15 Feb 2017 14:58:00 + Subject: [PATCH] only one select Kconfig needs to match --- v4l/scripts/make_kconfig.pl | 20 +++- 1 file changed, 19 insertions(+), 1 deletion(-) diff --git a/v4l/scripts/make_kconfig.pl b/v4l/scripts/make_kconfig.pl index ba8c134..a11f820 100755 --- a/v4l/scripts/make_kconfig.pl +++ b/v4l/scripts/make_kconfig.pl @@ -169,6 +169,7 @@ sub depends($$) push @{$depends{$key}}, $deps; } +my %selectdepends = (); sub selects($$$) { my $key = shift; @@ -181,7 +182,7 @@ sub selects($$$) # Transform "select X if Y" into "depends on !Y || X" $select = "!($if) || ($select)"; } - push @{$depends{$key}}, $select; + push @{$selectdepends{$key}}, $select; } # Needs: @@ -228,6 +229,23 @@ sub checkdeps() return 0; } } + my $selectdeps = $selectdepends{$key}; + if ($selectdeps) { + my $found = 0; + foreach (@$selectdeps) { + next if($_ eq ''); + if (eval(toperl($_))) { + $found = 1; + last; + } + } + if ($found == 0) { + print "Disabling $key, select dependency '$_' not met\n" if $debug; + $allconfig{$key} = 0; + return 0; + } + } + return 1; } -- 2.7.4
Re: [regression] dvb_usb_cxusb (was Re: ir-keytable: infinite loops, segfaults)
ping? My media_build tree is updated as far as: $ git log -1 commit 0721d4bde661c71cd4e41de37afb24b0694c65a3 Author: Hans Verkuil Date: Mon Nov 21 13:17:19 2016 +0100 Only use Makefile.mm if frame_vector.c is present. Signed-off-by: Hans Verkuil > On Wed, Feb 08, 2017 at 10:30:30PM +1100, Vincent McIntyre wrote: >> Hi >> >> I have been working with Sean on figuring out the protocol used by a >> dvico remote. >> I thought the patch he sent was at fault but I backed it out and tried >> again. >> >> I've attached a full dmesg but the core of it is when dvb_usb_cxusb >> tries to load: >> >> [7.858907] WARNING: You are using an experimental version of the >> media stack. >> As the driver is backported to an older kernel, it doesn't >> offer >> enough quality for its usage in production. >> Use it with care. >>Latest git patches (needed if you report a bug to >> linux-media@vger.kernel.org): >> 47b037a0512d9f8675ec2693bed46c8ea6a884ab [media] >> v4l2-async: failing functions shouldn't have side effects >> 79a2eda80c6dab79790c308d9f50ecd2e5021ba3 [media] >> mantis_dvb: fix some error codes in mantis_dvb_init() >> c2987aaf0c9c2bcb0d4c5902d61473d9aa018a3d [media] >> exynos-gsc: Avoid spamming the log on VIDIOC_TRY_FMT >> [7.861968] dvb_usb_af9035 1-4:1.0: prechip_version=83 >> chip_version=02 chip_type=9135 >> [7.887476] dvb_usb_cxusb: disagrees about version of symbol >> dvb_usb_generic_rw >> [7.887477] dvb_usb_cxusb: Unknown symbol dvb_usb_generic_rw (err -22) >
Re: [regression] dvb_usb_cxusb (was Re: ir-keytable: infinite loops, segfaults)
Hi Vincent, On Wed, Feb 08, 2017 at 10:30:30PM +1100, Vincent McIntyre wrote: > Hi > > I have been working with Sean on figuring out the protocol used by a > dvico remote. > I thought the patch he sent was at fault but I backed it out and tried again. > > I've attached a full dmesg but the core of it is when dvb_usb_cxusb > tries to load: > > [7.858907] WARNING: You are using an experimental version of the > media stack. > As the driver is backported to an older kernel, it doesn't > offer > enough quality for its usage in production. > Use it with care. >Latest git patches (needed if you report a bug to > linux-media@vger.kernel.org): > 47b037a0512d9f8675ec2693bed46c8ea6a884ab [media] > v4l2-async: failing functions shouldn't have side effects > 79a2eda80c6dab79790c308d9f50ecd2e5021ba3 [media] > mantis_dvb: fix some error codes in mantis_dvb_init() > c2987aaf0c9c2bcb0d4c5902d61473d9aa018a3d [media] > exynos-gsc: Avoid spamming the log on VIDIOC_TRY_FMT > [7.861968] dvb_usb_af9035 1-4:1.0: prechip_version=83 > chip_version=02 chip_type=9135 > [7.887476] dvb_usb_cxusb: disagrees about version of symbol > dvb_usb_generic_rw > [7.887477] dvb_usb_cxusb: Unknown symbol dvb_usb_generic_rw (err -22) -snip- This is a problem with media_build. I'm not familiar with media_build, I did try it out last night (for the first time) and got the same issue on Ubuntu 16.04. I haven't been able to figure out what the problem is yet. I'll have a look again tonight or tomorrow night. In the mean time, if anyone else knows then that would be great. :) Sean -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[regression] dvb_usb_cxusb (was Re: ir-keytable: infinite loops, segfaults)
Hi I have been working with Sean on figuring out the protocol used by a dvico remote. I thought the patch he sent was at fault but I backed it out and tried again. I've attached a full dmesg but the core of it is when dvb_usb_cxusb tries to load: [7.858907] WARNING: You are using an experimental version of the media stack. As the driver is backported to an older kernel, it doesn't offer enough quality for its usage in production. Use it with care. Latest git patches (needed if you report a bug to linux-media@vger.kernel.org): 47b037a0512d9f8675ec2693bed46c8ea6a884ab [media] v4l2-async: failing functions shouldn't have side effects 79a2eda80c6dab79790c308d9f50ecd2e5021ba3 [media] mantis_dvb: fix some error codes in mantis_dvb_init() c2987aaf0c9c2bcb0d4c5902d61473d9aa018a3d [media] exynos-gsc: Avoid spamming the log on VIDIOC_TRY_FMT [7.861968] dvb_usb_af9035 1-4:1.0: prechip_version=83 chip_version=02 chip_type=9135 [7.887476] dvb_usb_cxusb: disagrees about version of symbol dvb_usb_generic_rw [7.887477] dvb_usb_cxusb: Unknown symbol dvb_usb_generic_rw (err -22) [7.887499] dvb_usb_cxusb: disagrees about version of symbol rc_keydown [7.887500] dvb_usb_cxusb: Unknown symbol rc_keydown (err -22) [7.887507] dvb_usb_cxusb: disagrees about version of symbol dib0070_wbd_offset [7.887508] dvb_usb_cxusb: Unknown symbol dib0070_wbd_offset (err -22) [7.887513] dvb_usb_cxusb: disagrees about version of symbol dvb_usb_device_init [7.887514] dvb_usb_cxusb: Unknown symbol dvb_usb_device_init (err -22) [7.887518] dvb_usb_cxusb: disagrees about version of symbol dvb_usb_generic_write [7.887519] dvb_usb_cxusb: Unknown symbol dvb_usb_generic_write (err -22) [7.900099] usb 1-4: dvb_usb_v2: found a 'Leadtek WinFast DTV Dongle Dual' in cold state [7.900768] usb 1-4: dvb_usb_v2: downloading firmware from file 'dvb-usb-it9135-02.fw' [8.124533] input: HDA NVidia HDMI/DP,pcm=3 as /devices/pci:00/:00:01.0/:01:00.1/sound/card1/input14 [8.124616] input: HDA NVidia HDMI/DP,pcm=7 as /devices/pci:00/:00:01.0/:01:00.1/sound/card1/input15 [8.124690] input: HDA NVidia HDMI/DP,pcm=8 as /devices/pci:00/:00:01.0/:01:00.1/sound/card1/input16 [8.124763] input: HDA NVidia HDMI/DP,pcm=9 as /devices/pci:00/:00:01.0/:01:00.1/sound/card1/input17 [8.144601] dvb_usb_cxusb: disagrees about version of symbol dvb_usb_generic_rw [8.144603] dvb_usb_cxusb: Unknown symbol dvb_usb_generic_rw (err -22) [8.144638] dvb_usb_cxusb: disagrees about version of symbol rc_keydown [8.144639] dvb_usb_cxusb: Unknown symbol rc_keydown (err -22) [8.144648] dvb_usb_cxusb: disagrees about version of symbol dib0070_wbd_offset [8.144649] dvb_usb_cxusb: Unknown symbol dib0070_wbd_offset (err -22) [8.144654] dvb_usb_cxusb: disagrees about version of symbol dvb_usb_device_init [8.144655] dvb_usb_cxusb: Unknown symbol dvb_usb_device_init (err -22) [8.144659] dvb_usb_cxusb: disagrees about version of symbol dvb_usb_generic_write [8.144660] dvb_usb_cxusb: Unknown symbol dvb_usb_generic_write (err -22) Vince [0.00] Initializing cgroup subsys cpuset [0.00] Initializing cgroup subsys cpu [0.00] Initializing cgroup subsys cpuacct [0.00] Linux version 4.4.0-59-generic (buildd@lgw01-11) (gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4) ) #80-Ubuntu SMP Fri Jan 6 17:47:47 UTC 2017 (Ubuntu 4.4.0-59.80-generic 4.4.35) [0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-4.4.0-59-generic root=UUID=420e8415-6799-4f8e-bb39-7d9077271ea6 ro [0.00] KERNEL supported cpus: [0.00] Intel GenuineIntel [0.00] AMD AuthenticAMD [0.00] Centaur CentaurHauls [0.00] x86/fpu: Legacy x87 FPU detected. [0.00] x86/fpu: Using 'lazy' FPU context switches. [0.00] e820: BIOS-provided physical RAM map: [0.00] BIOS-e820: [mem 0x-0x0009ebff] usable [0.00] BIOS-e820: [mem 0x0009ec00-0x0009] reserved [0.00] BIOS-e820: [mem 0x000e-0x000f] reserved [0.00] BIOS-e820: [mem 0x0010-0x7ed12fff] usable [0.00] BIOS-e820: [mem 0x7ed13000-0x7ed14fff] reserved [0.00] BIOS-e820: [mem 0x7ed15000-0x7ee2dfff] usable [0.00] BIOS-e820: [mem 0x7ee2e000-0x7eee4fff] ACPI NVS [0.00] BIOS-e820: [mem 0x7eee5000-0x7eee8fff] usable [0.00] BIOS-e820: [mem 0x7eee9000-0x7eef2fff] ACPI data [0.00] BIOS-e820: [mem 0x7eef3000-0x7eef3fff] usable [0.00] BIOS-e820: [mem 0x7eef4000-0x7eefefff] ACPI data [0.00] BIOS-e820: [mem 0x7eeff000-0x7eef] usable [0.00] BIOS-e
Re: ir-keytable: infinite loops, segfaults
I tried your patch, after disabling the custom keymap file I had put in. Unfortunately the remote isn't working at all. When the relevant modules get loaded I see this in dmesg [7.838223] media: Linux media interface: v0.10 [7.840484] WARNING: You are using an experimental version of the media stack. As the driver is backported to an older kernel, it doesn't offer enough quality for its usage in production. Use it with care. Latest git patches (needed if you report a bug to linux-media@vger.kernel.org): 47b037a0512d9f8675ec2693bed46c8ea6a884ab [media] v4l2-async: failing functions shouldn't have side effects 79a2eda80c6dab79790c308d9f50ecd2e5021ba3 [media] mantis_dvb: fix some error codes in mantis_dvb_init() c2987aaf0c9c2bcb0d4c5902d61473d9aa018a3d [media] exynos-gsc: Avoid spamming the log on VIDIOC_TRY_FMT [7.843667] dvb_usb_cxusb: disagrees about version of symbol dvb_usb_generic_rw [7.843669] dvb_usb_cxusb: Unknown symbol dvb_usb_generic_rw (err -22) [7.843692] dvb_usb_cxusb: disagrees about version of symbol rc_keydown [7.843693] dvb_usb_cxusb: Unknown symbol rc_keydown (err -22) [7.843701] dvb_usb_cxusb: disagrees about version of symbol dib0070_wbd_offset [7.843702] dvb_usb_cxusb: Unknown symbol dib0070_wbd_offset (err -22) [7.843707] dvb_usb_cxusb: disagrees about version of symbol dvb_usb_device_init [7.843708] dvb_usb_cxusb: Unknown symbol dvb_usb_device_init (err -22) [7.843712] dvb_usb_cxusb: disagrees about version of symbol dvb_usb_generic_write [7.843713] dvb_usb_cxusb: Unknown symbol dvb_usb_generic_write (err -22) [8.089033] dvb_usb_cxusb: disagrees about version of symbol dvb_usb_generic_rw [8.089035] dvb_usb_cxusb: Unknown symbol dvb_usb_generic_rw (err -22) [8.089068] dvb_usb_cxusb: disagrees about version of symbol rc_keydown [8.089070] dvb_usb_cxusb: Unknown symbol rc_keydown (err -22) [8.089079] dvb_usb_cxusb: disagrees about version of symbol dib0070_wbd_offset [8.089080] dvb_usb_cxusb: Unknown symbol dib0070_wbd_offset (err -22) [8.089085] dvb_usb_cxusb: disagrees about version of symbol dvb_usb_device_init [8.089086] dvb_usb_cxusb: Unknown symbol dvb_usb_device_init (err -22) [8.089090] dvb_usb_cxusb: disagrees about version of symbol dvb_usb_generic_write [8.089091] dvb_usb_cxusb: Unknown symbol dvb_usb_generic_write (err -22) A manual modprobe gives this: # modprobe -v dvb_usb_cxusb insmod /lib/modules/4.4.0-59-generic/kernel/drivers/media/usb/dvb-usb/dvb-usb-cxusb.ko modprobe: ERROR: could not insert 'dvb_usb_cxusb': Invalid argument # dmesg [ 547.365417] dvb_usb_cxusb: disagrees about version of symbol dvb_usb_generic_rw [ 547.365422] dvb_usb_cxusb: Unknown symbol dvb_usb_generic_rw (err -22) [ 547.365461] dvb_usb_cxusb: disagrees about version of symbol rc_keydown [ 547.365463] dvb_usb_cxusb: Unknown symbol rc_keydown (err -22) [ 547.365475] dvb_usb_cxusb: disagrees about version of symbol dib0070_wbd_offset [ 547.365477] dvb_usb_cxusb: Unknown symbol dib0070_wbd_offset (err -22) [ 547.365484] dvb_usb_cxusb: disagrees about version of symbol dvb_usb_device_init [ 547.365486] dvb_usb_cxusb: Unknown symbol dvb_usb_device_init (err -22) [ 547.365493] dvb_usb_cxusb: disagrees about version of symbol dvb_usb_generic_write [ 547.365495] dvb_usb_cxusb: Unknown symbol dvb_usb_generic_write (err -22) I was able to modprobe the rc-dvico-mce module, there was nothing in dmesg afterward though. Cheers Vince -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ir-keytable: infinite loops, segfaults
Hi Vincent, On Thu, Feb 02, 2017 at 10:18:52PM +1100, Vincent McIntyre wrote: > On 11/30/16, Vincent McIntyre wrote: > > On Sun, Nov 27, 2016 at 07:35:10PM +, Sean Young wrote: > >> > >> > I wanted to mention that the IR protocol is still showing as unknown. > >> > Is there anything that can be done to sort that out? > >> > >> It would be nice if that could be sorted out, although that would be > >> a separate patch. > >> > >> So all we know right now is what scancode the IR receiver hardware > >> produces but we have no idea what IR protocol is being used. In order to > >> figure this out we need a recording of the IR the remote sends, for which > >> a different IR receiver is needed. Neither your imon nor your > >> dvb_usb_af9035 can do this, something like a mce usb IR receiver would > >> be best. Do you have access to one? One with an IR emitter would be > >> best. > >> > >> So with that we can have a recording of the IR the remote sends, and > >> with the emitter we can see which IR protocols the IR receiver > >> understands. > > > > Haven't been able to find anything suitable. I would order something > > but I won't be able to follow up for several weeks. > > I'll ask on the myth list to see if anyone is up for trying this. > > > > I bought one of these, but I am not sure how to make the recording: > > # lsusb -d 1934:5168 -v > > Bus 008 Device 003: ID 1934:5168 Feature Integration Technology Inc. > (Fintek) F71610A or F71612A Consumer Infrared Receiver/Transceiver -snip- > Poking around I see lirc has an irrecord program. Is that what I need? That's great. There are a couple of ways of doing this, and none of them is straightforward. It's a bit of reading tea leaves (that's one of the motivations for my lirc-scancodes patches, but I digress). Method 1: echo "+rc-5 +nec +rc-6 +jvc +sony +rc-5-sz +sanyo +sharp +xmp" > /sys/class/rc/rc3/protocols echo 1 > /sys/module/rc_core/parameters/debug journal -f -k # press button on remote Now look for "scancode" somewhere in there. Method 2: Either use lirc's mode2 or "ir-ctl -r -d /dev/lircX" (from v4l-utils 1.12), and post the output here. Thanks! Sean -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ir-keytable: infinite loops, segfaults
Hey there On 11/30/16, Vincent McIntyre wrote: > On Sun, Nov 27, 2016 at 07:35:10PM +, Sean Young wrote: >> >> > I wanted to mention that the IR protocol is still showing as unknown. >> > Is there anything that can be done to sort that out? >> >> It would be nice if that could be sorted out, although that would be >> a separate patch. >> >> So all we know right now is what scancode the IR receiver hardware >> produces but we have no idea what IR protocol is being used. In order to >> figure this out we need a recording of the IR the remote sends, for which >> a different IR receiver is needed. Neither your imon nor your >> dvb_usb_af9035 can do this, something like a mce usb IR receiver would >> be best. Do you have access to one? One with an IR emitter would be >> best. >> >> So with that we can have a recording of the IR the remote sends, and >> with the emitter we can see which IR protocols the IR receiver >> understands. > > Haven't been able to find anything suitable. I would order something > but I won't be able to follow up for several weeks. > I'll ask on the myth list to see if anyone is up for trying this. > I bought one of these, but I am not sure how to make the recording: # lsusb -d 1934:5168 -v Bus 008 Device 003: ID 1934:5168 Feature Integration Technology Inc. (Fintek) F71610A or F71612A Consumer Infrared Receiver/Transceiver Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize016 idVendor 0x1934 Feature Integration Technology Inc. (Fintek) idProduct 0x5168 F71610A or F71612A Consumer Infrared Receiver/Transceiver bcdDevice0.01 iManufacturer 1 FINTEK iProduct2 eHome Infrared Transceiver iSerial 3 88636562727801 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 32 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xa0 (Bus Powered) Remote Wakeup MaxPower 100mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass255 Vendor Specific Subclass bInterfaceProtocol255 Vendor Specific Protocol iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes3 Transfer TypeInterrupt Synch Type None Usage Type Data wMaxPacketSize 0x0010 1x 16 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes3 Transfer TypeInterrupt Synch Type None Usage Type Data wMaxPacketSize 0x0010 1x 16 bytes bInterval 1 Device Status: 0x (Bus Powered) # ir-keytable -v Found device /sys/class/rc/rc0/ Found device /sys/class/rc/rc1/ Found device /sys/class/rc/rc2/ Found device /sys/class/rc/rc3/ < the new device Input sysfs node is /sys/class/rc/rc0/input8/ Event sysfs node is /sys/class/rc/rc0/input8/event5/ Parsing uevent /sys/class/rc/rc0/input8/event5/uevent /sys/class/rc/rc0/input8/event5/uevent uevent MAJOR=13 /sys/class/rc/rc0/input8/event5/uevent uevent MINOR=69 /sys/class/rc/rc0/input8/event5/uevent uevent DEVNAME=input/event5 Parsing uevent /sys/class/rc/rc0/uevent /sys/class/rc/rc0/uevent uevent NAME=rc-imon-mce /sys/class/rc/rc0/uevent uevent DRV_NAME=imon input device is /dev/input/event5 /sys/class/rc/rc0/protocols protocol rc-6 (enabled) 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: 0x Repeat delay = 500 ms, repeat period = 125 ms Input sysfs node is /sys/class/rc/rc1/input18/ Event sysfs node is /sys/class/rc/rc1/input18/event15/ Parsing uevent /sys/class/rc/rc1/input18/event15/uevent /sys/class/rc/rc1/input18/event15/uevent uevent MAJOR=13 /sys/class/rc/rc1/input18/event15/uevent uevent MINOR=79 /sys/class/rc/rc1/input18/event15/uevent uevent DEVNAME=input/event15 Parsing uevent /sys/class/rc/rc1/uevent /sys/class/rc/rc1/uevent uevent NAME=rc-dvico-mce /sys/class/rc/rc1/uevent uevent DRV_NAME=dvb_usb_cxusb i
Re: ir-keytable: infinite loops, segfaults
On Sun, Nov 27, 2016 at 07:35:10PM +, Sean Young wrote: > > > I wanted to mention that the IR protocol is still showing as unknown. > > Is there anything that can be done to sort that out? > > It would be nice if that could be sorted out, although that would be > a separate patch. > > So all we know right now is what scancode the IR receiver hardware > produces but we have no idea what IR protocol is being used. In order to > figure this out we need a recording of the IR the remote sends, for which > a different IR receiver is needed. Neither your imon nor your > dvb_usb_af9035 can do this, something like a mce usb IR receiver would > be best. Do you have access to one? One with an IR emitter would be > best. > > So with that we can have a recording of the IR the remote sends, and > with the emitter we can see which IR protocols the IR receiver > understands. Haven't been able to find anything suitable. I would order something but I won't be able to follow up for several weeks. I'll ask on the myth list to see if anyone is up for trying this. Thanks again for your help with this Vince -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ir-keytable: infinite loops, segfaults
On Sun, Nov 27, 2016 at 07:35:10PM +, Sean Young wrote: > > The application I am trying to use it with is the mythtv frontend. I > > am doing the keycode munging from an SSH session while myth is still > > running on the main screen. I didn't think this would matter (since it > > worked for KEY_OK->KEY_ENTER) but perhaps it does. Obviously > > ir-keytable -t intercepts the scancodes when it is running, but when I > > kill it myth responds normally to some keys, but not all. > > X and keycodes is a bit messy. You might need xmodmap mappings. You > can check them xev. I don't know much about this, I'm afraid. What > linux distribution, version and keyboard layout are you using? I could > try and see if I can reproduce/fix this. I mostly figured this out but something weird happens with the most significant bit (see my follow-on email). FWIW, this is on ubuntu 16.04 with their standard kernel (4.4) and a bog-standard US english layout. > > I wanted to mention that the IR protocol is still showing as unknown. > > Is there anything that can be done to sort that out? > > It would be nice if that could be sorted out, although that would be > a separate patch. That's fine. For the current patch, please feel free to add my Tested-By: vincent.mcint...@gmail.com > So all we know right now is what scancode the IR receiver hardware > produces but we have no idea what IR protocol is being used. In > order to figure this out we need a recording of the IR the remote > sends, for which a different IR receiver is needed. Neither your > imon nor your dvb_usb_af9035 can do this, something like a mce usb > IR receiver would be best. Do you have access to one? One with an IR > emitter would be best. > > So with that we can have a recording of the IR the remote sends, and > with the emitter we can see which IR protocols the IR receiver > understands. > I'll poke around to see if I can find something, will take a few days. Thanks again for your interest in this. Vince -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ir-keytable: infinite loops, segfaults
On Fri, Nov 25, 2016 at 07:59:21PM +1100, Vincent McIntyre wrote: > On 11/25/16, Sean Young wrote: > > > > So if I understand you correctly, if you change the keymap, like you > > changed 0xfe47 to KEY_PAUSE, then "ir-keytable -s rc1 -t" show you the > > correct (new) key? So as far as ir-keytable is concerned, everything > > works? > > > > However when you try to use the new mapping in some application then > > it does not work? > > That's correct. ir-keytable seems to be doing the right thing, mapping > the scancode to the input-event-codes.h key code I asked it to. ir-keytable reads from the input layer, so that's the key being sent. The problem is elsewhere. > The application I am trying to use it with is the mythtv frontend. I > am doing the keycode munging from an SSH session while myth is still > running on the main screen. I didn't think this would matter (since it > worked for KEY_OK->KEY_ENTER) but perhaps it does. Obviously > ir-keytable -t intercepts the scancodes when it is running, but when I > kill it myth responds normally to some keys, but not all. X and keycodes is a bit messy. You might need xmodmap mappings. You can check them xev. I don't know much about this, I'm afraid. What linux distribution, version and keyboard layout are you using? I could try and see if I can reproduce/fix this. > I wanted to mention that the IR protocol is still showing as unknown. > Is there anything that can be done to sort that out? It would be nice if that could be sorted out, although that would be a separate patch. So all we know right now is what scancode the IR receiver hardware produces but we have no idea what IR protocol is being used. In order to figure this out we need a recording of the IR the remote sends, for which a different IR receiver is needed. Neither your imon nor your dvb_usb_af9035 can do this, something like a mce usb IR receiver would be best. Do you have access to one? One with an IR emitter would be best. So with that we can have a recording of the IR the remote sends, and with the emitter we can see which IR protocols the IR receiver understands. Sean -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ir-keytable: infinite loops, segfaults
>> >> However when you try to use the new mapping in some application then >> it does not work? > > That's correct. ir-keytable seems to be doing the right thing, mapping > the scancode to the input-event-codes.h key code I asked it to. > > The application I am trying to use it with is the mythtv frontend. I > am doing the keycode munging from an SSH session while myth is still > running on the main screen. I didn't think this would matter (since it > worked for KEY_OK->KEY_ENTER) but perhaps it does. Obviously > ir-keytable -t intercepts the scancodes when it is running, but when I > kill it myth responds normally to some keys, but not all. It turned out that that I had to restart X to make it notice the updated keymap. After that, the modfied keymap I set up is mostly working. There is still a bit of a mystery. As I understand it, X should notice key codes less than 255 (0xff). But it seems to be ignoring KEY_STOP (code 128, 0x80) and any key codes higher than that but less than 255. ir-keytable -t shows the right codes. Vince -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ir-keytable: infinite loops, segfaults
On 11/25/16, Sean Young wrote: > > So if I understand you correctly, if you change the keymap, like you > changed 0xfe47 to KEY_PAUSE, then "ir-keytable -s rc1 -t" show you the > correct (new) key? So as far as ir-keytable is concerned, everything > works? > > However when you try to use the new mapping in some application then > it does not work? That's correct. ir-keytable seems to be doing the right thing, mapping the scancode to the input-event-codes.h key code I asked it to. The application I am trying to use it with is the mythtv frontend. I am doing the keycode munging from an SSH session while myth is still running on the main screen. I didn't think this would matter (since it worked for KEY_OK->KEY_ENTER) but perhaps it does. Obviously ir-keytable -t intercepts the scancodes when it is running, but when I kill it myth responds normally to some keys, but not all. I wanted to mention that the IR protocol is still showing as unknown. Is there anything that can be done to sort that out? Vince -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ir-keytable: infinite loops, segfaults
On Thu, Nov 24, 2016 at 11:12:57PM +1100, Vincent McIntyre wrote: > On Wed, Nov 23, 2016 at 10:34:19PM +, Sean Young wrote: > > > Not sure why Driver is (null), dvb_usb_cxusb is loaded. > > > > That's a mistake, I've fixed that now. > > Ah. I see the added module_name struct members. > > > > I tried -t and it generated events constantly, before I could press > > > any keys. > > > # ir-keytable -s rc1 -t > > > Testing events. Please, press CTRL-C to abort. > > > 1479903007.535509: event type EV_MSC(0x04): scancode = 0x00 > > > 1479903007.535509: event type EV_SYN(0x00). > > > 1479903007.635521: event type EV_MSC(0x04): scancode = 0x00 > > > > That's also been fixed. > > > > yep, works nicely. > > Things are looking much better! > As shown below I am able to clear a keytable and put in a fresh one. > Having a bit of trouble with key remapping. > I guess we still have to work out the protocol in use. > > Test details: > # ir-keytable -v > Found device /sys/class/rc/rc0/ > Found device /sys/class/rc/rc1/ > Found device /sys/class/rc/rc2/ > Input sysfs node is /sys/class/rc/rc0/input8/ > Event sysfs node is /sys/class/rc/rc0/input8/event5/ > Parsing uevent /sys/class/rc/rc0/input8/event5/uevent > /sys/class/rc/rc0/input8/event5/uevent uevent MAJOR=13 > /sys/class/rc/rc0/input8/event5/uevent uevent MINOR=69 > /sys/class/rc/rc0/input8/event5/uevent uevent DEVNAME=input/event5 > Parsing uevent /sys/class/rc/rc0/uevent > /sys/class/rc/rc0/uevent uevent NAME=rc-imon-mce > /sys/class/rc/rc0/uevent uevent DRV_NAME=imon > input device is /dev/input/event5 > /sys/class/rc/rc0/protocols protocol rc-6 (enabled) > 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: 0x > Input sysfs node is /sys/class/rc/rc1/input18/ > Event sysfs node is /sys/class/rc/rc1/input18/event15/ > Parsing uevent /sys/class/rc/rc1/input18/event15/uevent > /sys/class/rc/rc1/input18/event15/uevent uevent MAJOR=13 > /sys/class/rc/rc1/input18/event15/uevent uevent MINOR=79 > /sys/class/rc/rc1/input18/event15/uevent uevent DEVNAME=input/event15 > Parsing uevent /sys/class/rc/rc1/uevent > /sys/class/rc/rc1/uevent uevent NAME=rc-dvico-mce > /sys/class/rc/rc1/uevent uevent DRV_NAME=dvb_usb_cxusb > input device is /dev/input/event15 > /sys/class/rc/rc1/protocols protocol unknown (disabled) > Found /sys/class/rc/rc1/ (/dev/input/event15) with: > Driver dvb_usb_cxusb, table rc-dvico-mce > Supported protocols: unknown > Enabled protocols: > Name: IR-receiver inside an USB DVB re > bus: 3, vendor/product: 0fe9:db78, version: 0x827b > Input sysfs node is /sys/class/rc/rc2/input19/ > Event sysfs node is /sys/class/rc/rc2/input19/event16/ > Parsing uevent /sys/class/rc/rc2/input19/event16/uevent > /sys/class/rc/rc2/input19/event16/uevent uevent MAJOR=13 > /sys/class/rc/rc2/input19/event16/uevent uevent MINOR=80 > /sys/class/rc/rc2/input19/event16/uevent uevent DEVNAME=input/event16 > Parsing uevent /sys/class/rc/rc2/uevent > /sys/class/rc/rc2/uevent uevent NAME=rc-empty > /sys/class/rc/rc2/uevent uevent DRV_NAME=dvb_usb_af9035 > input device is /dev/input/event16 > /sys/class/rc/rc2/protocols protocol nec (disabled) > Found /sys/class/rc/rc2/ (/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 > Repeat delay = 500 ms, repeat period = 125 ms > Repeat delay = 500 ms, repeat period = 125 ms > > # ir-keytable -r -v -s rc1 > Found device /sys/class/rc/rc0/ > Found device /sys/class/rc/rc1/ > Found device /sys/class/rc/rc2/ > Input sysfs node is /sys/class/rc/rc1/input18/ > Event sysfs node is /sys/class/rc/rc1/input18/event15/ > Parsing uevent /sys/class/rc/rc1/input18/event15/uevent > /sys/class/rc/rc1/input18/event15/uevent uevent MAJOR=13 > /sys/class/rc/rc1/input18/event15/uevent uevent MINOR=79 > /sys/class/rc/rc1/input18/event15/uevent uevent DEVNAME=input/event15 > Parsing uevent /sys/class/rc/rc1/uevent > /sys/class/rc/rc1/uevent uevent NAME=rc-dvico-mce > /sys/class/rc/rc1/uevent uevent DRV_NAME=dvb_usb_cxusb > input device is /dev/input/event15 > /sys/class/rc/rc1/protocols protocol unknown (disabled) > Opening /dev/input/event15 > Input Protocol version: 0x00010001 > Enabled protocols: > scancode 0xfe01 = KEY_RECORD (0xa7) > scancode 0xfe02 = KEY_TV (0x179) > scancode 0xfe03 = KEY_0 (0x0b) > scancode 0xfe05 = KEY_VOLUMEDOWN (0x72) > scancode 0xfe07 = KEY_4 (0x05) > scancode 0xfe09 = KEY_CHANNELDOWN (0x193) > scancode 0xfe0a = KEY_EPG (0x16d) > scancode 0xfe0b = KEY_1 (0x02) > scancode 0xfe0d = KEY_STOP (0x80) > scancode 0xfe0e = KEY_MP3 (0x187) > scancode 0xfe0f = KE
Re: ir-keytable: infinite loops, segfaults
On Wed, Nov 23, 2016 at 10:34:19PM +, Sean Young wrote: > > Not sure why Driver is (null), dvb_usb_cxusb is loaded. > > That's a mistake, I've fixed that now. Ah. I see the added module_name struct members. > > I tried -t and it generated events constantly, before I could press > > any keys. > > # ir-keytable -s rc1 -t > > Testing events. Please, press CTRL-C to abort. > > 1479903007.535509: event type EV_MSC(0x04): scancode = 0x00 > > 1479903007.535509: event type EV_SYN(0x00). > > 1479903007.635521: event type EV_MSC(0x04): scancode = 0x00 > > That's also been fixed. > yep, works nicely. Things are looking much better! As shown below I am able to clear a keytable and put in a fresh one. Having a bit of trouble with key remapping. I guess we still have to work out the protocol in use. Test details: # ir-keytable -v Found device /sys/class/rc/rc0/ Found device /sys/class/rc/rc1/ Found device /sys/class/rc/rc2/ Input sysfs node is /sys/class/rc/rc0/input8/ Event sysfs node is /sys/class/rc/rc0/input8/event5/ Parsing uevent /sys/class/rc/rc0/input8/event5/uevent /sys/class/rc/rc0/input8/event5/uevent uevent MAJOR=13 /sys/class/rc/rc0/input8/event5/uevent uevent MINOR=69 /sys/class/rc/rc0/input8/event5/uevent uevent DEVNAME=input/event5 Parsing uevent /sys/class/rc/rc0/uevent /sys/class/rc/rc0/uevent uevent NAME=rc-imon-mce /sys/class/rc/rc0/uevent uevent DRV_NAME=imon input device is /dev/input/event5 /sys/class/rc/rc0/protocols protocol rc-6 (enabled) 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: 0x Input sysfs node is /sys/class/rc/rc1/input18/ Event sysfs node is /sys/class/rc/rc1/input18/event15/ Parsing uevent /sys/class/rc/rc1/input18/event15/uevent /sys/class/rc/rc1/input18/event15/uevent uevent MAJOR=13 /sys/class/rc/rc1/input18/event15/uevent uevent MINOR=79 /sys/class/rc/rc1/input18/event15/uevent uevent DEVNAME=input/event15 Parsing uevent /sys/class/rc/rc1/uevent /sys/class/rc/rc1/uevent uevent NAME=rc-dvico-mce /sys/class/rc/rc1/uevent uevent DRV_NAME=dvb_usb_cxusb input device is /dev/input/event15 /sys/class/rc/rc1/protocols protocol unknown (disabled) Found /sys/class/rc/rc1/ (/dev/input/event15) with: Driver dvb_usb_cxusb, table rc-dvico-mce Supported protocols: unknown Enabled protocols: Name: IR-receiver inside an USB DVB re bus: 3, vendor/product: 0fe9:db78, version: 0x827b Input sysfs node is /sys/class/rc/rc2/input19/ Event sysfs node is /sys/class/rc/rc2/input19/event16/ Parsing uevent /sys/class/rc/rc2/input19/event16/uevent /sys/class/rc/rc2/input19/event16/uevent uevent MAJOR=13 /sys/class/rc/rc2/input19/event16/uevent uevent MINOR=80 /sys/class/rc/rc2/input19/event16/uevent uevent DEVNAME=input/event16 Parsing uevent /sys/class/rc/rc2/uevent /sys/class/rc/rc2/uevent uevent NAME=rc-empty /sys/class/rc/rc2/uevent uevent DRV_NAME=dvb_usb_af9035 input device is /dev/input/event16 /sys/class/rc/rc2/protocols protocol nec (disabled) Found /sys/class/rc/rc2/ (/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 Repeat delay = 500 ms, repeat period = 125 ms Repeat delay = 500 ms, repeat period = 125 ms # ir-keytable -r -v -s rc1 Found device /sys/class/rc/rc0/ Found device /sys/class/rc/rc1/ Found device /sys/class/rc/rc2/ Input sysfs node is /sys/class/rc/rc1/input18/ Event sysfs node is /sys/class/rc/rc1/input18/event15/ Parsing uevent /sys/class/rc/rc1/input18/event15/uevent /sys/class/rc/rc1/input18/event15/uevent uevent MAJOR=13 /sys/class/rc/rc1/input18/event15/uevent uevent MINOR=79 /sys/class/rc/rc1/input18/event15/uevent uevent DEVNAME=input/event15 Parsing uevent /sys/class/rc/rc1/uevent /sys/class/rc/rc1/uevent uevent NAME=rc-dvico-mce /sys/class/rc/rc1/uevent uevent DRV_NAME=dvb_usb_cxusb input device is /dev/input/event15 /sys/class/rc/rc1/protocols protocol unknown (disabled) Opening /dev/input/event15 Input Protocol version: 0x00010001 Enabled protocols: scancode 0xfe01 = KEY_RECORD (0xa7) scancode 0xfe02 = KEY_TV (0x179) scancode 0xfe03 = KEY_0 (0x0b) scancode 0xfe05 = KEY_VOLUMEDOWN (0x72) scancode 0xfe07 = KEY_4 (0x05) scancode 0xfe09 = KEY_CHANNELDOWN (0x193) scancode 0xfe0a = KEY_EPG (0x16d) scancode 0xfe0b = KEY_1 (0x02) scancode 0xfe0d = KEY_STOP (0x80) scancode 0xfe0e = KEY_MP3 (0x187) scancode 0xfe0f = KEY_PREVIOUSSONG (0xa5) scancode 0xfe11 = KEY_CHANNELUP (0x192) scancode 0xfe12 = KEY_NEXTSONG (0xa3) scancode 0xfe13 = KEY_ANGLE (0x173) scancode 0xfe15 = KEY_VOLUMEUP (0x73) scancode 0xfe16 = KEY_SETUP (0x8d) scancode 0xfe17 = KEY_2 (0x03) scancode 0xfe19 =
Re: ir-keytable: infinite loops, segfaults
On Wed, Nov 23, 2016 at 11:39:06PM +1100, Vincent McIntyre wrote: > On Tue, Nov 22, 2016 at 09:20:44AM +, Sean Young wrote: > > > Thanks for this. I have got it to build within the media_build setup > > > but will need to find some windows in the schedule for testing. More > > > in a couple of days. Are there specific things you would like me to > > > test? > > > > You should have an rc device for the IR receiver in the dvb device; does > > it continue to work and can you clear/load a new keymap with ir-keytable, > > and does it work after that. > > > > A "Tested-by" would be great if it all works of course. > > Time for some initial results. Good start, not quite there yet. > > Nov 23 23:04:56 kernel: Registered IR keymap rc-dvico-mce > Nov 23 23:04:56 kernel: input: IR-receiver inside an USB DVB receiver as > /devices/pci:00 > Nov 23 23:04:56 kernel: rc rc1: IR-receiver inside an USB DVB receiver as > /devices/pci:0 > Nov 23 23:04:56 kernel: dvb-usb: schedule remote query interval to 100 msecs. > Nov 23 23:04:56 kernel: dvb-usb: DViCO FusionHDTV DVB-T Dual Digital 4 > successfully initiali > Nov 23 23:04:56 kernel: dvb-usb: found a 'DViCO FusionHDTV DVB-T Dual Digital > 4' in warm sta > Nov 23 23:04:56 kernel: dvb-usb: will pass the complete MPEG2 transport > stream to the softwa > Nov 23 23:04:56 kernel: dvbdev: DVB: registering new adapter (DViCO > FusionHDTV DVB-T Dual Di > Nov 23 23:04:56 kernel: usb 3-2: media controller created > Nov 23 23:04:56 kernel: dvbdev: dvb_create_media_entity: media entity > 'dvb-demux' registered > Nov 23 23:04:56 kernel: cxusb: No IR receiver detected on this device. > Nov 23 23:04:56 kernel: usb 3-2: DVB: registering adapter 1 frontend 0 > (Zarlink ZL10353 DVB- > Nov 23 23:04:56 kernel: dvbdev: dvb_create_media_entity: media entity > 'Zarlink ZL10353 DVB-T > Nov 23 23:04:56 kernel: xc2028 5-0061: creating new instance > Nov 23 23:04:56 kernel: xc2028 5-0061: type set to XCeive xc2028/xc3028 tuner > Nov 23 23:04:56 kernel: xc2028 5-0061: Loading 80 firmware images from > xc3028-v27.fw, type: > Nov 23 23:04:56 kernel: dvb-usb: DViCO FusionHDTV DVB-T Dual Digital 4 > successfully initiali > Nov 23 23:04:56 kernel: usbcore: registered new interface driver dvb_usb_cxusb > > # lsmod |grep rc > rc_dvico_mce 16384 0 > rc_imon_mce16384 0 > rc_core32768 11 > imon,dvb_usb,winbond_cir,dvb_usb_cxusb,rc_imon_mce,rc_dvico_mce,dvb_usb_v2,dvb_usb_af9035 > libcrc32c 16384 1 raid456 > crc_itu_t 16384 1 firewire_core > > # lsmod |grep cxu > dvb_usb_cxusb 77824 2 > dib007020480 1 dvb_usb_cxusb > dvb_usb32768 1 dvb_usb_cxusb > rc_core32768 11 > imon,dvb_usb,winbond_cir,dvb_usb_cxusb,rc_imon_mce,rc_dvico_mce,dvb_usb_v2,dvb_usb_af9035 > > > # 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: 0x > Repeat delay = 500 ms, repeat period = 125 ms > Found /sys/class/rc/rc1/ (/dev/input/event15) with: > Driver (null), table rc-dvico-mce > Supported protocols: unknown > Enabled protocols: > Name: IR-receiver inside an USB DVB re > bus: 3, vendor/product: 0fe9:db78, version: 0x827b > Repeat delay = 500 ms, repeat period = 125 ms > Found /sys/class/rc/rc2/ (/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 > > Not sure why Driver is (null), dvb_usb_cxusb is loaded. That's a mistake, I've fixed that now. > # ir-keytable -s rc1 -r -v > Found device /sys/class/rc/rc0/ > Found device /sys/class/rc/rc1/ > Found device /sys/class/rc/rc2/ > Input sysfs node is /sys/class/rc/rc1/input18/ > Event sysfs node is /sys/class/rc/rc1/input18/event15/ > Parsing uevent /sys/class/rc/rc1/input18/event15/uevent > /sys/class/rc/rc1/input18/event15/uevent uevent MAJOR=13 > /sys/class/rc/rc1/input18/event15/uevent uevent MINOR=79 > /sys/class/rc/rc1/input18/event15/uevent uevent DEVNAME=input/event15 > Parsing uevent /sys/class/rc/rc1/uevent > /sys/class/rc/rc1/uevent uevent NAME=rc-dvico-mce > input device is /dev/input/event15 > /sys/class/rc/rc1/protocols protocol unknown (disabled) > Opening /dev/input/event15 > Input Protocol version: 0x00010001 > scancode 0xfe01 = KEY_RECORD (0xa7) > scancode 0xfe02 = KEY_TV (0x179) > scancode 0xfe03 = KEY_0 (0x0b) > scancode 0xfe05 = KEY_VOLUMEDOWN (0x72) > scancode 0xfe07 = KEY_4 (0x05) > scancode 0xfe09 = KEY_CHANNELDOWN (0x193) > scancode 0xfe0a = KEY_EPG (0x16d) > scancode 0xfe0b = KEY_1 (0x02) > scancode 0xfe0d = KEY_STOP (0x80) > scancode 0xfe0e = KEY_MP3 (
Re: ir-keytable: infinite loops, segfaults
On Tue, Nov 22, 2016 at 09:20:44AM +, Sean Young wrote: > > Thanks for this. I have got it to build within the media_build setup > > but will need to find some windows in the schedule for testing. More > > in a couple of days. Are there specific things you would like me to > > test? > > You should have an rc device for the IR receiver in the dvb device; does > it continue to work and can you clear/load a new keymap with ir-keytable, > and does it work after that. > > A "Tested-by" would be great if it all works of course. Time for some initial results. Good start, not quite there yet. Nov 23 23:04:56 kernel: Registered IR keymap rc-dvico-mce Nov 23 23:04:56 kernel: input: IR-receiver inside an USB DVB receiver as /devices/pci:00 Nov 23 23:04:56 kernel: rc rc1: IR-receiver inside an USB DVB receiver as /devices/pci:0 Nov 23 23:04:56 kernel: dvb-usb: schedule remote query interval to 100 msecs. Nov 23 23:04:56 kernel: dvb-usb: DViCO FusionHDTV DVB-T Dual Digital 4 successfully initiali Nov 23 23:04:56 kernel: dvb-usb: found a 'DViCO FusionHDTV DVB-T Dual Digital 4' in warm sta Nov 23 23:04:56 kernel: dvb-usb: will pass the complete MPEG2 transport stream to the softwa Nov 23 23:04:56 kernel: dvbdev: DVB: registering new adapter (DViCO FusionHDTV DVB-T Dual Di Nov 23 23:04:56 kernel: usb 3-2: media controller created Nov 23 23:04:56 kernel: dvbdev: dvb_create_media_entity: media entity 'dvb-demux' registered Nov 23 23:04:56 kernel: cxusb: No IR receiver detected on this device. Nov 23 23:04:56 kernel: usb 3-2: DVB: registering adapter 1 frontend 0 (Zarlink ZL10353 DVB- Nov 23 23:04:56 kernel: dvbdev: dvb_create_media_entity: media entity 'Zarlink ZL10353 DVB-T Nov 23 23:04:56 kernel: xc2028 5-0061: creating new instance Nov 23 23:04:56 kernel: xc2028 5-0061: type set to XCeive xc2028/xc3028 tuner Nov 23 23:04:56 kernel: xc2028 5-0061: Loading 80 firmware images from xc3028-v27.fw, type: Nov 23 23:04:56 kernel: dvb-usb: DViCO FusionHDTV DVB-T Dual Digital 4 successfully initiali Nov 23 23:04:56 kernel: usbcore: registered new interface driver dvb_usb_cxusb # lsmod |grep rc rc_dvico_mce 16384 0 rc_imon_mce16384 0 rc_core32768 11 imon,dvb_usb,winbond_cir,dvb_usb_cxusb,rc_imon_mce,rc_dvico_mce,dvb_usb_v2,dvb_usb_af9035 libcrc32c 16384 1 raid456 crc_itu_t 16384 1 firewire_core # lsmod |grep cxu dvb_usb_cxusb 77824 2 dib007020480 1 dvb_usb_cxusb dvb_usb32768 1 dvb_usb_cxusb rc_core32768 11 imon,dvb_usb,winbond_cir,dvb_usb_cxusb,rc_imon_mce,rc_dvico_mce,dvb_usb_v2,dvb_usb_af9035 # 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: 0x Repeat delay = 500 ms, repeat period = 125 ms Found /sys/class/rc/rc1/ (/dev/input/event15) with: Driver (null), table rc-dvico-mce Supported protocols: unknown Enabled protocols: Name: IR-receiver inside an USB DVB re bus: 3, vendor/product: 0fe9:db78, version: 0x827b Repeat delay = 500 ms, repeat period = 125 ms Found /sys/class/rc/rc2/ (/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 Not sure why Driver is (null), dvb_usb_cxusb is loaded. # ir-keytable -s rc1 -r -v Found device /sys/class/rc/rc0/ Found device /sys/class/rc/rc1/ Found device /sys/class/rc/rc2/ Input sysfs node is /sys/class/rc/rc1/input18/ Event sysfs node is /sys/class/rc/rc1/input18/event15/ Parsing uevent /sys/class/rc/rc1/input18/event15/uevent /sys/class/rc/rc1/input18/event15/uevent uevent MAJOR=13 /sys/class/rc/rc1/input18/event15/uevent uevent MINOR=79 /sys/class/rc/rc1/input18/event15/uevent uevent DEVNAME=input/event15 Parsing uevent /sys/class/rc/rc1/uevent /sys/class/rc/rc1/uevent uevent NAME=rc-dvico-mce input device is /dev/input/event15 /sys/class/rc/rc1/protocols protocol unknown (disabled) Opening /dev/input/event15 Input Protocol version: 0x00010001 scancode 0xfe01 = KEY_RECORD (0xa7) scancode 0xfe02 = KEY_TV (0x179) scancode 0xfe03 = KEY_0 (0x0b) scancode 0xfe05 = KEY_VOLUMEDOWN (0x72) scancode 0xfe07 = KEY_4 (0x05) scancode 0xfe09 = KEY_CHANNELDOWN (0x193) scancode 0xfe0a = KEY_EPG (0x16d) scancode 0xfe0b = KEY_1 (0x02) scancode 0xfe0d = KEY_STOP (0x80) scancode 0xfe0e = KEY_MP3 (0x187) scancode 0xfe0f = KEY_PREVIOUSSONG (0xa5) scancode 0xfe11 = KEY_CHANNELUP (0x192) scancode 0xfe12 = KEY_NEXTSONG (0xa3) scancode 0xfe13 = KEY_ANGLE (0x173) scancode 0xfe15 = KEY_VOLUMEUP (0x73) scancode 0xfe16 = KEY_SETUP (0x8d) scancode 0xfe17 = KEY_2 (0x03) scancode 0xfe19 = KEY_OPEN (0x86) scancode 0xfe1a = KEY_DVD
Re: ir-keytable: infinite loops, segfaults
On Tue, Nov 22, 2016 at 06:25:59PM +1100, Vincent McIntyre wrote: > On 11/21/16, Sean Young wrote: > >> > >> 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: > > > > As I said you would need to use a raw IR receiver which has rc-core support > > to determine the protocol, so never mind. Please can you try this patch: > > > > I don't have the hardware to test this so your input would be appreciated. > > > > Thanks for this. I have got it to build within the media_build setup > but will need to find some windows in the schedule for testing. More > in a couple of days. Are there specific things you would like me to > test? You should have an rc device for the IR receiver in the dvb device; does it continue to work and can you clear/load a new keymap with ir-keytable, and does it work after that. A "Tested-by" would be great if it all works of course. Thanks Sean -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ir-keytable: infinite loops, segfaults
On 11/21/16, Sean Young wrote: >> >> 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: > > As I said you would need to use a raw IR receiver which has rc-core support > to determine the protocol, so never mind. Please can you try this patch: > > I don't have the hardware to test this so your input would be appreciated. > Thanks for this. I have got it to build within the media_build setup but will need to find some windows in the schedule for testing. More in a couple of days. Are there specific things you would like me to test? Vince -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ir-keytable: infinite loops, segfaults
On Sat, Nov 19, 2016 at 09:01:10AM +1100, Vincent McIntyre wrote: > On Fri, Nov 18, 2016 at 05:40:34PM +, 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; 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: As I said you would need to use a raw IR receiver which has rc-core support to determine the protocol, so never mind. Please can you try this patch: I don't have the hardware to test this so your input would be appreciated. Sean From: Sean Young Subject: [PATCH] [media] cxusb: port to rc-core The d680_dmb keymap has some new new mappings. Signed-off-by: Sean Young --- drivers/media/rc/keymaps/Makefile| 3 + drivers/media/rc/keymaps/rc-d680-dmb.c | 75 +++ drivers/media/rc/keymaps/rc-dvico-mce.c | 85 drivers/media/rc/keymaps/rc-dvico-portable.c | 76 +++ drivers/media/usb/dvb-usb/cxusb.c| 298 ++- include/media/rc-map.h | 3 + 6 files changed, 308 insertions(+), 232 deletions(-) create mode 100644 drivers/media/rc/keymaps/rc-d680-dmb.c create mode 100644 drivers/media/rc/keymaps/rc-dvico-mce.c create mode 100644 drivers/media/rc/keymaps/rc-dvico-portable.c diff --git a/drivers/media/rc/keymaps/Makefile b/drivers/media/rc/keymaps/Makefile index d7b13fa..11d5d5a 100644 --- a/drivers/media/rc/keymaps/Makefile +++ b/drivers/media/rc/keymaps/Makefile @@ -21,6 +21,7 @@ obj-$(CONFIG_RC_MAP) += rc-adstech-dvb-t-pci.o \ rc-cec.o \ rc-cinergy-1400.o \ rc-cinergy.o \ + rc-d680-dmb.o \ rc-delock-61959.o \ rc-dib0700-nec.o \ rc-dib0700-rc5.o \ @@ -31,6 +32,8 @@ obj-$(CONFIG_RC_MAP) += rc-adstech-dvb-t-pci.o \ rc-dntv-live-dvbt-pro.o \ rc-dtt200u.o \ rc-dvbsky.o \ + rc-dvico-mce.o \ + rc-dvico-portable.o \ rc-em-terratec.o \ rc-encore-enltv2.o \ rc-encore-enltv.o \ diff --git a/drivers/media/rc/keymaps/rc-d680-dmb.c b/drivers/media/rc/keymaps/rc-d680-dmb.c new file mode 100644 index 000..bb5745d --- /dev/null +++ b/drivers/media/rc/keymaps/rc-d680-dmb.c @@ -0,0 +1,75 @@ +/* + * keymap imported from cxusb.c + * + * Copyright (C) 2016 Sean Young + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; version 2. + */ + +#include +#include + +static struct rc_map_table rc_map_d680_dmb_table[] = { + { 0x0038, KEY_SWITCHVIDEOMODE },/* TV/AV */ + { 0x080c, KEY_ZOOM }, + { 0x0800, KEY_0 }, + { 0x0001, KEY_1 }, + { 0x0802, KEY_2 }, + { 0x0003, KEY_3 }, + { 0x0804, KEY_4 }, + { 0x0005, KEY_5 }, + { 0x0806, KEY_6 }, + { 0x0007, KEY_7 }, + { 0x0808, KEY_8 }, + { 0x0009, KEY_9 }, + { 0x000a, KEY_MUTE }, + { 0x0829, KEY_BACK }, + { 0x0012, KEY_CHANNELUP }, + { 0x0813, KEY_CHANNELDOWN }, + { 0x002b, KEY_VOLUMEUP }, + { 0x082c, KEY_VOLUMEDOWN }, + { 0x0020, KEY_UP }, + { 0x0821, KEY_DOWN }, + { 0x0011, KEY_LEFT }, + { 0x0810, KEY_RIGHT }, + { 0x000d, KEY_OK }, + { 0x081f, KEY_RECORD }, + { 0x0017, KEY_PLAYPAUSE }, + { 0x0816, KEY_PLAYPAUSE }, + { 0x000b, KEY_STOP }, + { 0x0827, KEY_FASTFORWARD }, + { 0x0026, KEY_REWIND }, +
Re: ir-keytable: infinite loops, segfaults
On Fri, Nov 18, 2016 at 05:40:34PM +, 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; 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: 0x 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ir-keytable: infinite loops, segfaults
On Fri, Nov 18, 2016 at 05:40:34PM +, 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: 0x > > 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) Value500 Repeat code 1 (REP_PERIOD) Value125 Properties: Testing ... (interrupt to exit) Event: time 1479509081.158426, type 4 (EV_MSC), code 4 (MSC_SCAN), value 35a Event: time 1479509081.158426, -- SYN_REPORT 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 Event: time 1479509251.174361, type 4 (EV_MSC), code 4 (MSC_SCAN), value 105 Event: time 1479509251.174361, -- SYN_REPORT 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ir-keytable: infinite loops, segfaults
On Fri, Nov 18, 2016 at 05:40:34PM +, 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; 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: 0x > > 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ir-keytable: infinite loops, segfaults
On Fri, Nov 18, 2016 at 11:14:25PM +1100, Vincent McIntyre wrote: > On Thu, Nov 17, 2016 at 01:45:26PM +, 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; 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: 0x > 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 majord...@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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ir-keytable: infinite loops, segfaults
On Thu, Nov 17, 2016 at 01:45:26PM +, 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: 0x 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ir-keytable: infinite loops, segfaults
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
ir-keytable: infinite loops, segfaults
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 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: --- dvico_mce 2016-11-13 22:50:11.442092350 +1100 +++ testfile2016-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 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=0