Bug 99663 - Cannot move mouse pointer over the top 1080px along the Y axis when display is rotated vertically (patched xwayland_output.c)
Summary: Cannot move mouse pointer over the top 1080px along the Y axis when display i...
Status: RESOLVED FIXED
Alias: None
Product: Wayland
Classification: Unclassified
Component: XWayland (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Wayland bug list
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-02-03 10:33 UTC by zashkirka
Modified: 2017-02-08 19:40 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:

Attachments
xwayland-output from the sources of installed package (10.15 KB, text/x-csrc)
2017-02-03 10:33 UTC, zashkirka 		Details
Му weston config (273 bytes, application/x-wine-extension-ini)
2017-02-03 10:34 UTC, zashkirka 		Details
weston log (7.98 KB, text/x-log)
2017-02-03 10:35 UTC, zashkirka 		Details
weston-info output (2.94 KB, text/x-log)
2017-02-06 07:10 UTC, zashkirka 		Details
View All

Description zashkirka 2017-02-03 10:33:47 UTC 
Created attachment 129318 [details]
xwayland-output from the sources of installed package

Same problem, as was described in Bug #92076

>When I open any X11 app (in Weston):
1. I can move successfully mouse pointer along the axis X (all of the 1080 pixels).
2. I can move successfully mouse pointer along the axis Y within only the top 1080 pixels (relative to the screen, not the window).
3. If I move mouse pointer below the top 1080px, the app (!) still thinks that Y=1080, though I (!) see that mouse pointer's Y is actually > 1080.
4. If I move the window to the bottom of the screen, then I can't click/scroll anything (Y relative to screen is > 1080) in it. I can't even move the window by clicking its title bar using the left mouse button. Though I can move the window by using Weston's Super+LMB.

But my version of xwayland is already patched.

Display: DELL S2240T, 1920x1080@60.
Distro: Ubuntu 16.04
Linux 4.4.0-62-generic x86_64
Weston  1.9.0-3
xorg-server-xwayland 1.18.4
firefox 51.0.1+build2-0ubuntu0.16.04.1
chromium-browser 57.0.2950.4-0ubuntu1~ppa14~16.04.1

Same problem was in other distros (fedora 25, debian 8).
Comment 1 zashkirka 2017-02-03 10:34:45 UTC 
Created attachment 129319 [details]
Му weston config
Comment 2 zashkirka 2017-02-03 10:35:06 UTC 
Created attachment 129320 [details]
weston log
Comment 3 Olivier Fourdan 2017-02-03 12:54:41 UTC 
Works fine here on F25 with a rotated screen (1200x1920) with GNOME on Wayland.

Can you post the output from "weston-info" and "xrandr -q" on your setup?
Comment 4 zashkirka 2017-02-06 07:08:49 UTC 
xrand -q gave me an error. Then i've tried to set rotation "normal" two times, and it started to work correct.

zashk@w056:~$ xrandr -q
xrandr: output XWAYLAND0 cannot use rotation "left" reflection "none" 
zashk@w056:~$ xrandr --output XWAYLAND0 --rotate normal
xrandr: Configure crtc 0 failed X Error of failed 
request: BadMatch (invalid parameter attributes)
  Major opcode of failed request: 140 (RANDR)
  Minor opcode of failed request: 21 (RRSetCrtcConfig)
  Serial number of failed request: 25
  Current serial number in output stream: 25
zashk@w056:~$ xrandr --output XWAYLAND0 --rotate normal 
zashk@w056:~$ xrandr -q
Screen 0: minimum 320 x 200, current 1080 x 1920, maximum 8192 x 8192 
XWAYLAND0 connected
   1080x1920 59.96 +
Comment 5 zashkirka 2017-02-06 07:10:48 UTC 
Created attachment 129353 [details]
weston-info output
Comment 6 zashkirka 2017-02-06 07:20:09 UTC 
X11 apps after setting rotation "normal" works correct too.
Comment 7 Jonas Ådahl 2017-02-06 07:26:28 UTC 
Note that currently under mutter, Xwayland will have no idea about any rotation, as we pretend all wl_output's have no transform on them. The reason for doing so is that we don't handle buffer transformations yet, and if we pretend that outputs are never transformed, clients are less likely to pass buffers we can't handle.
Comment 8 Olivier Fourdan 2017-02-06 11:05:19 UTC 
I see what you mean, seems mutter and weston do things differently.
Comment 9 Olivier Fourdan 2017-02-06 11:07:18 UTC 
Patch sent here: https://patchwork.freedesktop.org/series/19156/

You may try that to see if that works for you (works here, with weston rotated screen).
Comment 10 zashkirka 2017-02-06 14:37:41 UTC 
Patch works for me. Xrandr has valid setup on weston startup.
Thank you!
Comment 11 Olivier Fourdan 2017-02-07 13:14:06 UTC 
Unfortunately, the patch isn't right so I am still working on this.

I think there are two issues, one being the rotation set on the crtc is not supported by the crtc by default, this is easy to fix and I have a patch for that, the other more annoying issue is with the input coordinates being filtered out when there is a rotation in place, which is... odd.  That explains why it works with mutter (see Jonas comment 7).
Comment 12 Olivier Fourdan 2017-02-07 14:03:38 UTC 
Ah! it's because of RRConstrainCursorHarder() apparently
Comment 13 Olivier Fourdan 2017-02-07 14:35:17 UTC 
So I've split the patch in two:

https://patchwork.freedesktop.org/patch/137446/
https://patchwork.freedesktop.org/patch/137447/

Can you try these two patch instead? They seem to work for me, the "xrandr -q" works and actually gives the right rotation/reflection in weston, and the pointer events are reported correctly as well.
Comment 14 Olivier Fourdan 2017-02-08 08:32:04 UTC 
(In reply to Olivier Fourdan from comment #13)
> So I've split the patch in two:
> 
> https://patchwork.freedesktop.org/patch/137446/
> https://patchwork.freedesktop.org/patch/137447/
> 
> Can you try these two patch instead? They seem to work for me, the "xrandr
> -q" works and actually gives the right rotation/reflection in weston, and
> the pointer events are reported correctly as well.

Actually those are better:

https://patchwork.freedesktop.org/patch/137446/
https://patchwork.freedesktop.org/patch/137635/
Comment 15 Olivier Fourdan 2017-02-08 19:40:47 UTC 
Patches have landed (thanks ajax!), closing.

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.