Xpra: Ticket #1658: mouse events in black border around desktop area

xpra v2.2-r17160 on debian 9

If running xpra --start-desktop and maximizing the client window, there can be a black area around the shown desktop if the vfb X server does not provide a matching resolution.

Mouse events (moving and clicks) in the black area should not do anything, but they happen to the outer border of the desktop.

Example: mouse click in black area above clock in xfce4-panel shows calendar, but this should only happen if I click directly on the clock. example of black border around the window contents

Mouse movements in black area above the panel causes highlighting of nearest panel objects.

Not really a problem so far, just different from what I would expect.



Fri, 13 Oct 2017 02:17:47 GMT - Antoine Martin: status, milestone changed

Originally reported in #1656, see ticket:1656#comment:24.

If we swallow pointer motion events, there are some potential problems with seamless mode when the window size does not match its contents exactly: the virtual pointer could linger on the edge of the server side window - which could trigger unwanted behaviour.


Sat, 03 Feb 2018 05:56:31 GMT - Antoine Martin: attachment set

example of black border around the window contents


Sat, 03 Feb 2018 06:00:10 GMT - Antoine Martin: description changed

there can be a black area around the shown desktop if the vfb X server does not provide a matching resolution.

This is less of a problem nowadays since you can:

(converted link to an attachment so it doesn't bitrot)


Tue, 27 Feb 2018 12:36:58 GMT - mviereck:

This happens rather with Xwayland than with Xvfb or Xdummy as it unfortunately does not support resolution changes with xrandr.

In seamless mode for single applications I do not expect an issue as they are always scaled up to the client screen resolution. In that case I am not able to move the mouse outside of the virtual desktop.


Tue, 27 Feb 2018 16:02:33 GMT - Antoine Martin:

This happens rather with Xwayland than with Xvfb or Xdummy as it unfortunately does not support resolution changes with xrandr.

Then this is an unsupported configuration, we rely on randr to make things match. Use Xvfb instead.


Tue, 27 Feb 2018 16:24:07 GMT - mviereck:

Use Xvfb instead.

For most things I use Xvfb or Xdummy. Xwayland has the advantage of supporting hardware acceleration, but the disadvantage of bad xrandr support.

Aside from this minor issue of mouse events at the edge in desktop mode, xpra works quite well with Xwayland. Also, xpra clients sets the window size right, the issue only appears if I maximize the window.

So far, it is fine for me, xpra handles Xwayland quite well.


Mon, 07 May 2018 05:43:59 GMT - Antoine Martin: milestone changed


Mon, 11 Jun 2018 17:57:25 GMT - Antoine Martin:

Testing as per ticket:1656#comment:12

Still TODO:


Tue, 12 Jun 2018 13:17:33 GMT - Antoine Martin:

The cursor handling is "fixed" in r19621, though it does break the neat dependency separation from #1838.

Only one item left: re-test all the desktop and shadow servers with multi-window mode by hand. (#1805) Maybe use fullscreen to trigger more easily?


Tue, 21 Aug 2018 18:46:46 GMT - Antoine Martin: owner, status changed

Was worth re-testing (I temporarily disabled size-hints to get black borders without using fullscreen or maximize): r19615 was buggy for the multi-monitor multi-window case (#1805), fixed in r20162.

I have not re-tested on macos shadow servers since that involves lugging too many things around. Those are similar to mswindows shadow servers anyway.

@mviereck: please close if this works for you. beta builds with these changes can be found here: https://xpra.org/beta


Tue, 11 Sep 2018 16:04:30 GMT - Antoine Martin: status changed; resolution set

Not heard back, closing.


Wed, 03 Apr 2019 15:17:59 GMT - Antoine Martin:

Related bug: #2249


Sat, 23 Jan 2021 05:30:19 GMT - migration script:

this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/1658