Pointer barriers have gaps along the edge of the screen

Bug #1073724 reported by Tim Lunn
20
This bug affects 2 people
Affects Status Importance Assigned to Milestone
X.Org X server
In Progress
Medium
xorg-server (Ubuntu)
Fix Released
Low
Unassigned

Bug Description

[Impact]
On a multiple monitor setup there is a small gap above the pointer barriers, that allows the mouse to slide through past the barrier, via the edge of the screen.

This a particular issue on gnome-shell, since the pointer barriers are used to trap the pointer inside the panel/tray when activating hot-corners. Currently it is extremely hard to land on these hot-corners due to this bug.

[TESTCASE]
1. run gnome-shell with atleast 2 montiors in horizontal configuration, 2nd monitor to the right of the primary
2. move mouse towards top-right corner of primary monitor.

Pointer should get trapped in the corner of the primary monitor, however it will actually just side over the top of the barrier.

With fix in the attached branch, the pointer is correctly trapped.

[Regression Pontential]
Should be minimal, I have tested under gnome-shell and unity and all hot-corners/sticky edges appear to be working correctly.

=== Original Bug Report ==
I have a multiple monitor setup and the pointer barriers seem to have a small (~1px) gap at the edge of the screen. For example in gnome-shell, the panel has barriers on either end, If I move the mouse towards the hot corner (top-right corner of screen) it inevitably just slips over the top of the barrier and onto the next monitor.

This bug introduced by the '500_pointer_barrier_thresholds.diff' patch. I have rebuilt the xserver without this patch, and the barriers behave as expected blocking/trapping the mouser pointer in the top corner of the screen.

ProblemType: BugDistroRelease: Ubuntu 12.10
Package: xserver-xorg-core 2:1.13.0-0ubuntu6
ProcVersionSignature: Ubuntu 3.5.0-18.29-generic 3.5.7
Uname: Linux 3.5.0-18-generic x86_64
NonfreeKernelModules: nvidia
.proc.driver.nvidia.gpus.0: Error: [Errno 21] Is a directory: '/proc/driver/nvidia/gpus/0'
.proc.driver.nvidia.registry: Binary: ""
.proc.driver.nvidia.version:
 NVRM version: NVIDIA UNIX x86_64 Kernel Module 310.14 Tue Oct 9 11:52:41 PDT 2012
 GCC version: gcc version 4.7.2 (Ubuntu/Linaro 4.7.2-2ubuntu1)
.tmp.unity.support.test.0:

ApportVersion: 2.6.1-0ubuntu6
Architecture: amd64
CompizPlugins: [core,composite,opengl,compiztoolbox,decor,vpswitch,snap,mousepoll,resize,place,move,wall,grid,regex,imgpng,session,gnomecompat,animation,fade,unitymtgrabhandles,workarounds,scale,expo,ezoom,unityshell,dbus]
CompositorRunning: None
Date: Thu Nov 1 08:04:55 2012
DistUpgraded: Fresh install
DistroCodename: quantal
DistroVariant: ubuntu
ExtraDebuggingInterest: Yes
GraphicsCard:
 NVIDIA Corporation G94 [GeForce 9600 GT] [10de:0622] (rev a1) (prog-if 00 [VGA controller])
   Subsystem: ASUSTeK Computer Inc. Device [1043:827c]
