diff mbox

ir-keytable: infinite loops, segfaults

Message ID 20161116105256.GA9998@shambles.local (mailing list archive)
State RFC, archived
Headers

Commit Message

Vincent McIntyre Nov. 16, 2016, 10:52 a.m. UTC 
  Hi,

I have a fairly old dvico dual digital 4 tuner and remote.
There seem to be some issues with support for it, can I help fix them?

I am using ir-keytable 1.10.0-1 on Ubuntu 16.04 LTS,
with kernel 4.4.0-47-generic (package version 4.4.0-47-generic)

The remote's keymapping is the one in /lib/udev/rc_keymaps/dvico_mce;
kernel support for the device is in media/usb/dvb-usb/cxusb.c.

Mostly it works, in that I get correct keycodes back from evtest
and ir-keytable -t. But I want to change some of the keycode mappings
and that is not working.

  # cat >testfile
  0xfe47 KEY_PAUSE
  ^D
  
  # ir-keytable -v -d /dev/input/event15 -w testfile
  Parsing testfile keycode file
  parsing 0xfe47=KEY_PAUSE:   value=119
  Opening /dev/input/event15
  Input Protocol version: 0x00010001
      fe47=0077
  Wrote 1 keycode(s) to driver

So far so good, yes? But evtest still reports the same keycode
for the key I tried to modify.

  # evtest
  <select device 15>
  <press PLAYPAUSE key on remote>
  Event: time 1479206112.262746, type 1 (EV_KEY), code 164 (KEY_PLAYPAUSE), value 1
  Event: time 1479206112.262746, -------------- SYN_REPORT ------------
  Event: time 1479206112.262760, type 1 (EV_KEY), code 164 (KEY_PLAYPAUSE), value 0
  Event: time 1479206112.262760, -------------- SYN_REPORT ------------
 
  # irkeytable -r -d /dev/input/event15 |grep PAUSE
  Enabled protocols: unknown rc-5 sony nec sanyo mce-kbd rc-6 sharp xmp 
  scancode 0xfe02 = KEY_PAUSE (0x77)
  scancode 0xfe47 = KEY_PLAYPAUSE (0xa4)

I thought that I might need to clear and replace the entire table
to get things working. This is where the problems really start.

First trying to clear the table causes an infinite loop.

  # ir-keytable -d /dev/input/event15 -c
  Opening /dev/input/event15
  Input Protocol version: 0x00010001
  Deleting entry 1
  Deleting entry 2
  Deleting entry 3
  Deleting entry 4
  ....
  Deleting entry 2114689
  Deleting entry 2114690
  ^C

Then I tried to load a modified version of dvico_mce
The whole file was there, with just this change:

The program seems to parse the modified file ok but then
segaults while reading from the input device.

  # ir-keytable -v -d /dev/input/event15 -w testfile
  Parsing testfile keycode file
  parsing 0xfe02=KEY_TV:  value=377
  parsing 0xfe0e=KEY_MP3: value=391
  parsing 0xfe1a=KEY_DVD: value=389
  parsing 0xfe1e=KEY_FAVORITES:   value=364
  parsing 0xfe16=KEY_SETUP:   value=141
  parsing 0xfe46=KEY_POWER2:  value=356
  parsing 0xfe0a=KEY_EPG: value=365
  parsing 0xfe49=KEY_BACK:    value=158
  parsing 0xfe4d=KEY_MENU:    value=139
  parsing 0xfe51=KEY_UP:  value=103
  parsing 0xfe5b=KEY_LEFT:    value=105
  parsing 0xfe5f=KEY_RIGHT:   value=106
  parsing 0xfe53=KEY_DOWN:    value=108
  parsing 0xfe5e=KEY_OK:  value=352
  parsing 0xfe59=KEY_INFO:    value=358
  parsing 0xfe55=KEY_TAB: value=15
  parsing 0xfe0f=KEY_PREVIOUSSONG:    value=165
  parsing 0xfe12=KEY_NEXTSONG:    value=163
  parsing 0xfe42=KEY_ENTER:   value=28
  parsing 0xfe15=KEY_VOLUMEUP:    value=115
  parsing 0xfe05=KEY_VOLUMEDOWN:  value=114
  parsing 0xfe11=KEY_CHANNELUP:   value=402
  parsing 0xfe09=KEY_CHANNELDOWN: value=403
  parsing 0xfe52=KEY_CAMERA:  value=212
  parsing 0xfe5a=KEY_TUNER:   value=386
  parsing 0xfe19=KEY_OPEN:    value=134
  parsing 0xfe0b=KEY_1:   value=2
  parsing 0xfe17=KEY_2:   value=3
  parsing 0xfe1b=KEY_3:   value=4
  parsing 0xfe07=KEY_4:   value=5
  parsing 0xfe50=KEY_5:   value=6
  parsing 0xfe54=KEY_6:   value=7
  parsing 0xfe48=KEY_7:   value=8
  parsing 0xfe4c=KEY_8:   value=9
  parsing 0xfe58=KEY_9:   value=10
  parsing 0xfe13=KEY_ANGLE:   value=371
  parsing 0xfe03=KEY_0:   value=11
  parsing 0xfe1f=KEY_ZOOM:    value=372
  parsing 0xfe43=KEY_REWIND:  value=168
  parsing 0xfe47=KEY_PAUSE:   value=119
  parsing 0xfe4f=KEY_FASTFORWARD: value=208
  parsing 0xfe57=KEY_MUTE:    value=113
  parsing 0xfe0d=KEY_STOP:    value=128
  parsing 0xfe01=KEY_RECORD:  value=167
  parsing 0xfe4e=KEY_POWER:   value=116
  Read dvico_mce table
  Opening /dev/input/event15
  Input Protocol version: 0x00010001
      fe4e=0074
      fe01=00a7
      fe0d=0080
      fe57=0071
      fe4f=00d0
      fe47=0077
      fe43=00a8
      fe1f=0174
      fe03=000b
      fe13=0173
      fe58=000a
      fe4c=0009
      fe48=0008
      fe54=0007
      fe50=0006
      fe07=0005
      fe1b=0004
      fe17=0003
      fe0b=0002
      fe19=0086
      fe5a=0182
      fe52=00d4
      fe09=0193
      fe11=0192
      fe05=0072
      fe15=0073
      fe42=001c
      fe12=00a3
      fe0f=00a5
      fe55=000f
      fe59=0166
      fe5e=0160
      fe53=006c
      fe5f=006a
      fe5b=0069
      fe51=0067
      fe4d=008b
      fe49=009e
      fe0a=016d
      fe46=0164
      fe16=008d
      fe1e=016c
      fe1a=0185
      fe0e=0187
      fe02=0179
  Wrote 45 keycode(s) to driver
  Segmentation fault (core dumped)
 
Is this just operator error?
What further diagnostics would help?

Vince

PS evtest reports this about the device:
  # evtest /dev/input/event15
  Input driver version is 1.0.1
  Input device ID: bus 0x3 vendor 0xfe9 product 0xdb78 version 0x827b
  Input device name: "IR-receiver inside an USB DVB receiver"
  Supported events:
    Event type 0 (EV_SYN)
    Event type 1 (EV_KEY)
    ...<elided>...
    Event code 403 (KEY_CHANNELDOWN)
  Properties:
  Testing ... (interrupt to exit)
  ^C
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Comments

Sean Young Nov. 17, 2016, 1:45 p.m. UTC | #1 
On Wed, Nov 16, 2016 at 09:52:58PM +1100, Vincent McIntyre wrote:
> I have a fairly old dvico dual digital 4 tuner and remote.
> There seem to be some issues with support for it, can I help fix them?
> 
> I am using ir-keytable 1.10.0-1 on Ubuntu 16.04 LTS,
> with kernel 4.4.0-47-generic (package version 4.4.0-47-generic)
> 
> The remote's keymapping is the one in /lib/udev/rc_keymaps/dvico_mce;
> kernel support for the device is in media/usb/dvb-usb/cxusb.c.
> 
> Mostly it works, in that I get correct keycodes back from evtest
> and ir-keytable -t. But I want to change some of the keycode mappings
> and that is not working.

I suspect the problem here is rc-core is not used and 
legacy_dvb_usb_setkeycode has a bug (it has several problems).

It would be nicer if we could move it rc-core, but for that to work
we need to know what scancodes remote sends (and in what protocol).
A scancode of 0xfe47 is not a valid RC5 scancode.

