Bug 150303

This is proper multiple X displays, not Xinerama, we're talking about?

Right, not Xinerama.

It may be that Konsole uses the screen number, instead of the orientation directions ("left of" "right of") to figure out where the display is located.  So, that would need to be corrected in Konsole (or whatever it is that Konsole uses to identify screen configuration -- which could be some issue in X).

Here's xorg.conf:

# Xorg configuration created by system-config-display

Section "ServerLayout"
	Identifier     "Multihead layout"
	Screen      0  "MainViewsonic" 0 0
	Screen      1  "LeftViewsonic" LeftOf "MainViewsonic"
	Screen      2  "RightViewsonic" RightOf "MainViewsonic"
	Screen      3  "PhillipsRight" RightOf "RightViewsonic"
	InputDevice    "Mouse0" "CorePointer"
	InputDevice    "Keyboard0" "CoreKeyboard"
	Option	    "Xinerama" "off"
	Option	    "Clone" "on"
EndSection

Section "Files"
# Multiple FontPath entries are allowed (they are concatenated together)
# By default, a font server independent of the X server is
# used to render fonts.

	FontPath     "unix/:7100"
EndSection

Section "Module"
	Load  "dbe"
	Load  "extmod"
	Load  "fbdevhw"
	Load  "glx"
	Load  "record"
	Load  "freetype"
	Load  "type1"
	Load  "dri"
EndSection

Section "InputDevice"
# Specify which keyboard LEDs can be user-controlled (eg, with xset(1))
#	Option	"Xleds"		"1 2 3"

# To disable the XKEYBOARD extension, uncomment XkbDisable.
#	Option	"XkbDisable"

# To customise the XKB settings to suit your keyboard, modify the
# lines below (which are the defaults).  For example, for a non-U.S.
# keyboard, you will probably want to use:
#	Option	"XkbModel"	"pc102"
# If you have a US Microsoft Natural keyboard, you can use:
#	Option	"XkbModel"	"microsoft"
#
# Then to change the language, change the Layout setting.
# For example, a german layout can be obtained with:
#	Option	"XkbLayout"	"de"
# or:
#	Option	"XkbLayout"	"de"
#	Option	"XkbVariant"	"nodeadkeys"
#
# If you'd like to switch the positions of your capslock and
# control keys, use:
#	Option	"XkbOptions"	"ctrl:swapcaps"
# Or if you just want both to be control, use:
#	Option	"XkbOptions"	"ctrl:nocaps"
#
	Identifier  "Keyboard0"
	Driver      "kbd"
	Option	    "XkbModel" "pc105"
	Option	    "XkbLayout" "us"
EndSection

Section "InputDevice"
	Identifier  "Mouse0"
	Driver      "mouse"
	Option	    "Protocol" "IMPS/2"
	Option	    "Device" "/dev/input/mice"
	Option	    "ZAxisMapping" "4 5"
	Option	    "Emulate3Buttons" "yes"
EndSection

Section "Monitor"
	Identifier   "MainViewsonic"
	VendorName   "Monitor Vendor"
	ModelName    "P225fb"
	DisplaySize  415	310
 ### Comment all HorizSync and VertSync values to use DDC:
	HorizSync    30.0 - 127.0
	VertRefresh  50.0 - 160.0
	Option	    "dpms"
EndSection

Section "Monitor"
	Identifier   "RightViewsonic"
	VendorName   "Monitor Vendor"
	ModelName    "G70mb"
	DisplaySize  320	240
 ### Comment all HorizSync and VertSync values to use DDC:
	HorizSync    30.0 - 70.0
	VertRefresh  50.0 - 120.0
	Option	    "dpms"
EndSection

Section "Monitor"
	Identifier   "LeftViewsonic"
	VendorName   "Monitor Vendor"
	ModelName    "ViewSonic G70fmb"
 ### Comment all HorizSync and VertSync values to use DDC:
	HorizSync    30.0 - 70.0
	VertRefresh  50.0 - 160.0
	Option	    "dpms"
EndSection

Section "Monitor"
        Identifier   "Philips"
        VendorName   "Monitor Vendor"
        ModelName    "Philips 107S(17inch/CM1300)"
        DisplaySize  320        240
 ### Comment all HorizSync and VertSync values to use DDC:
        HorizSync    30.0 - 69.0
        VertRefresh  50.0 - 120.0
        Option      "dpms"
EndSection


Section "Device"
	Identifier  "Videocard0a"
	Driver      "nvidia"
	VendorName  "Videocard vendor"
	BoardName   "nVidia Corporation NV17GL [Quadro4 200/400 NVS]"
	BusID       "PCI:3:0:0"
	Screen 0
EndSection

Section "Device"
	Identifier  "Videocard0b"
	Driver      "nvidia"
	VendorName  "Videocard vendor"
	BoardName   "nVidia Corporation NV17GL [Quadro4 200/400 NVS]"
	BusID       "PCI:3:0:0"
	Screen 1
EndSection