InstallationDate: Installed on 2012-09-23 (38 days ago)
InstallationMedia: Ubuntu GNOME Remix 12.10 "Quantal Quetzal" - Alpha amd64(20120922)
MachineType: Gigabyte Technology Co., Ltd. P67A-UD3R-B3
MarkForUpload: True
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.5.0-18-generic root=UUID=dc987631-dd10-4695-8806-338e780920e2 ro quiet splashSourcePackage: xorg-server
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 07/22/2011
dmi.bios.vendor: Award Software International, Inc.
dmi.bios.version: F5
dmi.board.name: P67A-UD3R-B3
dmi.board.vendor: Gigabyte Technology Co., Ltd.
dmi.board.version: x.x
dmi.chassis.type: 3
dmi.chassis.vendor: Gigabyte Technology Co., Ltd.
dmi.modalias: dmi:bvnAwardSoftwareInternational,Inc.:bvrF5:bd07/22/2011:svnGigabyteTechnologyCo.,Ltd.:pnP67A-UD3R-B3:pvr:rvnGigabyteTechnologyCo.,Ltd.:rnP67A-UD3R-B3:rvrx.x:cvnGigabyteTechnologyCo.,Ltd.:ct3:cvr:
dmi.product.name: P67A-UD3R-B3
dmi.sys.vendor: Gigabyte Technology Co., Ltd.
version.compiz: compiz 1:0.9.8.4+bzr3407-0ubuntu1
version.ia32-libs: ia32-libs 20090808ubuntu36
version.libdrm2: libdrm2 2.4.39-0ubuntu1
version.libgl1-mesa-dri: libgl1-mesa-dri 9.0-0ubuntu1
version.libgl1-mesa-dri-experimental: libgl1-mesa-dri-experimental N/A
version.libgl1-mesa-glx: libgl1-mesa-glx 9.0-0ubuntu1
version.nvidia-graphics-drivers: nvidia-graphics-drivers N/A
version.xserver-xorg-core: xserver-xorg-core 2:1.13.0-0ubuntu6
version.xserver-xorg-input-evdev: xserver-xorg-input-evdev 1:2.7.3-0ubuntu2
version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:6.99.99~git20120913.8637f772-0ubuntu1
version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.20.9-0ubuntu2
version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.2-0ubuntu3

Revision history for this message
In , Otaylor-redhat (otaylor-redhat) wrote :

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.)

Revision history for this message
In , Peter Hutterer (peter-hutterer) wrote :

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.

Revision history for this message
Tim Lunn (darkxst) wrote :
Revision history for this message
Tim Lunn (darkxst) wrote :

Passing in the unclamped x,y values to barrier_find_nearest(), fails to find nearest blocking barrier in some cases. Since we are measuring distance and not velocity I think its fine to use the clamped values in *x,*y, as per my patch in the linked branch. This fixes the issues in gnome-shell and does not appear to have any adverse affects in Unity.

Tim Lunn (darkxst)
description: updated
description: updated
Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in xorg-server (Ubuntu):
status: New → Confirmed
Revision history for this message
Tim Lunn (darkxst) wrote :
Revision history for this message
Ubuntu Foundations Team Bug Bot (crichton) wrote :

The attachment "pointer barrier patch" of this bug report has been identified as being a patch. The ubuntu-reviewers team has been subscribed to the bug report so that they can review the patch. In the event that this is in fact not a patch you can resolve this situation by removing the tag 'patch' from the bug report and editing the attachment so that it is not flagged as a patch. Additionally, if you are member of the ubuntu-reviewers team please also unsubscribe the team from this bug report.

[This is an automated message performed by a Launchpad user owned by Brian Murray. Please contact him regarding any issues with the action taken in this bug report.]

tags: added: patch
Revision history for this message
Tim Lunn (darkxst) wrote :

here are excerpts from my IRC conversation with Jasper re this bug.
----
<Jasper> darkxst, it's entirely possible that it will break it on monitor edges
<darkxst> the barrier_find_nearest() function definately breaks on the monitor edges when using the unclamped values
<Jasper> darkxst, I'm quite sure it will break BarrierNotify behavior, to be honest

<Jasper> I know exactly what the issue is: since we're using the unclamped positions, they're not clamped to the screen edges
<darkxst> if I hit the top edge I the screen it almost always slides past