Would it be possible to test the remote with another device (say an
usb mce receiver or so) and see what scancodes it sends? Then we can
translate the keymap to a real one and make the cxusb driver send
correct scancodes to rc-core.


Sean
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Vincent McIntyre Nov. 18, 2016, 12:14 p.m. UTC | #2 
On Thu, Nov 17, 2016 at 01:45:26PM +0000, Sean Young wrote:
> On Wed, Nov 16, 2016 at 09:52:58PM +1100, Vincent McIntyre wrote:
> > I have a fairly old dvico dual digital 4 tuner and remote.
> > There seem to be some issues with support for it, can I help fix them?
> > 
> > I am using ir-keytable 1.10.0-1 on Ubuntu 16.04 LTS,
> > with kernel 4.4.0-47-generic (package version 4.4.0-47-generic)
> > 
> > The remote's keymapping is the one in /lib/udev/rc_keymaps/dvico_mce;
> > kernel support for the device is in media/usb/dvb-usb/cxusb.c.
> > 
> > Mostly it works, in that I get correct keycodes back from evtest
> > and ir-keytable -t. But I want to change some of the keycode mappings
> > and that is not working.
> 
> I suspect the problem here is rc-core is not used and 
> legacy_dvb_usb_setkeycode has a bug (it has several problems).
> 
> It would be nicer if we could move it rc-core, but for that to work
> we need to know what scancodes remote sends (and in what protocol).
> A scancode of 0xfe47 is not a valid RC5 scancode.
 
So are you saying that the hex codes in the rc_map_dvico_mce_table
struct are invalid (at least in some cases)?

How can I tell what protocol is in use?
0x00010001 doesn't mean much to me; I did search the linux source
for the code but didn't find any helpful matches.

> Would it be possible to test the remote with another device (say an
> usb mce receiver or so) and see what scancodes it sends? Then we can
> translate the keymap to a real one and make the cxusb driver send
> correct scancodes to rc-core.

Great idea. Do you mean something like [1]?
Or the (presumably generic) receiver that comes with [2]?
Would a FLIRC work?

Probably dumb question - in this machine I also have
an iMon Remote (152c:ffdc)
and Leadtek WinFast DTV Dongle Dual
Do you think either of those would be helpful?
I tried evtest with them and the remote, no responses.

# ir-keytable
Found /sys/class/rc/rce0/ (/dev/input/event5) with:
    Driver imon, table rc-imon-mce
    Supported protocols: rc-6 
    Enabled protocols: rc-6 
    Name: iMON Remote (15c2:ffdc)
    bus: 3, vendor/product: 15c2:ffdc, version: 0x0000
    Repeat delay = 500 ms, repeat period = 125 ms
Found /sys/class/rc/rc1/ (/dev/input/event16) with:
    Driver dvb_usb_af9035, table rc-empty
    Supported protocols: nec 
    Enabled protocols: 
    Name: Leadtek WinFamst DTV Dongle Dual
    bus: 3, vendor/product: 0413:6a05, version: 0x0200
    Repeat delay = 500 mss, repeat period = 125 ms

Thanks
Vince

[1] http://www.ebay.com.au/itm/New-HP-USB-MCE-IR-Wireless-Receiver-Windows-7-Vista-/261127073131
[2] https://www.jaycar.com.au/home-theatre-pc-remote-control/p/XC4939

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Sean Young Nov. 18, 2016, 5:40 p.m. UTC | #3 
On Fri, Nov 18, 2016 at 11:14:25PM +1100, Vincent McIntyre wrote:
> On Thu, Nov 17, 2016 at 01:45:26PM +0000, Sean Young wrote:
> > On Wed, Nov 16, 2016 at 09:52:58PM +1100, Vincent McIntyre wrote:
> > > I have a fairly old dvico dual digital 4 tuner and remote.
> > > There seem to be some issues with support for it, can I help fix them?
> > > 
> > > I am using ir-keytable 1.10.0-1 on Ubuntu 16.04 LTS,
> > > with kernel 4.4.0-47-generic (package version 4.4.0-47-generic)
> > > 
> > > The remote's keymapping is the one in /lib/udev/rc_keymaps/dvico_mce;
> > > kernel support for the device is in media/usb/dvb-usb/cxusb.c.
> > > 
> > > Mostly it works, in that I get correct keycodes back from evtest
> > > and ir-keytable -t. But I want to change some of the keycode mappings
> > > and that is not working.
> > 
> > I suspect the problem here is rc-core is not used and 
> > legacy_dvb_usb_setkeycode has a bug (it has several problems).
> > 
> > It would be nicer if we could move it rc-core, but for that to work
> > we need to know what scancodes remote sends (and in what protocol).
> > A scancode of 0xfe47 is not a valid RC5 scancode.
>  
> So are you saying that the hex codes in the rc_map_dvico_mce_table
> struct are invalid (at least in some cases)?

