Steps to reproduce: - you need a graphic card with at least two display ports - configure the two screens as separate X-Screens (:0.0 and :0.1, it does not occur when using xinerama!) - use a window manager of your choice (tested with kde and fvwm2) - open an xterm and enter 'sleep 5 && xset dpms force off' - in the remaining five seconds place the mouse cursor in the middle between the two screens - wait until the monitors go into dpms mode - wake up the monitors by moving the mouse, make sure you cross the screen boundary of the two screens more than once - move it fast left and right so it crosses the boundary more than once! - X is locked up - the mouse cursor is flickering between the two screens and does no longer react, the only solution is to restart X See also http://www.nvnews.net/vbulletin/showthread.php?t=159334#4 - I could not find a corresponding bug report here therefore I wrote a new one. We only tested it with two monitors connected via DisplayPort - we will also check if it also occurs when using HDMI. Any idea what's going wrong here or where we can start to debug?
This issue seems to happen anytime that the CPU is saturated and the user zig zags (usually just once) between any two displays. Interestingly, you can see the mouse bounce on both sides of both boundaries at the same time between triple heads, if you do the zig zag across both boundaries quickly. I am using the 3 separate X-Screens (no Xinerama). Have observed the problem in: KDE, Enlightenment, e16, Gnome/openbox Note also, that it starts chewing memory (if you log in remotely and run "top", you will see it). The place to look should be in code that locates or renders the cursor. It seems as though a callback to place the mouse cursor on one screen is essentially fighting with a callback to place it on the other screen. It must be some sort of update callback after attempting to render a mouse that has run off of the edge of a screen. I find this to be a very painful issue. For example, if I restart a crashed browser (uses lots of CPU cycles) and have any indecision about where to place the mouse (if it is near the edge of the screen), it will hang, taking the other 20 windows I had open along with it. Up until this bug, I've had a habit of zig zagging the mouse cursor in order to find it. Now, I try to remember to first look carefully for it before trying to move it. Painful.
(In reply to comment #1) > This issue seems to happen anytime that the CPU is saturated and the user zig > zags (usually just once) between any two displays. > > Interestingly, you can see the mouse bounce on both sides of both boundaries at > the same time between triple heads, if you do the zig zag across both > boundaries quickly. > > I am using the 3 separate X-Screens (no Xinerama). > Have observed the problem in: KDE, Enlightenment, e16, Gnome/openbox > > Note also, that it starts chewing memory (if you log in remotely and run "top", > you will see it). > > The place to look should be in code that locates or renders the cursor. It > seems as though a callback to place the mouse cursor on one screen is > essentially fighting with a callback to place it on the other screen. It must > be some sort of update callback after attempting to render a mouse that has run > off of the edge of a screen. > > I find this to be a very painful issue. For example, if I restart a crashed > browser (uses lots of CPU cycles) and have any indecision about where to place > the mouse (if it is near the edge of the screen), it will hang, taking the > other 20 windows I had open along with it. > > Up until this bug, I've had a habit of zig zagging the mouse cursor in order to > find it. Now, I try to remember to first look carefully for it before trying > to move it. Painful. This is on an Intel Celeron 2.40GHz CPU. X.Org X Server 1.6.3.901 (1.6.4 RC 1) Release Date: 2009-8-25 xorg-x11-server-Xorg.i586 1.6.4-0.1.fc11 Not using any screen savers, blanking, locking, etc. Looks like it has been an issue for at least a year. Sorry that I'm not using the latest version. But, seeing as the issue is in the latest versions, there is not much point in updating.
I run multiple hiding desktop panels. I have found that if I quickly zig zag the mouse across display boundaries (usually unintentionally), activating one or more hiding panels, the hang almost assuredly happens. So, I've reconfigured KDE from the default: from: Low display resolution and High CPU to: High display resolution and Low CPU which is in System Settings-> Application Appearance-> Style-> Fine Tuning-> Graphical Effects Hopefully, this reduces the occurrence of these freeze-outs (usually more than once a day). I expect to report back on the degree of success.
I was now able to debug this bug and found the culprit. The problem seems to be that there are two ET_Motion - events in the event queue. One of them is on screen 1 and one on screen 0. Since such an event triggers a new ET_Motion event we're in an endless loop. Here some outputs to show my findings: -----------------------------------8<---------- Breakpoint 7, GetPointerEvents (events=<value optimized out>, pDev=0x133a1b0, type=<value optimized out>, buttons=<value optimized out>, flags=<value optimized out>, first_valuator=0, num_valuators=2, valuators=0x7fff29652d90) at getevents.c:1102 1102 event->type = ET_Motion; (gdb) p *event $50 = {header = 255 '\377', type = 0, length = 408, time = 17041032, deviceid = 9, sourceid = 9, detail = {button = 0, key = 0}, root_x = 0, root_x_frac = 0, root_y = 0, root_y_frac = 0, buttons = '\000' <repeats 31 times>, valuators = {mask = "\000\000\000\000", mode = "\000\000\000\000", data = {0 <repeats 36 times>}, data_frac = {0 <repeats 36 times>}}, mods = {base = 0, latched = 0, locked = 0, effective = 0}, group = {base = 0 '\000', latched = 0 '\000', locked = 0 '\000', effective = 0 '\000'}, root = 0, corestate = 0, key_repeat = 0} (gdb) c Continuing. Breakpoint 3, mieqProcessDeviceEvent (dev=0x133a1b0, event=0x1321360, screen=0xbaa050) at mieq.c:385 385 DequeueScreen(dev) = screen; (gdb) p *event $51 = {any = {header = 255 '\377', type = ET_Motion, length = 408, time = 16835079}, device_event = {header = 255 '\377', type = ET_Motion, length = 408, time = 16835079, deviceid = 9, sourceid = 9, detail = {button = 0, key = 0}, root_x = 1675, root_x_frac = 0, root_y = 306, root_y_frac = 0, buttons = '\000' <repeats 31 times>, valuators = {mask = "\003\000\000\000", mode = "\000\000\000\000", data = {1675, 306, 0 <repeats 34 times>}, data_frac = {0 <repeats 36 times>}}, mods = {base = 0, latched = 0, locked = 0, effective = 0}, group = { base = 0 '\000', latched = 0 '\000', locked = 0 '\000', effective = 0 '\000'}, root = 0, corestate = 0, key_repeat = 0}, changed_event = { header = 255 '\377', type = ET_Motion, length = 408, time = 16835079, deviceid = 9, flags = 9, masterid = 0, sourceid = 1675, buttons = { num_buttons = 0, names = {306, 0, 0, 0, 0, 0, 0, 0, 0, 0, 3, 0, 0, 1675, 306, 0 <repeats 241 times>}}, num_valuators = 0, valuators = {{ min = 0, max = 0, resolution = 0, mode = 0 '\000', name = 0} <repeats 36 times>}, keys = {min_keycode = 0, max_keycode = 0}}, dga_event = { header = 255 '\377', type = ET_Motion, length = 408, time = 16835079, subtype = 9, detail = 9, dx = 0, dy = 1675, screen = 0, state = 306}, raw_event = {header = 255 '\377', type = ET_Motion, length = 408, time = 16835079, deviceid = 9, sourceid = 9, detail = {button = 0, key = 0}, valuators = {mask = "\213\006\000\000", data = {306, 0, 0, 0, 0, 0, 0, 0, 0, 0, 3, 0, 0, 1675, 306, 0 <repeats 21 times>}, data_frac = { 0 <repeats 36 times>}, data_raw = {0 <repeats 36 times>}, data_raw_frac = {0 <repeats 36 times>}}}} (gdb) c Continuing. Breakpoint 7, GetPointerEvents (events=<value optimized out>, pDev=0x133a1b0, type=<value optimized out>, buttons=<value optimized out>, flags=<value optimized out>, first_valuator=0, num_valuators=2, valuators=0x7fff29652d90) at getevents.c:1102 1102 event->type = ET_Motion; (gdb) p *event $52 = {header = 255 '\377', type = 0, length = 408, time = 17057799, deviceid = 9, sourceid = 9, detail = {button = 0, key = 0}, root_x = 0, root_x_frac = 0, root_y = 0, root_y_frac = 0, buttons = '\000' <repeats 31 times>, valuators = {mask = "\000\000\000\000", mode = "\000\000\000\000", data = {0 <repeats 36 times>}, data_frac = {0 <repeats 36 times>}}, mods = {base = 0, latched = 0, locked = 0, effective = 0}, group = {base = 0 '\000', latched = 0 '\000', locked = 0 '\000', effective = 0 '\000'}, root = 0, corestate = 0, key_repeat = 0} (gdb) c Continuing. Breakpoint 3, mieqProcessDeviceEvent (dev=0x133a1b0, event=0x1321360, screen=0xbf23b0) at mieq.c:385 385 DequeueScreen(dev) = screen; (gdb) p *event $53 = {any = {header = 255 '\377', type = ET_Motion, length = 408, time = 17041032}, device_event = {header = 255 '\377', type = ET_Motion, length = 408, time = 17041032, deviceid = 9, sourceid = 9, detail = {button = 0, key = 0}, root_x = 6, root_x_frac = 0, root_y = 299, root_y_frac = 0, buttons = '\000' <repeats 31 times>, valuators = {mask = "\003\000\000\000", mode = "\000\000\000\000", data = {6, 299, 0 <repeats 34 times>}, data_frac = {0 <repeats 36 times>}}, mods = {base = 0, latched = 0, locked = 0, effective = 0}, group = { base = 0 '\000', latched = 0 '\000', locked = 0 '\000', effective = 0 '\000'}, root = 0, corestate = 0, key_repeat = 0}, changed_event = { header = 255 '\377', type = ET_Motion, length = 408, time = 17041032, deviceid = 9, flags = 9, masterid = 0, sourceid = 6, buttons = { num_buttons = 0, names = {299, 0, 0, 0, 0, 0, 0, 0, 0, 0, 3, 0, 0, 6, 299, 0 <repeats 241 times>}}, num_valuators = 0, valuators = {{ min = 0, max = 0, resolution = 0, mode = 0 '\000', name = 0} <repeats 36 times>}, keys = {min_keycode = 0, max_keycode = 0}}, dga_event = { header = 255 '\377', type = ET_Motion, length = 408, time = 17041032, subtype = 9, detail = 9, dx = 0, dy = 6, screen = 0, state = 299}, raw_event = {header = 255 '\377', type = ET_Motion, length = 408, time = 17041032, deviceid = 9, sourceid = 9, detail = {button = 0, key = 0}, valuators = {mask = "\006\000\000\000", data = {299, 0, 0, 0, 0, 0, 0, 0, 0, 0, 3, 0, 0, 6, 299, 0 <repeats 21 times>}, data_frac = { 0 <repeats 36 times>}, data_raw = {0 <repeats 36 times>}, data_raw_frac = {0 <repeats 36 times>}}}} -----------------------------------8<---------- As you can see here a new event with id 17041032 is created. Then the old motion event is handled which also creates a new ET_Motion event. Now the event with id 17041032 is handled ... And here a backtrace if this helps: -----------------------------------8<---------- #0 0x00007fcb46603f22 in ?? () from /usr/lib64/xorg/modules/updates/drivers/nvidia_drv.so #1 0x00007fcb46604e0d in ?? () from /usr/lib64/xorg/modules/updates/drivers/nvidia_drv.so #2 0x00007fcb465ed615 in ?? () from /usr/lib64/xorg/modules/updates/drivers/nvidia_drv.so #3 0x0000000000574f7d in xf86SetCursor (pScreen=0xbaa050, pCurs=0x148a480, x=1669, y=302) at xf86HWCurs.c:144 #4 0x000000000054a490 in xf86CursorSetCursor (pDev=0x133a1b0, pScreen=0xbaa050, pCurs=0x148a480, x=1675, y=306) at xf86Cursor.c:350 #5 0x0000000000459df7 in miPointerUpdateSprite (pDev=0x133a1b0) at mipointer.c:403 #6 0x000000000045a01f in miPointerDisplayCursor (pDev=0x133a1b0, pScreen=0xbaa050, pCursor=0x148a480) at mipointer.c:197 #7 0x0000000000493e31 in CursorDisplayCursor (pDev=0x133a1b0, pScreen=0xbaa050, pCursor=0x148a480) at cursor.c:157 #8 0x00000000004b850f in AnimCurDisplayCursor (pDev=0x133a1b0, pScreen=0xbaa050, pCursor=0x148a480) at animcur.c:247 #9 0x000000000042a0b6 in UpdateSpriteForScreen (pDev=0x133a1b0, pScreen=0xbaa050) at events.c:3127 #10 0x0000000000459bab in miPointerWarpCursor (pDev=0x133a1b0, pScreen=0xbaa050, x=<value optimized out>, y=<value optimized out>) at mipointer.c:343 #11 0x0000000000471ce1 in xf86WarpCursor (pDev=0x133a1b0, pScreen=0xbaa050, x=1675, y=306) at xf86Cursor.c:473 #12 0x0000000000459f4c in miPointerSetCursorPosition (pDev=0x133a1b0, pScreen=0xbaa050, x=1675, y=306, generateEvent=1) at mipointer.c:239 #13 0x00000000004b81a3 in AnimCurSetCursorPosition (pDev=0x133a1b0, pScreen=0xbaa050, x=1675, y=306, generateEvent=<value optimized out>) at animcur.c:266 #14 0x0000000000428fe7 in CheckPhysLimits (pDev=0x133a1b0, cursor=<value optimized out>, generateEvents=1, confineToScreen=0, pScreen=0xbaa050) at events.c:796 #15 0x000000000048e1fa in mieqProcessDeviceEvent (dev=0x133a1b0, event=0x1321360, screen=0xbaa050) at mieq.c:388 #16 0x000000000048e32b in mieqProcessInputEvents () at mieq.c:471 #17 0x000000000046b779 in ProcessInputEvents () at xf86Events.c:166 #18 0x0000000000445323 in Dispatch () at dispatch.c:371 #19 0x0000000000425f3a in main (argc=<value optimized out>, argv=0x7fff29653878, envp=<value optimized out>) at main.c:286 -----------------------------------8<---------- Now we really need somebody with more knowledge of the internals. Why does the x-server create an additional ET_Motion event?
Howdy Christian! Fabulous! I wouldn't know why there would be 2 of them. This happens when you pass in just one direction? Or, is it only when you pass quickly in both directions? On Tuesday 11 October 2011 12:36:36 daemon wrote: > https://bugs.freedesktop.org/show_bug.cgi?id=40945 > > --- Comment #4 from Christian Ehrlicher <ch.ehrlicher@gmx.de> 2011-10-11 > 09:36:36 PDT --- I was now able to debug this bug and found the culprit. > The problem seems to be that there are two ET_Motion - events in the event > queue. One of them is on screen 1 and one on screen 0. Since such an event > triggers a new ET_Motion event we're in an endless loop. > > Here some outputs to show my findings: > -----------------------------------8<---------- > Breakpoint 7, GetPointerEvents (events=<value optimized out>, > pDev=0x133a1b0, type=<value optimized out>, buttons=<value optimized out>, > flags=<value optimized out>, first_valuator=0, num_valuators=2, > valuators=0x7fff29652d90) at getevents.c:1102 > 1102 event->type = ET_Motion; > (gdb) p *event > $50 = {header = 255 '\377', type = 0, length = 408, time = 17041032, > deviceid = 9, sourceid = 9, detail = {button = 0, key = 0}, root_x = 0, > root_x_frac = 0, root_y = 0, root_y_frac = 0, buttons = '\000' <repeats > 31 times>, valuators = {mask = "\000\000\000\000", > mode = "\000\000\000\000", data = {0 <repeats 36 times>}, data_frac = > {0 <repeats 36 times>}}, mods = {base = 0, latched = 0, locked = 0, > effective = 0}, group = {base = 0 '\000', latched = 0 '\000', locked = > 0 '\000', effective = 0 '\000'}, root = 0, corestate = 0, > key_repeat = 0} > (gdb) c > Continuing. > > Breakpoint 3, mieqProcessDeviceEvent (dev=0x133a1b0, event=0x1321360, > screen=0xbaa050) at mieq.c:385 > 385 DequeueScreen(dev) = screen; > (gdb) p *event > $51 = {any = {header = 255 '\377', type = ET_Motion, length = 408, time = > 16835079}, device_event = {header = 255 '\377', type = ET_Motion, > length = 408, time = 16835079, deviceid = 9, sourceid = 9, detail = > {button = 0, key = 0}, root_x = 1675, root_x_frac = 0, root_y = 306, > root_y_frac = 0, buttons = '\000' <repeats 31 times>, valuators = {mask > = "\003\000\000\000", mode = "\000\000\000\000", data = {1675, 306, > 0 <repeats 34 times>}, data_frac = {0 <repeats 36 times>}}, mods = > {base = 0, latched = 0, locked = 0, effective = 0}, group = { > base = 0 '\000', latched = 0 '\000', locked = 0 '\000', effective = 0 > '\000'}, root = 0, corestate = 0, key_repeat = 0}, changed_event = { > header = 255 '\377', type = ET_Motion, length = 408, time = 16835079, > deviceid = 9, flags = 9, masterid = 0, sourceid = 1675, buttons = { > num_buttons = 0, names = {306, 0, 0, 0, 0, 0, 0, 0, 0, 0, 3, 0, 0, > 1675, 306, 0 <repeats 241 times>}}, num_valuators = 0, valuators = {{ > min = 0, max = 0, resolution = 0, mode = 0 '\000', name = 0} > <repeats 36 times>}, keys = {min_keycode = 0, max_keycode = 0}}, dga_event > = { header = 255 '\377', type = ET_Motion, length = 408, time = 16835079, > subtype = 9, detail = 9, dx = 0, dy = 1675, screen = 0, state = 306}, > raw_event = {header = 255 '\377', type = ET_Motion, length = 408, time = > 16835079, deviceid = 9, sourceid = 9, detail = {button = 0, key = 0}, > valuators = {mask = "\213\006\000\000", data = {306, 0, 0, 0, 0, 0, 0, 0, > 0, 0, 3, 0, 0, 1675, 306, 0 <repeats 21 times>}, data_frac = { > 0 <repeats 36 times>}, data_raw = {0 <repeats 36 times>}, > data_raw_frac = {0 <repeats 36 times>}}}} > (gdb) c > Continuing. > > Breakpoint 7, GetPointerEvents (events=<value optimized out>, > pDev=0x133a1b0, type=<value optimized out>, buttons=<value optimized out>, > flags=<value optimized out>, first_valuator=0, num_valuators=2, > valuators=0x7fff29652d90) at getevents.c:1102 > 1102 event->type = ET_Motion; > (gdb) p *event > $52 = {header = 255 '\377', type = 0, length = 408, time = 17057799, > deviceid = 9, sourceid = 9, detail = {button = 0, key = 0}, root_x = 0, > root_x_frac = 0, root_y = 0, root_y_frac = 0, buttons = '\000' <repeats > 31 times>, valuators = {mask = "\000\000\000\000", > mode = "\000\000\000\000", data = {0 <repeats 36 times>}, data_frac = > {0 <repeats 36 times>}}, mods = {base = 0, latched = 0, locked = 0, > effective = 0}, group = {base = 0 '\000', latched = 0 '\000', locked = > 0 '\000', effective = 0 '\000'}, root = 0, corestate = 0, > key_repeat = 0} > (gdb) c > Continuing. > > Breakpoint 3, mieqProcessDeviceEvent (dev=0x133a1b0, event=0x1321360, > screen=0xbf23b0) at mieq.c:385 > 385 DequeueScreen(dev) = screen; > (gdb) p *event > $53 = {any = {header = 255 '\377', type = ET_Motion, length = 408, time = > 17041032}, device_event = {header = 255 '\377', type = ET_Motion, > length = 408, time = 17041032, deviceid = 9, sourceid = 9, detail = > {button = 0, key = 0}, root_x = 6, root_x_frac = 0, root_y = 299, > root_y_frac = 0, buttons = '\000' <repeats 31 times>, valuators = {mask > = "\003\000\000\000", mode = "\000\000\000\000", data = {6, 299, > 0 <repeats 34 times>}, data_frac = {0 <repeats 36 times>}}, mods = > {base = 0, latched = 0, locked = 0, effective = 0}, group = { > base = 0 '\000', latched = 0 '\000', locked = 0 '\000', effective = 0 > '\000'}, root = 0, corestate = 0, key_repeat = 0}, changed_event = { > header = 255 '\377', type = ET_Motion, length = 408, time = 17041032, > deviceid = 9, flags = 9, masterid = 0, sourceid = 6, buttons = { > num_buttons = 0, names = {299, 0, 0, 0, 0, 0, 0, 0, 0, 0, 3, 0, 0, 6, > 299, 0 <repeats 241 times>}}, num_valuators = 0, valuators = {{ > min = 0, max = 0, resolution = 0, mode = 0 '\000', name = 0} > <repeats 36 times>}, keys = {min_keycode = 0, max_keycode = 0}}, dga_event > = { header = 255 '\377', type = ET_Motion, length = 408, time = 17041032, > subtype = 9, detail = 9, dx = 0, dy = 6, screen = 0, state = 299}, > raw_event = {header = 255 '\377', type = ET_Motion, length = 408, time = > 17041032, deviceid = 9, sourceid = 9, detail = {button = 0, key = 0}, > valuators = {mask = "\006\000\000\000", data = {299, 0, 0, 0, 0, 0, 0, 0, > 0, 0, 3, 0, 0, 6, 299, 0 <repeats 21 times>}, data_frac = { > 0 <repeats 36 times>}, data_raw = {0 <repeats 36 times>}, > data_raw_frac = {0 <repeats 36 times>}}}} > > -----------------------------------8<---------- > As you can see here a new event with id 17041032 is created. Then the old > motion event is handled which also creates a new ET_Motion event. Now the > event with id 17041032 is handled ... > > And here a backtrace if this helps: > -----------------------------------8<---------- > #0 0x00007fcb46603f22 in ?? () from > /usr/lib64/xorg/modules/updates/drivers/nvidia_drv.so > #1 0x00007fcb46604e0d in ?? () from > /usr/lib64/xorg/modules/updates/drivers/nvidia_drv.so > #2 0x00007fcb465ed615 in ?? () from > /usr/lib64/xorg/modules/updates/drivers/nvidia_drv.so > #3 0x0000000000574f7d in xf86SetCursor (pScreen=0xbaa050, pCurs=0x148a480, > x=1669, y=302) at xf86HWCurs.c:144 > #4 0x000000000054a490 in xf86CursorSetCursor (pDev=0x133a1b0, > pScreen=0xbaa050, pCurs=0x148a480, x=1675, y=306) at xf86Cursor.c:350 > #5 0x0000000000459df7 in miPointerUpdateSprite (pDev=0x133a1b0) at > mipointer.c:403 > #6 0x000000000045a01f in miPointerDisplayCursor (pDev=0x133a1b0, > pScreen=0xbaa050, pCursor=0x148a480) at mipointer.c:197 > #7 0x0000000000493e31 in CursorDisplayCursor (pDev=0x133a1b0, > pScreen=0xbaa050, pCursor=0x148a480) at cursor.c:157 > #8 0x00000000004b850f in AnimCurDisplayCursor (pDev=0x133a1b0, > pScreen=0xbaa050, pCursor=0x148a480) at animcur.c:247 > #9 0x000000000042a0b6 in UpdateSpriteForScreen (pDev=0x133a1b0, > pScreen=0xbaa050) at events.c:3127 > #10 0x0000000000459bab in miPointerWarpCursor (pDev=0x133a1b0, > pScreen=0xbaa050, x=<value optimized out>, y=<value optimized out>) at > mipointer.c:343 > #11 0x0000000000471ce1 in xf86WarpCursor (pDev=0x133a1b0, pScreen=0xbaa050, > x=1675, y=306) at xf86Cursor.c:473 > #12 0x0000000000459f4c in miPointerSetCursorPosition (pDev=0x133a1b0, > pScreen=0xbaa050, x=1675, y=306, generateEvent=1) at mipointer.c:239 > #13 0x00000000004b81a3 in AnimCurSetCursorPosition (pDev=0x133a1b0, > pScreen=0xbaa050, x=1675, y=306, generateEvent=<value optimized out>) at > animcur.c:266 > #14 0x0000000000428fe7 in CheckPhysLimits (pDev=0x133a1b0, cursor=<value > optimized out>, generateEvents=1, confineToScreen=0, pScreen=0xbaa050) at > events.c:796 > #15 0x000000000048e1fa in mieqProcessDeviceEvent (dev=0x133a1b0, > event=0x1321360, screen=0xbaa050) at mieq.c:388 > #16 0x000000000048e32b in mieqProcessInputEvents () at mieq.c:471 > #17 0x000000000046b779 in ProcessInputEvents () at xf86Events.c:166 > #18 0x0000000000445323 in Dispatch () at dispatch.c:371 > #19 0x0000000000425f3a in main (argc=<value optimized out>, > argv=0x7fff29653878, envp=<value optimized out>) at main.c:286 > -----------------------------------8<---------- > > Now we really need somebody with more knowledge of the internals. Why does > the x-server create an additional ET_Motion event?
Is this new to the 1.11 server?
No. I'm running 1.5.2. By the way, my triple head hasn't crashed since early yesterday when I reduced the CPU usage of the hiding panels in KDE. So, that helps. But that, of course, doesn't solve the problem. It just makes it a little bit less of an issue for me. On Tuesday 11 October 2011 13:38:04 daemon wrote: > https://bugs.freedesktop.org/show_bug.cgi?id=40945 > > Jeremy Huddleston <jeremyhu@freedesktop.org> changed: > > What |Removed |Added > --------------------------------------------------------------------------- >- Status Whiteboard| |2011BRB_Reviewed > CC| |jeremyhu@freedesktop.org, > > | |peter.hutterer@who-t.net > > --- Comment #6 from Jeremy Huddleston <jeremyhu@freedesktop.org> 2011-10-11 > 10:38:04 PDT --- Is this new to the 1.11 server?
(In reply to comment #5) > Or, is it only when you pass quickly in both directions? I'm not sure - my repro is to move the cursor fast over the screen border. You can take a looke by yourself if you've the same problem when you ssh into your box once x11 is screwed up and debug the x server. when you see mieqProcessInputEvents in the backtrace you've the same problem.
Well, that would be both directions, because I've never heard of it happening with a slow one-way movement over the border. It would explain why you are seeing 2 events. The problem occurs when the CPU usage is high. So what is happening, is that the events are entering the queue faster than they are cleared from the queue. But that shouldn't be sufficient to cause the problem. Likely something about mi/mieq.c sets out to handle both events, but fails to clear them. I'm not yet set up to debug or repair this. I'm not yet sure whether I'll have the opportunity to do so. On Tuesday 11 October 2011 16:18:21 daemon wrote: > https://bugs.freedesktop.org/show_bug.cgi?id=40945 > > --- Comment #8 from Christian Ehrlicher <ch.ehrlicher@gmx.de> 2011-10-11 > 13:18:21 PDT --- (In reply to comment #5) > > > Or, is it only when you pass quickly in both directions? > > I'm not sure - my repro is to move the cursor fast over the screen border. > You can take a looke by yourself if you've the same problem when you ssh > into your box once x11 is screwed up and debug the x server. when you see > mieqProcessInputEvents in the backtrace you've the same problem.
As I already said - since the screen crossing creates a new ET_Motion added to the end of the queue you have an endless loop. The question now is - why does the server create a second ET_Motion event.
(In reply to comment #10) > As I already said - since the screen crossing creates a new ET_Motion added to > the end of the queue you have an endless loop. The question now is - why does > the server create a second ET_Motion event. crossing between screens triggers a call to xf86WarpCursor which then calls miPointerWarpPointer. That needs to generate a motion event. I've seen this issue multiple times and fixed at least one instance of it but haven't been able to trigger this reliably enough for debugging since.
Sorry. Just very eager to see this repaired. On Wednesday 12 October 2011 00:33:00 daemon wrote: > https://bugs.freedesktop.org/show_bug.cgi?id=40945 > > --- Comment #10 from Christian Ehrlicher <ch.ehrlicher@gmx.de> 2011-10-11 > 21:33:00 PDT --- As I already said - since the screen crossing creates a > new ET_Motion added to the end of the queue you have an endless loop. The > question now is - why does the server create a second ET_Motion event.
(In reply to comment #12) > Sorry. Just very eager to see this repaired. Well as Peter mentioned, he has already fixed one instance of this issue. I suggest you update your server to a modern version and see if that helps.
Can we have a commit id for this fix? Maybe I can backport it to 1.8 ( the one used in opensuse 11.3 ) and see if it helps. And if it's in 1.10 I can maybe use the prebuild packages from opensuse build service.
I could test it with a 1.10.4 - prebuild rpm from openSUSE and could not reproduce it anymore.
Howdy there! Well, I thought that I was going to have to say that I cannot test this. I wanted to upgrade to the latest version of Fedora, which has 1.10.4. But, I had so much trouble getting the upgrade to work, that I decided to install Ubuntu, instead. When I installed it, I could see that it was an older version of the X Server. But, it appears to be up to date now. I have 1.10.4, and I see no issues whatsoever with a trapped cursor. I've been using it for weeks now. I cannot even seem to force it to fail. Thank you, Gary On Friday 04 November 2011 12:18:58 daemon wrote: > https://bugs.freedesktop.org/show_bug.cgi?id=40945 > > --- Comment #15 from Christian Ehrlicher <ch.ehrlicher@gmx.de> 2011-11-04 > 09:18:58 PDT --- I could test it with a 1.10.4 - prebuild rpm from openSUSE > and could not reproduce it anymore.
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.