That is how X works and is something that you would have to live with when using monitors with different resolutions together. You will get that problem in every single desktop environment.

I think it would be possible to write a little program or X extension that prevents the mouse cursor from entering the dead zones but I haven't heard of anyone doing it yet.

troycarpenter wrote:I would speculate that X (and consequently KDE) thinks there is one big 2960x1050 desktop.

Yes, you're right. I can confirm that my desktop resolution is 2960x1050.

Zarin wrote:That is how X works and is something that you would have to live with when using monitors with different resolutions together. You will get that problem in every single desktop environment.

Ok. Good to know that it's not KDE's fault but it's a bit of an annoyance, though. I hope someone fixes that behaviour from X now that multi-monitor setups are more common.

Thanks all for your help!

Update: I've found a configuration option that may help a bit. It seems that you can have both displays at the same resolution by activating panning on the smaller one. I'm using that setup right now and I like it better than having a dead zone. In case someone is interested, the relevant "metamode" option in xorg.conf is:

Code: Select all

Option         "metamodes" "CRT: 1280x1024 @1280x1050 +1680+0, DFP: 1680x1050 +0+0"


More information here.

Finally! Sorry to resurrect this thread but I just read today on Planet KDE about a proper (well, I think the proper solution would involve hacking Xorg...) solution to this problem: NoEnter by Aike J Sommer.

Also, in the comments, somebody mentioned an alternative: Deadspace.

I haven't tried them yet but I hope this information could be helpful (and that NoEnter would be part of KDE someday).

Just tried NoEnter--it's nice but works exactly like how I envisioned: Bouncy cursor movement.

The problem with X is that the cursor is a part of the server while applications such as NoEnter are done on the client-side. As you're moving the cursor directly on the server there will be a small delay before the client picks up the mouse movement to be able to warp it back into a visible section of the screen. There is also the possibility that the user can click/release a mouse button in the off-screen area and have it picked up by another application before NoEnter can correct the mouse location.

The only way to have the cursor blocked nicely is to actually do the processing on the server itself--I.e. have it as a part of X.

Zarin wrote:The only way to have the cursor blocked nicely is to actually do the processing on the server itself--I.e. have it as a part of X.

Oh, sorry to hear that. I guess we won't have a proper solution for a while then, as X is outside KDE scope, isn't it?

It would be nice if enough users would join in making distros aware of this problem. If we get a critical mass perhaps someone nearer to X development would initiate an effort to correct this.