Section "Device"
	Identifier  "Videocard1a"
	Driver      "nvidia"
	VendorName  "Videocard Vendor"
	BoardName   "nVidia Corporation NV17GL [Quadro4 200/400 NVS]"
	BusID       "PCI:3:4:0"
	Screen 0
EndSection

Section "Device"
	Identifier  "Videocard1b"
	Driver      "nvidia"
	VendorName  "Videocard Vendor"
	BoardName   "nVidia Corporation NV17GL [Quadro4 200/400 NVS]"
	BusID       "PCI:3:4:0"
	Screen 1
EndSection

Section "Screen"
	Identifier "MainViewsonic"
	Device     "Videocard0a"
	Monitor    "MainViewsonic"
	DefaultDepth     16
	Option	"UseEdidFreqs" "True"
	SubSection "Display"
		Depth     16
		Modes    "1280x1024" "1024x768" "800x600"
	EndSubSection
EndSection

Section "Screen"
	Identifier "LeftViewsonic"
	Device     "Videocard0b"
	Monitor    "LeftViewsonic"
	DefaultDepth     16
	Option	"UseEdidFreqs" "True"
	SubSection "Display"
		Depth     16
		Modes    "1280x1024" "1024x768" "800x600"
	EndSubSection
EndSection

Section "Screen"
	Identifier "RightViewsonic"
	Device     "Videocard1a"
	Monitor    "RightViewsonic"
	DefaultDepth     16
	Option	"UseEdidFreqs" "True"
	SubSection "Display"
		Depth     16
		Modes    "1280x1024" "1024x768" "800x600"
	EndSubSection
EndSection

Section "Screen"
	Identifier "PhillipsRight"
	Device     "Videocard1b"
	Monitor    "Philips"
	DefaultDepth     16
	Option	"UseEdidFreqs" "True"
	SubSection "Display"
		Viewport   0 0
		Depth     16
		Modes    "1280x1024" "1024x768" "800x600"
	EndSubSection
EndSection

Section "DRI"
	Group        0
	Mode         0666
EndSection

Hi,

There is no code in Konsole itself which relates to screen/display/monitor handling.  The only thing I can think of which Konsole (1.6.6) does that other KDE applications do not is that it attempts to reposition the mouse cursor if it moves out of the terminal display's bounds.

kdebase/konsole/konsole/TEWidget.cpp , line 1411:
    if ( pos != oldpos ) cursor().setPos(mapToGlobal(pos));

You could try removing that line and building from source to see if it makes any difference.

Unfortunately I do not have an NVidia setup to test with.  My multi-monitor setup is a simple two-screen Xinerama affair (with a laptop and external screen) under which I could not reproduce the problem.

Howdy Mr. Knight!

If you would like to reproduce it, just swap the order of the monitors 
in xorg.conf.

That is, tell it that Screen 0 is right of Screen 1.

That should be sufficient to get the problem to appear.

The problem with the code would be that it not only needs to set the 
position of the mouse, but the display on which the mouse appears.

Without even making any changes to your configuration, move a copy of 
Konsole to the edge nearest your other display.

If while selecting, you drag the mouse quickly against that edge of the 
display, the mouse cursor will jump to the other display (even though 
on the visually correct side).

The point there is that the user has escaped from the global map by 
jumping to the next display.

So, also setting the display on which the mouse appears "if ( pos != 
oldpos )" will make the problem go away.

Thank you.

On Thu 29 November 2007 3:28 pm, Robert Knight wrote:
[bugs.kde.org quoted mail]

> If you would like to reproduce it, just swap the order of the monitors
> in xorg.conf. 

I couldn't reproduce the problem.  I'm wondering whether it might be something to do with your window management options.

> So, also setting the display on which the mouse appears "if ( pos !=
> oldpos )" will make the problem go away. 

There is no concept of multiple displays.  From Konsole's point of view, there is only one (possibly very large) screen.  In actuality, different sections of that screen may be displayed by different monitors, but KDE applications are not aware of this.   

Howdy Mr. Knight!

I suppose that the difference is that maybe you are using Xinerama, and 
I'm not using Xinerama.  Instead, I'm displaying a separate workspace 
on each display.

So, Konsole is dragging the mouse back to the original coordinates, but 
on a different display.  And that is because the mouse motion increment 
was greater than the width of the Konsole border.

So to solve this, you either need to catch the mouse before it actually 
moves off the display (that is, you know the delta and the mouse cursor 
hasn't yet been updated with the delta), or become aware of the display 
that contains the mouse (if you are going to twiddle with the mouse 
position).

A simpler option would be to allow the user to specify that the mouse 
cursor will not be jailed.  Then the effect won't happen.

Thank you.

On Tue 18 December 2007 7:19 pm, Robert Knight wrote:
[bugs.kde.org quoted mail]

> A simpler option would be to allow the user to specify that the mouse
> cursor will not be jailed.  Then the effect won't happen. 

In which case this is fixed in KDE 4.