Bug 46588

Forgot to add - the current package is based from git, I have also tried to use the module from git and it fails the same :(

Here is Pieter's stacktrace from the downstream bug.

(gdb) bt f
#0 0xb72023f7 in strchrnul () from /lib/i386-linux-gnu/libc.so.6
No symbol table info available.
#1 0xb71c58a9 in vfprintf () from /lib/i386-linux-gnu/libc.so.6
No symbol table info available.
#2 0xb72820d8 in __vsnprintf_chk () from /lib/i386-linux-gnu/libc.so.6
No symbol table info available.
#3 0xb76cf75d in vsnprintf (__ap=0xb72e1318 "Segmentation fault", __fmt=<optimized out>, __n=1024, __s=0xbfaf1c20 "") at /usr/include/i386-linux-gnu/bits/stdio2.h:78
No locals.
#4 VAuditF (f=0xb <Address 0xb out of bounds>, args=0xb72e1318 "Segmentation fault") at ../../os/log.c:517
        prefix = 0xb84e32e0 "AUDIT: Fri Feb 24 07:48:54 2012: 30747: "
        buf = '\000' <repeats 32 times>"\320, \034\257\277", '\000' <repeats 12 times>, "\004\035\257\277\000\000\000\000\000\000\000\000@\264L\270,\255z\264\000\000\000\000\004\000\000\000\270@\354\264\000\000\000\000\250\070a\270l\257L\270\351\201\037\267\000\000\000\000\000\000\001\000\350\000D\267\240\225F\267\260\354N\270\000\000\000\000\020\000\000\000\314\034\257\277\225\066j\000\te&\267\270@\354\264i\327\211\264\v\000\000\000\364\237S\267@\264L\270\001\000\000\000\000\000\000\000\233rR\267\370\265L\270p\263L\270\001\000\000\000\301\062\203\264\000\000\000\000\270@촰\257L\270\260\257L\270\260\257L\270\000\220z\264\230\254z\264\000\000\000\000\231D\b\000\000\000\000\000\035\002\000\000\000\000\000\000\231D\000\000\334'\214\264\b\320p\264]&R\267\257{\031\267\005\275z\264\200\257L\270\260\326R\267\000\000\000\000P\257L\270\270@\354\061\002\000\000\000\346\274z\264\250\232\066\267\025\000\000\000\364\237S\267\260y\030\267\f\000\000\000\350\266L\270\003\000\000\000\n\000\000\000f\000\000\000\000\000\000\000 \000\000\000\000\000\000\000"...
        len = -1221717224
        oldbuf = '\000' <repeats 1023 times>
#5 0x0000000b in ?? ()
No symbol table info available.
#6 0x0000000b in ?? ()
No symbol table info available.
#7 0xb72e1318 in ?? () from /lib/i386-linux-gnu/libc.so.6
No symbol table info available.
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Disclosure - We haven't yet ruled out that this might be one of the recent xserver patches in Ubuntu.

This is the config snippet he was trying to enable:

Section "InputDevice"
       Identifier "RF remote"
       Driver "evdev"
       Option "Device" "/dev/input/dvb-ir"
       Option "event_key_remap" "28=36 398=27 401=25 352=36 167=27 174=9 139=58 119=33"

Option "event_key_remap" isn't an option that evdev parses, so nothing should look at it. If you take that option out, does it work? Seems to work fine here with that config (though I don't have the rf remote device)

Hi Peter,

Thanks for the reply. When I looked at it, it works with the following config:

Section "InputDevice"
       Identifier "RF remote"
       Driver "evdev"
EndSection

Enabling any of the other lines causes the segfault.

Bryce has managed to replicated the error on his side.

That config option came from the "fact" that some input drivers can't handle "keys" with scan codes higher than 255. I still need to test if evdev is really needed in my setup, but I thought that this is a "real" bug, no matter which way I go.

Has that option been removed then ?

