Mouse pointer is bounded to a fixed area at top left of window

[taranu]

Describe the bug The mouse position seems to be cropped to a fixed area at the top left of a window. Mouseovers and clicks beyond this region are registered at the limits instead.

To Reproduce Steps to reproduce the behavior:

1. xpra -d grab start
2. xpra -d grab --clipboard-direction=both attach --encoding=webp (the encoding doesn't matter, but webp happens to work well)
3. Attempt to mouse over or click on any part of the window below or to the right of some threshold. See the image below, where I am attempting to click on the hamburger menu at the right, but both the mouseover and any clicks are registered on the extensions (puzzle icon) button to the left instead.

System Information (please complete the following information):

• Server OS: RHEL 8.6
• Client OS: Fedora 40 Workstation
• Xpra Server Version: 6.1.2, master (I've tried other versions with the same result)
• Xpra Client Version: 5.0.6 (distrib provided), 6.1.2 (compiled) - same result with both

Additional context I'm not sure if this is related to https://github.com/Xpra-org/xpra/issues/4354. I tried running with -d grab as suggested there but did not see anything obviously related in either client or server logs.

This problem only occurs on one of two nearly identical servers I've tried, both with the same OS version (one EPYC 7702 and the other 7702P), so I'm baffled.

[totaam]

RHEL 8.6

That's quite old. Which repository path are you using? We don't have builds for almalinux 8.6 or oraclelinux 8.6 or centos 8.6... only rockylinux 8.6

The mouse position seems to be cropped to a fixed area at the top left of a window

Sounds like the dummy driver is not patched? Are you sure that you have installed all the components from the xpra repo? You may be able to workaround the issue by launching the server with --resize-display=4k. You can get the exact coordinates with -d mouse, this may give us a clue.

--clipboard-direction=both

This is already the default.

--encoding=webp

As per the documentation, tweak the quality and speed, not the encoding(s) options.

[taranu]

RHEL 8.6

That's quite old. Which repository path are you using? We don't have builds for almalinux 8.6 or oraclelinux 8.6 or centos 8.6... only rockylinux 8.6

I don't have root on this server, so I installed the missing dependencies via conda (py3.12 env) and compiled xpra myself following #3360 (thanks for that). Actually, having checked again, the last time I had a server working without this issue it was an older py3.10 env (which likely had older versions of most dependencies).

The mouse position seems to be cropped to a fixed area at the top left of a window

Sounds like the dummy driver is not patched? Are you sure that you have installed all the components from the xpra repo? You may be able to workaround the issue by launching the server with --resize-display=4k. You can get the exact coordinates with -d mouse, this may give us a clue.

The system dummy_drv.so is dated Aug 12, 2018. I tried running with -d mouse and there is something interesting. The lines are like:

2024-09-12 23:26:33,602 do_send_mouse_position() position=('pointer', 0, 4801, 1, (2048, 122, 2022, 63), {'modifiers': [], 'buttons': []})

I checked against a screenshot and the right edge of the mouse response region in the window is exactly 2022 pixels from the left. Unfortunately I can't quite tell where the bottom edge is easily but it's around 1420 pixels (maybe 1440?).

I tried with --resize-display=4k and resize-display=2560x2880 (the native resolution of my display) and neither made a difference. Yes, that is an unusual resolution; I'm not sure if that's related.

[totaam]

I don't have root on this server, so I installed the missing dependencies via conda (py3.12 env)

As per https://github.com/Xpra-org/xpra/wiki/Reporting-Bugs, this should have been in the OP.

You're not using a supported installation method, and you end up with buggy packages. ie: dummy driver.

[totaam]

BTW, there is a way to use the non-buggy dummy driver without needing root access. You can modify the xorg config file to load driver modules from a different directory.

[taranu]

Sorry, I misspoke - it was a py3.11 conda env. I tried recompiling with a more recent dummy driver but the server would not start. But never mind that...

Instead I tried the conda-forge-provided 5.0.2 and 5.0.7 and both work fine. Upgrading to 6.1.0 (without changing any dependencies) results in this same bug, albeit the affected area window is different from what I originally saw.

I suppose conda-forge is also not a supported installation method but AFAICT conda does not provide the dummy driver itself, so if this is indeed a bug with older dummy drivers, it does not seem to manifest in 5.0.x.

[totaam]

The initial resolution should be the same in both branches: https://github.com/Xpra-org/xpra/blob/518b2713798a14f2a5d68ed8ec7c73e5a4f68986/xpra/x11/vfb_util.py#L70-L73

There were some fixes in v5 related to the initial resolution, but only for desktop and monitor modes: a5edfc628ed02837faf6e337a167ae02ab925ec5, 1973b37e38f00b22d591445e19ce84b1052aef62