Most likely the remote produces IR in a standard protocol (e.g. rc5, rc6). 
If we first get the keymap right then the remote can be used with any 
IR receiver that can deal with its protocol; conversely, if we know 
what protocol the IR receiver can receive, and we make it produce the 
scancodes in the right format, it can then be used with any remote that 
uses the protocol it understands.

So at the moment we don't know what protocol it is, and even if it is 
rc5 then some bit shifting might be needed to make it into a proper
rc5 scancode (both driver and keymap).

> How can I tell what protocol is in use?
> 0x00010001 doesn't mean much to me; I did search the linux source
> for the code but didn't find any helpful matches.

At the moment it's not easy to determine what protocol an remote uses;
I would like to change that but for now, the following is probably
the easiest way.

cd /sys/class/rc/rc1 # replace rc1 with your receiver
for i in $(<protocols); do echo +$i > protocols; done
echo 3 > /sys/module/rc_core/parameters/debug
journal -f -k

Protocol numbers are defined in enum rc_type, see include/media/rc-map.h

> > Would it be possible to test the remote with another device (say an
> > usb mce receiver or so) and see what scancodes it sends? Then we can
> > translate the keymap to a real one and make the cxusb driver send
> > correct scancodes to rc-core.
> 
> Great idea. Do you mean something like [1]?

Yes, it would be a receiver like that.

> Or the (presumably generic) receiver that comes with [2]?

It's not clear what usb receiver it uses.

> Would a FLIRC work?

I hadn't heard of flirc, looks like it doesn't have a kernel driver. Maybe
I'll go and get one. :)

> Probably dumb question - in this machine I also have
> an iMon Remote (152c:ffdc)
> and Leadtek WinFast DTV Dongle Dual
> Do you think either of those would be helpful?
> I tried evtest with them and the remote, no responses.
> 
> # ir-keytable
> Found /sys/class/rc/rce0/ (/dev/input/event5) with:
>     Driver imon, table rc-imon-mce
>     Supported protocols: rc-6 
>     Enabled protocols: rc-6 
>     Name: iMON Remote (15c2:ffdc)
>     bus: 3, vendor/product: 15c2:ffdc, version: 0x0000
>     Repeat delay = 500 ms, repeat period = 125 ms
> Found /sys/class/rc/rc1/ (/dev/input/event16) with:
>     Driver dvb_usb_af9035, table rc-empty
>     Supported protocols: nec 
>     Enabled protocols: 
>     Name: Leadtek WinFamst DTV Dongle Dual
>     bus: 3, vendor/product: 0413:6a05, version: 0x0200
>     Repeat delay = 500 mss, repeat period = 125 ms

Looks like it's neither rc6 nor nec then.

If you don't have the right receiver then all of this a bit academic.
Maybe it's possible to port to rc-core with the existing scancodes.

Thanks
Sean

> 
> Thanks
> Vince
> 
> [1] http://www.ebay.com.au/itm/New-HP-USB-MCE-IR-Wireless-Receiver-Windows-7-Vista-/261127073131
> [2] https://www.jaycar.com.au/home-theatre-pc-remote-control/p/XC4939
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Vincent McIntyre Nov. 18, 2016, 10:01 p.m. UTC | #4 
On Fri, Nov 18, 2016 at 05:40:34PM +0000, Sean Young wrote:
> >  
> > So are you saying that the hex codes in the rc_map_dvico_mce_table
> > struct are invalid (at least in some cases)?
> 
> Most likely the remote produces IR in a standard protocol (e.g. rc5, rc6). 
> If we first get the keymap right then the remote can be used with any 
> IR receiver that can deal with its protocol; conversely, if we know 
> what protocol the IR receiver can receive, and we make it produce the 
> scancodes in the right format, it can then be used with any remote that 
> uses the protocol it understands.
> 
> So at the moment we don't know what protocol it is, and even if it is 
> rc5 then some bit shifting might be needed to make it into a proper
> rc5 scancode (both driver and keymap).
> 
> > How can I tell what protocol is in use?
> > 0x00010001 doesn't mean much to me; I did search the linux source
> > for the code but didn't find any helpful matches.
> 
> At the moment it's not easy to determine what protocol an remote uses;
> I would like to change that but for now, the following is probably
> the easiest way.
> 
> cd /sys/class/rc/rc1 # replace rc1 with your receiver
> for i in $(<protocols); do echo +$i > protocols; done
> echo 3 > /sys/module/rc_core/parameters/debug
> journal -f -k
 
