linux client mouse position is wrong if your display isn't at +0+0

[totaam]

Issue migrated from trac ticket # 2726

component: client | priority: major | keywords: linux client mouse position GTK

2020-04-12 16:27:13: sashab created the issue

---

Aparently there seems to be a bug in handling/mapping mouse coordinates.

There was an old bug on MICROS~1 #980 similar to this one.

MWE:

1. Have a display setup, where there is no display on +0+0, e.g.
   XWAYLAND0 connected 1366x768+1920+0
2. xpra attach to a random xpra server session
3. Try to click something in a window
   Expected result:

• You can click something
  Result:
• You can't
• Focusing a window with your mouse works though

Workaround:

• Change your display setup to start at +0+0, e.g.
  XWAYLAND0 connected 1366x768+0+0

Tested client on debian bullseye/sid:

• v3.0.8-25889
• 26081 v4.0-20200410r26081-1
• r26095 v3.0.9-20200412r26095-1

Tested server:

• all above mentioned versions on debian bullseye/sid
• v3.0.8-25889 on debian buster
• v3.0.6-25195 on CentOS 7 (7.7)
• v3.0.8-25889 on CentOS 7 (7.7)

[totaam]

2020-04-12 16:27:54: sashab uploaded file gtk_info.txt (3.6 KiB)

gtk_info.py

[totaam]

2020-04-12 16:29:28: sashab uploaded file :4.log (65.8 KiB)

xpra log with -d mouse

[totaam]

Have a display setup, where there is no display on +0+0, e.g. XWAYLAND0 connected 1366x768+1920+0

How do I do that?

[totaam]

2020-04-12 17:35:17: sashab commented

---

Replying to [comment:3 Antoine Martin]:

Have a display setup, where there is no display on +0+0, e.g. XWAYLAND0 connected 1366x768+1920+0
How do I do that?

Hmm, good question.

In my case (sway wm on wayland) it's one line in ~/.config/sway/config:

output LVDS-1 pos 1920 0 res 1366x768

I've tried to simulate it on Xorg, but xrandr doesn't let me change screen size without changing output mode. :(

[phi-mah]

I'm hit by the same bug, but without rearranging my monitor setup I rely on the geometric offset:

My client side looks as follows:

• OS: Arch Linux
• Window manager: sway (tiling WM, originally runs on wayland). This seems to complicate things.
• Xpra runs within Xwayland
• Dual monitor setup:

~ ❯❯❯ xrandr
Screen 0: minimum 16 x 16, current 6400 x 2160, maximum 32767 x 32767
XWAYLAND0 connected 2560x1440+0+0 (normal left inverted right x axis y axis) 310mm x 170mm
   2560x1440     59.96*+
[...]
XWAYLAND1 connected 3840x2160+2560+0 (normal left inverted right x axis y axis) 600mm x 340mm
   3840x2160     29.98*+
[...]

which looks like this:

|-----------| |-------------------|
| XWAYLAND0 | |                   |
|-----------| |     XWAYLAND1     |
              |                   |
              |-------------------|
              

• Xpra version: v4.2.3-r3

The XWAYLAND1 display serves as my main screen, the laptop monitor (XWAYLAND0) is only a sidekick.

This causes problems on the main screen.

• A windows stays responsive as long as it left edge has a global xcoordinate < 3840, i.e. local xcoordinate < 3840 - 2560 = 1280. If it reacts, it catches also mouse movements with global xcorrdinates >= 3840
• Even with a responsive window, context menus (right click) are only rendered up to the xcorrdinate == 3840 frontier. For slightly larger numbers, it gets shifted to the left. Event larger coordinates trigger an "automatic selection", i.e. some action available in the context menu is triggered (unintendedly).
• En unresponsive window does not react to mouse clicks

I.e. i can only interact with xpra backed windows that are drawn on the first third of the main screen.

I'm happy to assist with further logs etc

[totaam]

Xpra version: v4.2.3-r3

This is well out of date.

@phi-mah my guess is that using a patched dummy driver would help, or perhaps switching to Xvfb. (assuming that you are using Xdummy - no idea what Arch does)

[phi-mah]

Ok, for the client side I would assume that Arch linux is always bleeding edge, but indeed the package is also flagged as "out of date". Could try to check with a self-compiled version.

But I assume that your comment refers to the server side? This is unfortuntlelly really old (Debian 9, xpra v3.0.13-r28351) and harder to change. Xpra spawns here the following process:

Xvfb-for-Xpra-:100 +extension GLX +extension Composite -screen 0 5760x2560x24+32 -dpi 96 -nolisten tcp -noreset -auth /network/home/mahlberg/.Xauthority :100
Noticed that it is already Xvfb, but the screen size given here (5760x2560) fails to meet the dimension on the client (6400 x 2160). Played around with XPRA_DEFAULT_VFB_RESOLUTION, but without the desired effect:

export XPRA_DEFAULT_VFB_RESOLUTION="6400x2160"; /usr/bin/xpra --no-daemon --start xrandr start :100

xrandr: Failed to get size of gamma for output screen
Screen 0: minimum 1 x 1, current 5760 x 2560, maximum 5760 x 2560
screen connected 5760x2560+0+0 0mm x 0mm

When connecting, the server logs:

022-01-17 15:08:16,203 Warning: failed to add resolution 6400x2160:
2022-01-17 15:08:16,203  XError: BadMatch (invalid parameter attributes)
2022-01-17 15:08:16,208 Error: size not found for 6400x2160
2022-01-17 15:08:16,208  1 sizes are supported
2022-01-17 15:08:16,208  5760x2560
2022-01-17 15:08:16,209 Warning: tried to set resolution to 6400x2160
2022-01-17 15:08:16,209  and ended up with 5760x2560

and indeed 5760 is now the magic number. This makes ~3/4 of my main screen, so for the moment I can work around that, but why is the environment variable not honored?

[totaam]

but why is the environment variable not honored?

It can't be, your Xvfb is so old that it doesn't support randr and the resolution can't be changed. So I am closing this ticket as invalid because there's nothing xpra can do here.

Perhaps using Xdummy would work better - assuming that you can use a patched dummy driver. I can't remember if the repos have one.

In newer versions of xpra you can just do --resize-display=4k or --resize-display=6400x1260.

[totaam]

Wait, re-opening: your problem may be different from the original issue.

[totaam]

This ticket looks out of date.