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 <kibi@debian.org>)
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.
Still happens with the two-screen-coordinates branch so I guess it's not that.
(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).
Created attachment 52040 [details] stack trace with device name
Created attachment 52041 [details] device list
Is this new to 1.11?
I think the first crash was with 10.4 but I am not sure. I did not try old X servers.
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.
With X server 1.11.99.902 (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.
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.
Created attachment 57593 [details] X log (note two keyboards, one is physically attached)
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.
did you try the fix for #38313? http://patchwork.freedesktop.org/patch/9199/ the stacktrace from comment 4 suggests it's the same issue.
Created attachment 57777 [details] [review] patch for 1.11.3.901 This similar patch avoids the crash on 1.11.3.901 which builds for me. Note that on 1.11.3.901 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 on attachment 57777 [details] [review] patch for 1.11.3.901 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.
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.
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.
Please send your patch to xorg-devel for discussion.
fixed in 472c2d1af75d8e321728589e377f73116adb29fa and 88c767edb01ed7efb19ffe3a453e16107b27130b
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.