Ah. Here we have a problem. The device (/dev/input/event15)
doesn't have a corresponding rcX node, see ir-keytable output below.
I had it explained to me like this:

  A "HID" device is basically any input device that resembles
  a keyboard or mouse (Human Interface Device). The label may also cover
  things like joysticks, etc. It does /not/ include remotes, so it
  seems, since "remote" can cover a wide variety of input devices.

  Some remotes can emulate fully or partially keyboard keypresses
  which is why they can be treated as HID devices. Of course, not all
  the keys may be mapped correctly or at all.


> Protocol numbers are defined in enum rc_type, see include/media/rc-map.h
> 
> > > Would it be possible to test the remote with another device (say an
> > > usb mce receiver or so) and see what scancodes it sends? Then we can
> > > translate the keymap to a real one and make the cxusb driver send
> > > correct scancodes to rc-core.
> > 
> > Great idea. Do you mean something like [1]?
> 
> Yes, it would be a receiver like that.
> 
> > Or the (presumably generic) receiver that comes with [2]?
> 
> It's not clear what usb receiver it uses.
> 
> > Would a FLIRC work?
> 
> I hadn't heard of flirc, looks like it doesn't have a kernel driver. Maybe
> I'll go and get one. :)
> 
> > Probably dumb question - in this machine I also have
> > an iMon Remote (152c:ffdc)
> > and Leadtek WinFast DTV Dongle Dual
> > Do you think either of those would be helpful?
> > I tried evtest with them and the remote, no responses.
> > 
> > # ir-keytable
> > Found /sys/class/rc/rce0/ (/dev/input/event5) with:
> >     Driver imon, table rc-imon-mce
> >     Supported protocols: rc-6 
> >     Enabled protocols: rc-6 
> >     Name: iMON Remote (15c2:ffdc)
> >     bus: 3, vendor/product: 15c2:ffdc, version: 0x0000
> >     Repeat delay = 500 ms, repeat period = 125 ms
> > Found /sys/class/rc/rc1/ (/dev/input/event16) with:
> >     Driver dvb_usb_af9035, table rc-empty
> >     Supported protocols: nec 
> >     Enabled protocols: 
> >     Name: Leadtek WinFamst DTV Dongle Dual
> >     bus: 3, vendor/product: 0413:6a05, version: 0x0200
> >     Repeat delay = 500 mss, repeat period = 125 ms
> 
> Looks like it's neither rc6 nor nec then.
> 
> If you don't have the right receiver then all of this a bit academic.
> Maybe it's possible to port to rc-core with the existing scancodes.

I may have given bad information here - I need to check whether the
IR receivers for these devices are properly connected. That might be
why there was no response...

Thanks for your help so far
Vince
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Vincent McIntyre Nov. 18, 2016, 10:49 p.m. UTC | #5 
On Fri, Nov 18, 2016 at 05:40:34PM +0000, Sean Young wrote:
> > 
> > # ir-keytable
> > Found /sys/class/rc/rce0/ (/dev/input/event5) with:
> >     Driver imon, table rc-imon-mce
> >     Supported protocols: rc-6 
> >     Enabled protocols: rc-6 
> >     Name: iMON Remote (15c2:ffdc)
> >     bus: 3, vendor/product: 15c2:ffdc, version: 0x0000
> >     Repeat delay = 500 ms, repeat period = 125 ms
> > Found /sys/class/rc/rc1/ (/dev/input/event16) with:
> >     Driver dvb_usb_af9035, table rc-empty
> >     Supported protocols: nec 
> >     Enabled protocols: 
> >     Name: Leadtek WinFamst DTV Dongle Dual
> >     bus: 3, vendor/product: 0413:6a05, version: 0x0200
> >     Repeat delay = 500 mss, repeat period = 125 ms

