After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 783331 - multi-head xinerama screens do not align askew
multi-head xinerama screens do not align askew
Status: RESOLVED OBSOLETE
Product: gnome-shell
Classification: Core
Component: general
3.24.x
Other Linux
: Normal minor
: ---
Assigned To: gnome-shell-maint
gnome-shell-maint
Depends on:
Blocks:
 
 
Reported: 2017-06-01 21:28 UTC by Gary Murphy
Modified: 2021-07-05 14:40 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Gary Murphy 2017-06-01 21:28:01 UTC
Using Ubuntu 17.04 and gnome-shell 3.24.1-0ubuntu on an HP laptop with an ASUS screen, I have the screen to the right of the laptop on the desk and set back so that *visually* the ASUS screen appears to the right and about 50% up from the laptop screen.

On the Unity desktop, when the Display configuration is set to the ASUS rectangle is moved up from the baseline of the laptop screen rectangle, there is a seamless path for the mouse to travel from one screen to the next, up at an angle, the cursor exits at 75% on one screen and enters the next at 25% of the height, a very natural movement.

This does not work with Gnome-Shell: no matter how the rectangles in the Display system setup are aligned, if the cursor exits one screen at 25% of the height, it will enter the other screen also at 25% of the height, which is no big deal, but it is annoying and all the more so because it works as expected in the (deprecated) Unity desktop.

Further to this, if the rectangles in the Display setup are set with the
base of the right box slid 50% up the side of the left, the cursor will not
move right beyond the lower 50% of the laptop screen or move left of the
upper (non-overlapping) portion of the ASUS screen -- the cursor stops dead at the boundaries (as could be expected) however, in the overlap boundary region, the mouse will enter the neighbouring screen, but jump to the same proportional height as it was on the prior screen, ie it is moving as if the screens were set horizontally flush aligned instead of continuing the smooth path across space.

What I really expect to happen, when the Display rectangles are arranged where both are 800x600 and the right screen set 50% up, then the total virtual deskspace would be (800+800)x(600+300) ie 1600x900, with bounds from the top-left of Screen 1 from (0,600) to top-left of Screen 2 at (800,900), and from bottom-right from Screen 1 (800,0) to bottom-right Screen 2 (1600,300) allowing the smooth trajectory of screens, cursors etc across the space between the screens.
Comment 1 Florian Müllner 2017-06-01 21:36:19 UTC
Are you using the wayland session? You are saying Xinerama which would imply X, but then it wouldn't be mutter/gnome-shell drawing the cursor ...
Comment 2 Gary Murphy 2017-06-01 21:47:44 UTC
Sorry, I am not at all sure what a wayland session is or how I'd choose or not choose one -- I am using the default Ubuntu 17.04 gnome-shell so if there is a test I can do to verify, let me know and I will append that.

Also, if this were an X issue, I would expect identical behaviour in Gnome Shell as in the Unity shell, but the behaviours are different, which possibly implies it has something to do with the way Gnome Shell interacts with the Xinerama feature of X?


[ btw, and maybe this is a feature, but I notice the email given as Reply-To on these bugzilla comments (bugzilla@gnome.org) are rejected as address not found ]
Comment 3 Florian Müllner 2017-06-01 22:14:53 UTC
(In reply to Gary Murphy from comment #2)
> Sorry, I am not at all sure what a wayland session is [...] so if
> there is a test I can do to verify, let me know and I will append that.

Can you run

 $ GDK_BACKEND=wayland nautilus

(when nautilus wasn't running before)?


> Also, if this were an X issue, I would expect identical behaviour in Gnome
> Shell as in the Unity shell

That's why I'm asking.
Comment 4 GNOME Infrastructure Team 2021-07-05 14:40:06 UTC
GNOME is going to shut down bugzilla.gnome.org in favor of  gitlab.gnome.org.
As part of that, we are mass-closing older open tickets in bugzilla.gnome.org
which have not seen updates for a longer time (resources are unfortunately
quite limited so not every ticket can get handled).

If you can still reproduce the situation described in this ticket in a recent
and supported software version, then please follow
  https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines
and create a new ticket at
  https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/

Thank you for your understanding and your help.