(In reply to comment #5)
> That config option came from the "fact" that some input drivers can't handle
> "keys" with scan codes higher than 255. 

The server can't handle those keycodes. evdev forwards them, such events just get dropped asap in the server. I understand the need for the option though.

I still need to test if evdev is really
> needed in my setup, but I thought that this is a "real" bug, no matter which
> way I go.

Please record your device description with evemu-describe and attach it here.

> Has that option been removed then ?

I can't find any notion of this option in the upstream git history. Where is it supposed to be handled?

Hi,

Is this what you are after ?

# evemu-describe /dev/input/dvb-ir 
N: cx88 IR (Hauppauge Nova-S-Plus 
I: 0001 0070 9202 0001
P: 00 00 00 00 00 00 00 00
B: 00 13 00 10 00 00 00 00 00
B: 01 fc 0f 00 10 00 00 00 00
B: 01 00 00 00 00 c0 16 9e 00
B: 01 01 48 00 00 a8 41 00 00
B: 01 00 80 11 00 00 00 00 00
B: 01 00 00 00 00 00 00 00 00
B: 01 00 00 00 00 17 20 14 02
B: 01 12 c3 af 10 00 00 00 00
B: 01 00 00 00 00 00 00 00 00
B: 01 00 00 00 00 00 00 00 00
B: 01 00 00 00 00 00 00 00 00
B: 01 00 00 00 00 00 00 00 00
B: 01 00 00 00 00 00 00 00 00
B: 02 00 00 00 00 00 00 00 00
B: 03 00 00 00 00 00 00 00 00
B: 04 10 00 00 00 00 00 00 00
B: 05 00 00 00 00 00 00 00 00
B: 11 00 00 00 00 00 00 00 00
B: 12 00 00 00 00 00 00 00 00
B: 15 00 00 00 00 00 00 00 00
B: 15 00 00 00 00 00 00 00 00

My understanding is that evdev "remaps" the event from say 398, to 27. So the X server "see" 27, not 398 (or maybe 398 followed by 27 and the 398 is dropped)

This is where the original instructions came from:

http://www.mythtv.org/wiki/Remapping_remote_control_key_codes_greater_than_255

This might be useful ?

# evtest /dev/input/dvb-ir 
Input driver version is 1.0.1
Input device ID: bus 0x1 vendor 0x70 product 0x9202 version 0x1
Input device name: "cx88 IR (Hauppauge Nova-S-Plus "
Supported events:
  Event type 0 (EV_SYN)
  Event type 1 (EV_KEY)
    Event code 2 (KEY_1)
    Event code 3 (KEY_2)
    Event code 4 (KEY_3)
    Event code 5 (KEY_4)
    Event code 6 (KEY_5)
    Event code 7 (KEY_6)
    Event code 8 (KEY_7)
    Event code 9 (KEY_8)
    Event code 10 (KEY_9)
    Event code 11 (KEY_0)
    Event code 28 (KEY_ENTER)
    Event code 102 (KEY_HOME)
    Event code 103 (KEY_UP)
    Event code 105 (KEY_LEFT)
    Event code 106 (KEY_RIGHT)
    Event code 108 (KEY_DOWN)
    Event code 113 (KEY_MUTE)
    Event code 114 (KEY_VOLUMEDOWN)
    Event code 115 (KEY_VOLUMEUP)
    Event code 116 (KEY_POWER)
    Event code 119 (KEY_PAUSE)
    Event code 128 (KEY_STOP)
    Event code 139 (KEY_MENU)
    Event code 142 (KEY_SLEEP)
    Event code 163 (KEY_NEXTSONG)
    Event code 165 (KEY_PREVIOUSSONG)
    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 212 (KEY_CAMERA)
    Event code 352 (KEY_OK)
    Event code 353 (KEY_SELECT)
    Event code 354 (KEY_GOTO)
    Event code 356 (KEY_POWER2)
    Event code 365 (KEY_EPG)
    Event code 370 (KEY_SUBTITLE)
    Event code 372 (KEY_ZOOM)
    Event code 377 (KEY_TV)
    Event code 385 (KEY_RADIO)
    Event code 388 (KEY_TEXT)
    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 405 (KEY_LAST)
    Event code 407 (KEY_NEXT)
    Event code 412 (KEY_PREVIOUS)
  Event type 4 (EV_MSC)
    Event code 4 (MSC_SCAN)
  Event type 20 (EV_REP)

Ran that device through evemu-device on top of eaba06a27c5520a02f08431ac1e4b0e0bdc22cd8 with evdev 224a28de25fda654040a9fd4e5c4d748c9e29809. Works fine. xorg.conf and log snippet below. I've tried a config with /dev/input/dvb-ir just in case the parsing of that device path fails (can't think why) and it reports no device found as expected.

Bryce, please confirm that this isn't a Ubuntu-specific problem.


Section "ServerLayout"
        Identifier "fooo"
        InputDevice "RF remote"
EndSection

Section "InputDevice"
       Identifier "RF remote"
       Driver "evdev"
        Option "Device" "/dev/input/event18"
       Option "event_key_remap" "28=36 398=27 401=25 352=36 167=27 174=9 139=58"
EndSection

[  2325.007] (II) Using input driver 'evdev' for 'RF remote'
[  2325.007]    Option "XkbRules" "evdev"
[  2325.007]    Option "XkbModel" "evdev"
[  2325.007]    Option "XkbLayout" "us"
[  2325.007]    Option "Device" "/dev/input/event18"
[  2325.007]    Option "event_key_remap" "28=36 398=27 401=25 352=36 167=27 174=9 139=58"
[  2325.007]    Option "driver" "evdev"
[  2325.007]    Option "identifier" "RF remote"
[  2325.007] (**) RF remote: always reports core events
[  2325.007] (**) evdev: RF remote: Device: "/dev/input/event18"
[  2325.007] (--) evdev: RF remote: Vendor 0x70 Product 0x9202
[  2325.007] (--) evdev: RF remote: Found keys
[  2325.007] (II) evdev: RF remote: Configuring as keyboard

I am starting to suspect the version of evdev that Ubuntu has doesn't play nice with the current server they have...

Not sure if this matters, but in my section I have the following:


Section "ServerLayout"
    Identifier     "Layout0"
    Screen      0  "Screen0" 0 0
    InputDevice    "RF remote" "SendCoreEvents"
    Option         "Xinerama" "0"
EndSection

-evdev in precise is basically the git master version.

(In reply to comment #12)
> -evdev in precise is basically the git master version.

the server has no end of patches though and I suspect it's in the server somewhere. evdev shouldn't even look at this option.

(In reply to comment #6)
> (In reply to comment #5)
> > That config option came from the "fact" that some input drivers can't handle
> > "keys" with scan codes higher than 255. 
> 
> The server can't handle those keycodes. evdev forwards them, such events just
> get dropped asap in the server. I understand the need for the option though.
> 
> I still need to test if evdev is really
> > needed in my setup, but I thought that this is a "real" bug, no matter which
> > way I go.
> 
> Please record your device description with evemu-describe and attach it here.
> 
> > Has that option been removed then ?
> 
> I can't find any notion of this option in the upstream git history. Where is it
> supposed to be handled?

What is the official recommended way to get events > 255 to work with Xorg, btw ?

(In reply to comment #14)
> What is the official recommended way to get events > 255 to work with Xorg, btw?

short answer - none. see Bug 11227

> What is the official recommended way to get events > 255 to work with
> Xorg, btw

The only thing which would work would be a fork of evdev which offset
the events coming from the kernel before passing them to the x server.

It would need its own driver name and keycodes file for
xkeyboard-config.

(The important part is to use a different keycodes set and to offset
the kernel’s event values into that set.  A different keycode set is
required for each set of 248 kernel events.)

This bug is due to a bad backport of the input option api/abi from upstream 1.12 into the ubuntu 1.11+1.12-input server. See https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/931397 for details.