So I checked on the ir receivers and found the rc1 device ir receiver
was indeed blocked (haven't checked rc0 properly, time is short)

I tested it with evtest and the remote that comes with the device

# evtest /dev/input/event16
Input driver version is 1.0.1
Input device ID: bus 0x3 vendor 0x413 product 0x6a05 version 0x200
Input device name: "Leadtek WinFast DTV Dongle Dual"
Supported events:
  Event type 0 (EV_SYN)
  Event type 1 (EV_KEY)
    Event code 28 (KEY_ENTER)
    Event code 103 (KEY_UP)
    Event code 105 (KEY_LEFT)
    Event code 106 (KEY_RIGHT)
    Event code 108 (KEY_DOWN)
    Event code 111 (KEY_DELETE)
    Event code 113 (KEY_MUTE)
    Event code 114 (KEY_VOLUMEDOWN)
    Event code 115 (KEY_VOLUMEUP)
    Event code 119 (KEY_PAUSE)
    Event code 128 (KEY_STOP)
    Event code 142 (KEY_SLEEP)
    Event code 152 (KEY_SCREENLOCK)
    Event code 161 (KEY_EJECTCD)
    Event code 164 (KEY_PLAYPAUSE)
    Event code 167 (KEY_RECORD)
    Event code 168 (KEY_REWIND)
    Event code 174 (KEY_EXIT)
    Event code 207 (KEY_PLAY)
    Event code 208 (KEY_FASTFORWARD)
    Event code 210 (KEY_PRINT)
    Event code 212 (KEY_CAMERA)
    Event code 224 (KEY_BRIGHTNESSDOWN)
    Event code 225 (KEY_BRIGHTNESSUP)
    Event code 226 (KEY_MEDIA)
    Event code 352 (KEY_OK)
    Event code 356 (KEY_POWER2)
    Event code 358 (KEY_INFO)
    Event code 365 (KEY_EPG)
    Event code 366 (KEY_PVR)
    Event code 368 (KEY_LANGUAGE)
    Event code 369 (KEY_TITLE)
    Event code 370 (KEY_SUBTITLE)
    Event code 372 (KEY_ZOOM)
    Event code 373 (KEY_MODE)
    Event code 377 (KEY_TV)
    Event code 385 (KEY_RADIO)
    Event code 386 (KEY_TUNER)
    Event code 387 (KEY_PLAYER)
    Event code 389 (KEY_DVD)
    Event code 392 (KEY_AUDIO)
    Event code 393 (KEY_VIDEO)
    Event code 398 (KEY_RED)
    Event code 399 (KEY_GREEN)
    Event code 400 (KEY_YELLOW)
    Event code 401 (KEY_BLUE)
    Event code 402 (KEY_CHANNELUP)
    Event code 403 (KEY_CHANNELDOWN)
    Event code 407 (KEY_NEXT)
    Event code 412 (KEY_PREVIOUS)
    Event code 425 (KEY_PRESENTATION)
    Event code 512 (KEY_NUMERIC_0)
    Event code 513 (KEY_NUMERIC_1)
    Event code 514 (KEY_NUMERIC_2)
    Event code 515 (KEY_NUMERIC_3)
    Event code 516 (KEY_NUMERIC_4)
    Event code 517 (KEY_NUMERIC_5)
    Event code 518 (KEY_NUMERIC_6)
    Event code 519 (KEY_NUMERIC_7)
    Event code 520 (KEY_NUMERIC_8)
    Event code 521 (KEY_NUMERIC_9)
    Event code 522 (KEY_NUMERIC_STAR)
    Event code 523 (KEY_NUMERIC_POUND)
  Event type 4 (EV_MSC)
    Event code 4 (MSC_SCAN)
Key repeat handling:
  Repeat type 20 (EV_REP)
    Repeat code 0 (REP_DELAY)
      Value    500
    Repeat code 1 (REP_PERIOD)
      Value    125
Properties:
Testing ... (interrupt to exit)
<volumedown pressed>
Event: time 1479509081.158426, type 4 (EV_MSC), code 4 (MSC_SCAN), value 35a
Event: time 1479509081.158426, -------------- SYN_REPORT ------------
<volumeup pressed>
Event: time 1479509084.658351, type 4 (EV_MSC), code 4 (MSC_SCAN), value 35e
Event: time 1479509084.658351, -------------- SYN_REPORT ------------
^C

I tried to load a keymap but got another segfault

# ir-keytable -p nec -d /dev/input/event16 -w /lib/udev/rc_keymaps/rc6_mce 
Read rc6_mce table
Wrote 63 keycode(s) to driver
Segmentation fault (core dumped)

Can't find a -dbg package so can't give you a useful backtrace
at the moment.

Anyway: trying the same evtest with the dvico remote
evtest /dev/input/event16
<volumedown>
Event: time 1479509251.174361, type 4 (EV_MSC), code 4 (MSC_SCAN), value 105
Event: time 1479509251.174361, -------------- SYN_REPORT ------------
<volumeup>
Event: time 1479509254.174403, type 4 (EV_MSC), code 4 (MSC_SCAN), value 115
Event: time 1479509254.174403, -------------- SYN_REPORT ------------

So something is connecting via IR.
Out of time now, more later
Vince
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Vincent McIntyre Nov. 18, 2016, 11:57 p.m. UTC | #6 
On Fri, Nov 18, 2016 at 05:40:34PM +0000, Sean Young wrote:
> 
> At the moment it's not easy to determine what protocol an remote uses;
> I would like to change that but for now, the following is probably
> the easiest way.
> 
> cd /sys/class/rc/rc1 # replace rc1 with your receiver
> for i in $(<protocols); do echo +$i > protocols; done
> echo 3 > /sys/module/rc_core/parameters/debug
> journal -f -k
> 
> Protocol numbers are defined in enum rc_type, see include/media/rc-map.h

I tried this with the rc1 device as a test. I get this odd result:
# cat protocols
nec
# echo '+nec' > protocols
bash: echo: write error: Invalid argument

and ir-keytable still shows no protocols enabled
# ir-keytable
Found /sys/class/rc/rc0/ (/dev/input/event5) with:
    Driver imon, table rc-imon-mce
    Supported protocols: rc-6 
    Enabled protocols: rc-6 
    Name: iMON Remote (15c2:ffdc)
    bus: 3, vendor/product: 15c2:ffdc, version: 0x0000
    Repeat delay = 500 ms, repeat period = 125 ms
Found /sys/class/rc/rc1/ (/dev/input/event16) with:
    Driver dvb_usb_af9035, table rc-empty
    Supported protocols: nec 
    Enabled protocols: 
    Name: Leadtek WinFast DTV Dongle Dual
    bus: 3, vendor/product: 0413:6a05, version: 0x0200
    Repeat delay = 500 ms, repeat period = 125 ms

I messed around some more with ir-keytable and got more segfaults
if I try to use the -d argument.

# ir-keytable -d /dev/input/event16 -p NEC -p RC6 -w /lib/udev/rc_keymaps/rc6_mce 
Read rc6_mce table
Wrote 63 keycode(s) to driver
Segmentation fault (core dumped)

-s at least doesn't segfault, but doesn't advance the cause.

# ir-keytable -s rc1 -p NEC -p RC6 -w /lib/udev/rc_keymaps/rc6_mce 
Read rc6_mce table
Wrote 63 keycode(s) to driver
/sys/class/rc/rc1//protocols: Invalid argument
Couldn't change the IR protocols


# ir-keytable -s rc1 -p NEC -w /lib/udev/rc_keymaps/winfast
Read winfast table
Wrote 56 keycode(s) to driver
/sys/class/rc/rc1//protocols: Invalid argument
Couldn't change the IR protocols

Vince
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
diff mbox

Patch

--- dvico_mce   2016-11-13 22:50:11.442092350 +1100
+++ testfile    2016-11-16 20:46:29.361411631 +1100
@@ -38,7 +38,7 @@ 
 0xfe03 KEY_0
 0xfe1f KEY_ZOOM
 0xfe43 KEY_REWIND
-0xfe47 KEY_PLAYPAUSE
+0xfe47 KEY_PAUSE
 0xfe4f KEY_FASTFORWARD
 0xfe57 KEY_MUTE
 0xfe0d KEY_STOP