|Summary:||Xorg crashes on pressing multimedia keys|
|Product:||xorg||Reporter:||Michal Suchanek <hramrach>|
|Component:||Server/Input/Core||Assignee:||Xorg Project Team <xorg-team>|
|Status:||RESOLVED FIXED||QA Contact:||Xorg Project Team <xorg-team>|
|i915 platform:||i915 features:|
|Bug Depends on:|
|Bug Blocks:||40982, 44202|
Description Michal Suchanek 2011-09-23 04:16:50 UTC
Created attachment 51538 [details] stack trace to reproduce: Start server and xscreensaver, lock screen Press a key so that dialog appeas. in quick succession press 'Esc' and 'Lock Desktop' keys. The 'Lock Desktop' key produces something very weird when pressed. I have no idea how to reproduce on a standard keyboard: ButtonPress event, serial 27, synthetic NO, window 0x2400001, root 0x151, subw 0x2400002, time 121788805, (42,35), root:(111,978), state 0x0, button 2, same_screen YES EnterNotify event, serial 27, synthetic NO, window 0x2400001, root 0x151, subw 0x0, time 121788805, (42,35), root:(111,978), mode NotifyGrab, detail NotifyInferior, same_screen YES, focus YES, state 512 KeymapNotify event, serial 27, synthetic NO, window 0x0, keys: 81 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 ButtonRelease event, serial 27, synthetic NO, window 0x2400001, root 0x151, subw 0x2400002, time 121789061, (42,35), root:(111,978), state 0x200, button 2, same_screen YES There may be other ways to reproduce but this works quite reliably. Once in the xscreensaver dialog it takes 2-3 tries to reproduce. X.Org X Server 1.11.0 Release Date: 2011-08-26 X Protocol Version 11, Revision 0 Build Operating System: Linux 3.0.0-1-amd64 x86_64 Debian Build Date: 28 August 2011 10:58:30AM xorg-server 2:1.11.0-1 (Cyril Brulebois <email@example.com>)
Comment 1 Peter Hutterer 2011-10-04 21:03:24 UTC
I think this is caused by a keyboard device sending pointer events (shouldn't happen in the WarpPointer path, but...). See Bug 38313. http://lists.freedesktop.org/archives/xorg-devel/2011-September/024946.html, still waiting for reviews.
Comment 2 Michal Suchanek 2011-10-05 02:07:17 UTC
Still happens with the two-screen-coordinates branch so I guess it's not that.
Comment 3 Peter Hutterer 2011-10-05 19:32:45 UTC
(In reply to comment #2) > Still happens with the two-screen-coordinates branch so I guess it's not that. can you get me a stacktrace with debug symbols? I also need to see pDev->name when this happens, xinput list --long and your xorg.conf (if you have any).
Comment 4 Michal Suchanek 2011-10-06 04:32:23 UTC
Created attachment 52040 [details] stack trace with device name
Comment 6 Jeremy Huddleston Sequoia 2011-10-08 23:55:55 UTC
Is this new to 1.11?
Comment 7 Michal Suchanek 2011-10-09 00:50:03 UTC
I think the first crash was with 10.4 but I am not sure. I did not try old X servers.
Comment 8 Michal Suchanek 2011-10-10 09:25:39 UTC
With 1.10.4 this issue is present. It's as old as I can get on this hardware, older X servers would not run on the graphics card.
Comment 9 Michal Suchanek 2012-02-23 09:28:19 UTC
With X server 22.214.171.1242 (1.12.0 RC 2) I get this log: ==26003== Invalid read of size 4 ==26003== at 0x170265: GetPointerEvents (getevents.c:1494) ==26003== by 0x17076C: QueuePointerEvents (getevents.c:1203) ==26003== by 0x1A6F5C: xf86PostButtonEvent (xf86Xinput.c:1174) ==26003== by 0xD1D1E67: EvdevReadInput (evdev.c:945) ==26003== by 0x196886: xf86SigioReadInput (xf86Events.c:298) ==26003== by 0x1BC1BD: xf86SIGIO (sigio.c:109) ==26003== by 0x56D502F: ??? (in /lib/x86_64-linux-gnu/libpthread-2.13.so) ==26003== by 0x69223E0: __select_nocancel (syscall-template.S:82) ==26003== by 0x28D7AA: WaitForSomething (WaitFor.c:232) ==26003== by 0x15A791: Dispatch (dispatch.c:366) ==26003== by 0x1499E9: main (main.c:287) ==26003== Address 0x60 is not stack'd, malloc'd or (recently) free'd poking around a bit it seems that pressing the "Desktop Lock" button on my keyboard causes mouse button press on a keyboard device. In GetPointerEvents valuator is dereferenced which is NULL on a keyboard leading to this crash. So either valuators should be defined on a keyboard (and generally keyboards and mice should be interchangeable even if there are separate functions for them) or there needs to be a guard against queuing button events on a keyboard. Note that xinput lists the keyboard twice, once with buttons and once without, both attached as keyboard. I suspect this is the root cause of the issue. It looks like at some point something tried to create a mouse device for the multimedia buttons of the keyboard but created another keyboard instead.
Comment 10 Michal Suchanek 2012-02-24 05:48:37 UTC
Tried to swap the order in which device types are assigned in evdev. I get (**) evdev: Lite-On Technology USB Productivity Option Keyboard( has the hub in # 1 ): Device: "/dev/input/event1" (--) evdev: Lite-On Technology USB Productivity Option Keyboard( has the hub in # 1 ): Vendor 0x4b3 Product 0x301b (--) evdev: Lite-On Technology USB Productivity Option Keyboard( has the hub in # 1 ): Found 12 mouse buttons (--) evdev: Lite-On Technology USB Productivity Option Keyboard( has the hub in # 1 ): Found keys (II) evdev: Lite-On Technology USB Productivity Option Keyboard( has the hub in # 1 ): Configuring as keyboard (II) evdev: Lite-On Technology USB Productivity Option Keyboard( has the hub in # 1 ): Configuring as mouse That is, the device is first assigned the keyboard type and it is then overwritten with the mouse type, not the other way around. However, even then X happily connects it to core keyboard and crashes whenever the lock desktop key is pressed.
Comment 11 Michal Suchanek 2012-02-24 06:06:23 UTC
Created attachment 57593 [details] X log (note two keyboards, one is physically attached)
Comment 12 Michal Suchanek 2012-02-27 05:05:12 UTC
Created attachment 57712 [details] evdev patch to configure keyboard with mouse buttons as mouse There is something seriously flawed. Applying this evdev patch the part of the keyboard with buttons is configured as mouse, it no longer shows the xkb options in the log. However, xinput still lists both attached as slave keyboards.
Comment 13 Peter Hutterer 2012-02-27 18:53:45 UTC
did you try the fix for #38313? http://patchwork.freedesktop.org/patch/9199/ the stacktrace from comment 4 suggests it's the same issue.
Comment 14 Michal Suchanek 2012-02-28 10:55:17 UTC
Created attachment 57777 [details] [review] patch for 126.96.36.1991 This similar patch avoids the crash on 188.8.131.521 which builds for me. Note that on 184.108.40.2061 before the input changes it is required to lock the screen with xscreensaver (grab pointer/keyboard ?) to get the crash. On 1.12 it crashes always.
Comment 15 Peter Hutterer 2012-02-28 22:43:27 UTC
Comment on attachment 57777 [details] [review] patch for 220.127.116.111 Review of attachment 57777 [details] [review]: ----------------------------------------------------------------- looks ok in principle but needs better integration. e.g. in the first hunk that whole function can skip altogether if !dev->valuator. also, git-formatted patches please.
Comment 16 Michal Suchanek 2012-02-29 07:07:30 UTC
Created attachment 57809 [details] [review] patch for 1.11.4 Thanks for your review. I am not sure what exactly the function is doing, just added some guard against dereferencing nonexistent values. Indeed, the X server reports that the event was ignored with the patch applied so I guess it is OK to do nothing at all. Attaching a git format patch.
Comment 17 Michal Suchanek 2012-02-29 07:20:13 UTC
Created attachment 57810 [details] [review] updated patch for 1.11.4 Looking at the patch again it seems the axis number checks should be different. They are not used in my case because the valuator is missing completely so don't have testing for those.
Comment 18 Jeremy Huddleston Sequoia 2012-03-24 11:46:31 UTC
Please send your patch to xorg-devel for discussion.
Comment 19 Michal Suchanek 2012-06-13 06:52:37 UTC
fixed in 472c2d1af75d8e321728589e377f73116adb29fa and 88c767edb01ed7efb19ffe3a453e16107b27130b