<Jasper> darkxst, we have three pieces of information: where the mouse came from, where the mouse is going to unclamped to the screen edges, where the mouse is going to clamped to the screen edges
<Jasper> darkxst, between those three it should be possible to figure something out, but I can't figure anything out
<Jasper> darkxst, the issue that RAOF was talking about was what happens when clamped and where the mouse is coming from end up to be the same thing -- that is, when we're bumping against a barrier on the screen edge
<Jasper> so we switched to unclamped to allow for screen edges there
<Jasper> now what's happening is that the unclamped mouse position is outside the bounds of the monitor, which the barrier doesn't reach to, so it doesn't consider it blocked
<Jasper> darkxst, feel free to copy/paste this conversation onto the LP bug -- whatever solution RAOF comes up with is really interesting to me, because I'm turning his patches into a core X feature for 3.8.

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package xorg-server - 2:1.13.0-0ubuntu7

---------------
xorg-server (2:1.13.0-0ubuntu7) raring; urgency=low

  [ Maarten Lankhorst ]
  * Add 233-xf86events-valgrind.patch to fix a xserver corruption
    when acpid is stopped before Xorg is.
    (LP: #1070481)
  * Add 235-composite-tracking.patch to fix exa corruption.
    (LP: #1010794)

  [ Bryce Harrington ]
  * Add 236-use-fbdev-for-poulsbo-oaktrail-medfield.patch: Never use Intel
    driver on Poulsbo/Oaktrail/Medfield. Thanks to Matthias Klumpp.
    (LP: #1069031)
  * Add 237-dix-set-the-device-transformation-matrix.patch: Fix pointer
    jumping with absolute pointing device. Initializes device
    transformation matrix to an identity matrix. Thanks to a7x.
    (LP: #1041063)

  [ Tim Lunn ]
  * 500_pointer_barrier_thresholds.diff: Update to fix gaps above
    barriers at edge of screen
    (LP: #1073724)
 -- Bryce Harrington <email address hidden> Fri, 16 Nov 2012 11:37:26 -0800

Changed in xorg-server (Ubuntu):
status: Confirmed → Fix Released
Revision history for this message
Jasper St. Pierre (jstpierre) wrote :

Um, as mentioned, Tim's patch actually breaks things as well. And the bug isn't entirely fixed either, just made less noticeable.

This is a dup of https://bugs.freedesktop.org/show_bug.cgi?id=48008

Revision history for this message
Timo Aaltonen (tjaalton) wrote :

reopening, and dropping the patch.

Changed in xorg-server (Ubuntu):
status: Fix Released → In Progress
Changed in xorg-server:
importance: Unknown → Medium
status: Unknown → In Progress
Revision history for this message
penalvch (penalvch) wrote :

Tim, this bug was reported a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue? If so, could you please test for this with the latest development release of Ubuntu? ISO images are available from http://cdimage.ubuntu.com/daily-live/current/ .

If it remains an issue, could you please run the following command in the development release from a Terminal (Applications->Accessories->Terminal), as it will automatically gather and attach updated debug information to this report:

apport-collect -p xorg-server REPLACE-WITH-BUG-NUMBER

Please note, given that the information from the prior release is already available, doing this on a release prior to the development one would not be helpful.

Thank you for your understanding.

Helpful bug reporting tips:
https://wiki.ubuntu.com/ReportingBugs

Changed in xorg-server (Ubuntu):
importance: Undecided → Low
status: In Progress → Incomplete
Revision history for this message
Tim Lunn (darkxst) wrote :

This was fixed upstream in xorg-server 1.14

Revision history for this message
penalvch (penalvch) wrote :

Tim, thank you for your comment. Would you need a backport to a release prior to Saucy?

Revision history for this message
Tim Lunn (darkxst) wrote :

Its not something that is likely backportable other than through a HWE stack update

Revision history for this message
Paul White (paulw2u) wrote :

Bug report did not expire due to bug watch
Re comments #13 and #14 will assume fixed in the saucy release (Ubuntu 13.10)

Changed in xorg-server (Ubuntu):
status: Incomplete → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.