Bug 282775

Summary:	Mouse Cursor Bounces Rapidly (zig zags) Between Multiple Displays, Pretty Much Locks Up things in X
Product:	[I don't know] kde	Reporter:	Gary Krueger <kde>
Component:	dualhead	Assignee:	Unassigned bugs mailing-list <unassigned-bugs>
Status:	RESOLVED UPSTREAM
Severity:	major	CC:	cfeck
Priority:	NOR
Version:	unspecified
Target Milestone:	---
Platform:	Fedora RPMs
OS:	Linux
Latest Commit:		Version Fixed In:
Sentry Crash Report:

Description Gary Krueger 2011-09-26 03:59:18 UTC

Version: unspecified (using KDE 4.6.5)
OS: Linux

The mouse cursor bounces rapidly between multiple displays. And, I'm locked out of doing almost everything in X.

Running PNY nVidia Quadro NVS 400 PCI 64MB DDR SDRAM. Running 3 displays without Xinerama (each display has independent workspaces).

To recover:
- telinit 3
- top
- kill Xorg with signal 9
- telinit 5

I would ordinarily assume that it is an Xorg problem, but the problem doesn't happen at the login screen (which has wallpaper on all 3 screens).

To hopefully reduce the recurrence of this problem, have set:
Pointer acceleration down from 2 to 1.5.
Pointer threshold up from 4 pixels to 8 pixels.

Reproducible: Always

Steps to Reproduce:
Very easily repeatable by moving mouse very rapidly across boundary between two displays. It then rapidly bounces on its own across the boundary.

If I move rapidly between 3 displays, it will sometimes bounce in the vicinity of both boundaries at the same time.

Actual Results:
After entering the undesired state, cannot do anything through any of the displays or inputs, except:
- Move the mouse up and down the boundary, if I try real hard.
- Change display resolution (AltCtrl+ and AltCtrl-).
- Turn on and off caps lock and num lock keys.

Nothing else works: (not even CtrlBackspace or AltCtrlDelete)

If I connect remotely, I discover that Xorg is chewing up nearly 100% CPU cycles, and it is growing at a couple of MB per second.

Expected Results:
It shouldn't hang. And the mouse shouldn't get trapped. And the Xorg process shouldn't grow rapidly, using up CPU cycles.

Using Aya theme.
Using Oxygen widget style.
Using B II decorations.
Display 1: 3hx5w workspaces
Display 2: 4hx4w workspaces
Display 3: 3hx5w workspaces
Fedora 14
No active screen edge actions. Explicitly disabled for upper left corner.
Disabled "Maximize windows by dragging them to the top of the screen"
Disabled "Tile windows by dragging them to the side of the screen"
Not using Compiz.
All displays set to 1280x1024. One display can do a higher resolution, but chose this lower resolution to keep them consistent to eliminate resolution mismatches as a cause.
Right handed mouse.
Single click to open files and folders.

It is data loss, because I have to restart the X server. And the other windows are starved for CPU cycles, so they stop accomplishing anything. And then, I have to "kill -9". So, it pretty much forgets what I was doing.

Comment 1 Gary Krueger 2011-09-26 04:01:35 UTC

I should clarify:  You need to move the mouse rapidly BACK and FORTH across the display boundary to enter the undesired state.

Comment 2 Christoph Feck 2011-09-26 10:39:18 UTC

Do you have any tool installed to help working around https://bugs.freedesktop.org/show_bug.cgi?id=20334 ?

Comment 3 Gary Krueger 2011-09-26 12:50:42 UTC

I do use a workaround, and that does remind me of some issues I had with 
mismatched resolutions:
	- I get 2 cashews on the widest display (in pixels).
	- Maximized windows occupy space beyond the right and bottom edges of
		the smaller screens (in pixels).

Anyhow, what you want to do for now, is apply to all monitors the same size in 
pixels.

Get a list of screen sizes that work for your monitors.  Choose among 
resolutions that have the same size in pixels for each monitor.

For my monitors, the common denominator is:  1280x1024

So, you go into:  /etc/X11/xorg.conf

Duplicate each of the "Modes" lines in the "Display" subsections of 
the "Screen" sections.  Comment out one of each of the lines.

Use your common denominator size as the first listed (and largest) resolution 
(if you include any other resolutions at all).

Restart your X server.

That should do it, until someone fixes the issue.  At that time, you delete or 
comment out the "Modes" lines that were used as the workaround.  And, you 
need to uncomment the "Modes" lines that you originally had.

Gary

On Monday 26 September 2011 06:39:19 Christoph Feck wrote:
> https://bugs.kde.org/show_bug.cgi?id=282775
>
>
> Christoph Feck <christoph@maxiom.de> changed:
>
>            What    |Removed                     |Added
> ---------------------------------------------------------------------------
>- CC|                            |christoph@maxiom.de
>
>
>
>
> --- Comment #2 from Christoph Feck <christoph maxiom de>  2011-09-26
> 10:39:18 --- Do you have any tool installed to help working around
> https://bugs.freedesktop.org/show_bug.cgi?id=20334 ?

Comment 4 Gary Krueger 2011-09-29 13:01:54 UTC

I have not yet found a workaround for this zig zagging mouse cursor problem.

I see that I have a habit of zig zagging the mouse around to find the cursor.  And it is hard to suppress that habit.

Nevertheless, it only takes a single quick zig & zag at the boundary to cause it to hang.  And that can happen in a moment of indecision about which display should receive the mouse cursor.

I have tested this issue on various window managers:

Window Manager      Problem
==============      =======
KDE                 yes
FVWM                no
Fedora Login Screen no
Enlightenment       yes
Gnome               no

That may help in figuring out which part of the code is likely at fault.

Comment 5 Gary Krueger 2011-09-30 14:57:31 UTC

This issue appears in other Window Managers/Desktop Environments:

Window Manager  Problem
==============  =======
e16             yes (hard to recreate)
Gnome/openbox   yes

It is looking less likely that this is any kind of KDE issue.

This needs to be pushed to XOrg to get resolved.

Comment 6 Gary Krueger 2011-10-01 00:37:57 UTC

Apparently there is already a bug report for this:

https://bugs.freedesktop.org/show_bug.cgi?id=40945

And recreating it actually requires the monitors to be sent into DPMS at least once.