Bug 48008 - Pointer barrier leak with multiple monitors
Summary: Pointer barrier leak with multiple monitors
Status: RESOLVED WONTFIX
Alias: None
Product: xorg
Classification: Unclassified
Component: Server/General (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Peter Hutterer
QA Contact: Xorg Project Team
URL:
Whiteboard: 2012BRB_Reviewed
Keywords:
Depends on:
Blocks:
 
Reported: 2012-03-28 11:43 UTC by Owen Taylor
Modified: 2016-11-28 04:40 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments

Description Owen Taylor 2012-03-28 11:43:03 UTC
Given two monitors of unequal size

 +----------------+---------------------+
 |                |                     |
 |                |                     |
 |                |                     |
 |                X                     |
 +----------------X                     |
                  |                     |
                  |                     |
                  +---------------------+

And a pointer barrier at the location labelled X, its possible to mouse underneath the barrier from left to right and onto the second monitor.

Reproduced with xorg-x11-server-Xorg-1.12.0-2.fc17.x86_64

(Using GNOME 3 you can reproduce by setting up two monitors like this with the primary monitor on the left - a pointer barrier will be set up at position X to make the hot corner at the bottom left. Try mousing along the bottom row of pixels on the left monitor. This leak is not observed if the two monitors are the same size, indicating that the pointer barrier is correctly positioned.)
Comment 1 Peter Hutterer 2012-06-12 19:13:57 UTC
Reproduced, but the conditions are narrow. The barrier must align with the edge of a monitor and the movement _vector_ must not overlap with the barrier.
e.g. if you're in that corner, moving by 1/1 will block, moving by 1/2 won't block.

Cause is that the fixes code that calculates whether a barrier is blocking doesn't know about screen edges. So the picture the fixes code sees for a movement a to b is

                a X
                 \X
                  \
                   b
Which is permitted since the movement goes just past the barrier. The RandR
code to clamp to monitors sees this picture:

 +----------------+---------------------+
 |                |                     |
 |                |                     |
 |                |                     |
 |              a |                     |
 +---------------\+                     |
                  \                     |
                  |b                    |
                  +---------------------+

Which too is allowed since the destination exists in RandR space. The two
operations are quite separated in the server, merging them is tricky.

As a workaround for now, I suggest either extending the barrier to the bottom of the second monitor like this:

 +----------------+---------------------+
 |                |                     |
 |                |                     |
 |                |                     |
 |                X                     |
 +----------------X                     |
                  X                     |
                  X                     |
                  X---------------------+

or, alternatively, to create a horizontal barrier in that corner that shares
the same endpoint with the vertical one.
Comment 2 Peter Hutterer 2016-11-28 04:40:04 UTC
This is a mass change of bugs. Bugs assigned to me that haven't been updated in the last 3 years are closed as WONTFIX, because, well, let's at least be honest about it.

Please do not re-open unless you have a really good reason to do so (e.g. you're fixing it yourself). If it hasn't been fixed in the last 3 years, it probably won't be fixed anytime soon either. Sorry.


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.