Menu by mouse right click doesn't render correctly.

[unisons]

I think the issue is same with https://github.com/Xpra-org/xpra/issues/3465.

When I clicked the right mouse button to show the context menu in Android Studio, the bottom of menu windows didn't render properly.

My setup is

• client : Windows 11
• server : Ubuntu 24.04
• xpra : 6.1.2

In Windows 11, I have two monitors and their resolution and hidpi scale setting are different.

It will be hard to provide the log due to my work place policy. But the situation is pretty identical with issue 3465. I will test the issue is reproduced when I align the monitors bottom line and share the result by the comment.

[totaam]

What is the total resolution you are running at? (this is shown in the server log) It's quite possible that this a Xvfb resolution problem, known to happen on Debian based distros.

[unisons]

When I connect two monitors, the menu is not ok and I got :

client root window size is 6464x2264 Default (977x342 mm - DPI: 168x168) ... 2880x1800 at 3584x0 (344x215 mm - DPI: 213x213) workarea: 2880x1716 at 3584x0 ... 3584x2016 at 0x248 (598x336 mm - DPI: 152x152) workarea: 3584x2016 at 0x248 server virtual display now set to 6464x2264 DPI set to 168x168

When I disconnect second monitor, the menu is ok and I got :

received updated display dimensions client dispay size is 2880x1800 Default (977x342 mm - DPI: 168x168) ... 2880x1800 at 3584x0 (344x215 mm - DPI: 213x213) workarea: 2880x1716 at 3584x0 ... 3584x2016 at 0x248 (598x336 mm - DPI: 152x152) workarea: 3584x2016 at 0x248 DPI set to 168x168 sent updated screen size to a clients: 2880x1800 (max 8192x4096)

[totaam]

Can you attach a screenshot? There's no guarantee that this is the issue, but I suspect that this is a Debian problem - using a better distro should fix this. Debian seems to be unable not to butcher Xdummy, so we are forced to use Xvfb on this platform. Unlike Xdummy, Xvfb is unable to virtualize monitors.

[unisons]

It would be hard to take the screenshot due to my workplace policy. I can draw it how it looks like later.

Is it an issue in server side? If you give me some information, I'd like to read some code by myself.

[totaam]

Is it an issue in server side?

Possibly. There aren't enough details for me to be sure about anything.

If you give me some information, I'd like to read some code by myself.

Debian uses the Xvfb command: https://github.com/Xpra-org/xpra/blob/27ccf0e88d8d9dae33ca9b925007bd00596ac249/fs/etc/xpra/conf.d/55_server_x11.conf.in#L32 Whereas other distributions use Xdummy. Only the latter supports virtual monitors. That's most of it.

[unisons]

Can you suggest other linux distro?

[totaam]

AFAIK, only debian messes up xorg, so anything else should work better. Fedora is the one I personally use and has the most up to date packages in the repositories.

[unisons]

Do you think I can use fedora docker image on ubuntu host to test the issue is ok?

[totaam]

I don't see why not

[unisons]

Aligning the bottom of monitors, still issue is reproduced.

About the screenshot, I draw it as below.

I tried to change to use dummy by adding /etc/xpra/conf.d/55_seever_x11.conf by using the commented line staring with Xorg. As a result, I could grep the process started with /usr/lib/xorg/Xorg-for-Xpra-100. But the issue is still reproduced. (With xvfb, I could find a process of Xvfb-for-Xpra-100)

I will test this with fedora docker image and leave the result once done.

[unisons]

I setup the fedora docker and run xpra via tcp. The issue is reproduced but a little bit differently. The pop menu is displayed in wrong position, even in other monitor when I start to use two monitors. When use the single monitor is working very well.

Updated: When I reattach the xpra with two monitors connected, it is working well. The above issue occured when I connect new monitor after attaching to xpra.

[totaam]

As a result, I could grep the process started with /usr/lib/xorg/Xorg-for-Xpra-100.

OK, so you can use Xdummy without needing tty tricks, but I still would not recommend it: https://github.com/Xpra-org/xpra/issues/2834#issuecomment-2142505742

But the issue is still reproduced.

Damn. That's a shame.

I setup the fedora docker and run xpra via tcp.

I would not expect any differences with Debian + Xdummy. These should effectively behave the same as far as xpra is concerned.

The issue is reproduced but a little bit differently.

That's surprising.

The above issue occured when I connect new monitor after attaching to xpra.

That's odd, adding a new monitor should re-initialize the virtual monitors.

---

I think that the problem comes from the way GTK hides the true monitor geometries from us: #3208 (it's even worse when monitors are added to the left of the primary one) I am afraid that this will take quite a lot of effort - it might just be easier to write a better client without GTK: #4314 or #1995

[unisons]

... 2880x1800 at 3584x0 (344x215 mm - DPI: 213x213) workarea: 2880x1716 at 3584x0 ... 3584x2016 at 0x248 (598x336 mm - DPI: 152x152) workarea: 3584x2016 at 0x248

I shared the above but my actual monitor resolution on left size is 2560x1440, not 3584x2016. The right one is correct. I set the hidpi ratio to 125% for left one and 175% for right one.

[unisons]

On client,

2024-09-02 19:51:04,225 get_workareas() GetMonitorInfo(93391689)=
  {'Work': (0, 0, 2880, 1716), 'Monitor': (0, 0, 2880, 1800), 'Flags': 1, 'Device': '\\\\.\\DISPLAY1'}
2024-09-02 19:51:04,225 get_workareas() GetMonitorInfo(434441319)=
 {'Work': (-3584, 497, 0, 2513), 'Monitor': (-3584, 497, 0, 2513), 'Flags': 0, 'Device': '\\\\.\\DISPLAY2'}
2024-09-02 19:51:04,226 get_workareas()=[(0, 0, 2880, 1716), (0, 0, 3584, 2016)]

[totaam]

Ah, well, then that's a completely different problem, a client side one. You can find some details sprinkled in #3943 and #4205 The gist of it is that GTK uses cooked coordinates but we want the real ones. Unfortunately, MS Windows lies to GTK.

[unisons]

I did some calculation. The size, "3584x2016" is just relative value as you said. It is not the actual monitor resolution. I set the same HIDPI ratio for both monitor to 175% and the issue is started to show on left monitor.

Log for HIDPI ratio 175 on both monitor:

2024-09-02 20:23:21,648 get_workareas() GetMonitorInfo(93391689)=
  {'Work': (0, 0, 2880, 1716), 'Monitor': (0, 0, 2880, 1800), 'Flags': 1, 'Device': '\\\\.\\DISPLAY1'}
2024-09-02 20:23:21,648 get_workareas() GetMonitorInfo(434441319)=
  {'Work': (-2560, 355, 0, 1795), 'Monitor': (-2560, 355, 0, 1795), 'Flags': 0, 'Device': '\\\\.\\DISPLAY2'}
2024-09-02 20:23:21,649 get_workareas()=[(0, 0, 2880, 1716), (0, 0, 2560, 1440)]

I think the issue is reproduced on the smaller monitor in virtual screen size.

In this api documentation, https://learn.microsoft.com/en-us/windows/win32/api/winuser/ns-winuser-monitorinfo, the values are not real monitor resolution.

rcMonitor

A RECT structure that specifies the display monitor rectangle, expressed in virtual-screen coordinates. Note that if the monitor is not the primary display monitor, some of the rectangle's coordinates may be negative values.

[unisons]

I found that the offset height is not drawn but move.

2024-09-02 21:40:56,195  client root window size is 6464x2513
2024-09-02 21:40:56,195 debug enabled for ['xpra.util.screen', 'screen']
2024-09-02 21:40:56,195   Default (977x379 mm - DPI: 168x168)
2024-09-02 21:40:56,195     Samsung Electronics Co.,Ltd. Samsung OLED Display 2880x1800 at 3584x0    (344x215 mm - DPI: 213x213) workarea: 2880x1716 at 3584x0
2024-09-02 21:40:56,195     LS27B61x         3584x2016 at    0x497  (598x336 mm - DPI: 152x152) workarea: 3584x2016 at    0x497
2024-09-02 21:40:56,209 setting dummy crtc and output 0 to:
2024-09-02 21:40:56,209  2880x1800 60Hz (344x215 mm, dpi=213) at 3584,0
2024-09-02 21:40:56,216 setting dummy crtc and output 1 to:
2024-09-02 21:40:56,216  3584x2016 75Hz (598x336 mm, dpi=152) at 0,497
2024-09-02 21:40:56,230 monitor 0 is 'Samsung Electronics Co.,Ltd. Samsung OLED Display-0' 2880x1800
2024-09-02 21:40:56,230 monitor 1 is 'LS27B61x' 3584x2016
2024-09-02 21:40:56,230 get_max_screen_size()=(8192, 4320)
2024-09-02 21:40:56,230 calculate_workarea(6464, 2513)
2024-09-02 21:40:56,230 _NET_WORKAREA=[0, 0, 6464, 2513]
2024-09-02 21:40:56,231 _NET_DESKTOP_GEOMETRY=[6464, 2513]

In the case of popup is not in a monitor and offset is calculated(-530), the issue is reproduced.

2024-09-02 21:41:04,021 client   2 @17.297 process_new_common: wid=82, OR=True, geometry((4758, 1572, 859, 758))=(4758, 1572, 859, 758) / (859, 758)
2024-09-02 21:41:04,024 client   2 @17.297 set_decorated(True) re-adjusting window location using {'normal': (12, 12), 'fixed': (3, 3), 'minimum': (232, 64), 'menu-bar': 34, 'border': 1, 'caption': 40, 'offset': (12, 52), 'frame': (12, 12, 52, 12)}
2024-09-02 21:41:04,025 client   2 @17.297 setup_window() position=(4758, 1572), set_initial_position=False, OR=True, decorated=True
2024-09-02 21:41:04,027 client   2 @17.297 after removing areas visible on Samsung Electronics Co.,Ltd. Samsung OLED Display from [R(4758, 1572, 859, 758)]: [R(4758, 1800, 859, 530)]
2024-09-02 21:41:04,027 client   2 @17.297 after removing areas visible on (표준 모니터 종류) LS27B61x from [R(4758, 1800, 859, 530)]: [R(4758, 1800, 859, 530)]
2024-09-02 21:41:04,028 client   2 @17.297 pixels in monitor={195852: 0}
2024-09-02 21:41:04,029 client   2 @17.297 calculating OR offset for monitor 0: Samsung Electronics Co.,Ltd. Samsung OLED Display
2024-09-02 21:41:04,029 client   2 @17.297 calculate_window_offset(4758, 1572, 859, 758)=(0, -530)
2024-09-02 21:41:04,029 client   2 @17.313 OR offsets=(0, -530)

In the case of popup is in a monitor and no offset, the issue is not reproduced.

2024-09-02 21:56:24,107 client   2 @37.375 process_new_common: wid=88, OR=True, geometry((4984, 702, 858, 758))=(4984, 702, 858, 758) / (858, 758)
2024-09-02 21:56:24,110 client   2 @37.375 set_decorated(True) re-adjusting window location using {'normal': (12, 12), 'fixed': (3, 3), 'minimum': (232, 64), 'menu-bar': 34, 'border': 1, 'caption': 40, 'offset': (12, 52), 'frame': (12, 12, 52, 12)}
2024-09-02 21:56:24,111 client   2 @37.375 setup_window() position=(4984, 702), set_initial_position=False, OR=True, decorated=True
2024-09-02 21:56:24,112 client   2 @37.375 after removing areas visible on Samsung Electronics Co.,Ltd. Samsung OLED Display from [R(4984, 702, 858, 758)]: []
2024-09-02 21:56:24,112 client   2 @37.375 OR offsets=None

[totaam]

To fix this bug we need one of these two options:

• get Gtk to see the true window geometries, not the ones cooked up by the OS
• bypass or remove Gtk

[unisons]

The issues is not reproduced with the same client (windows 11) and fedora docker. So I am not sure it is a problem of the client.

When I tested this with fedora docker, even I clicked the right mouse button on the similar position. The offset is not caculated as below.

2024-09-03 20:03:17,385 process_new_common: wid=4, OR=True, geometry((5110, 1204, 705, 385))=(5110, 1204, 705, 385) / (705, 385)
2024-09-03 20:03:17,385 set_decorated(True) re-adjusting window location using {'normal': (12, 12), 'fixed': (3, 3), 'minimum': (232, 64), 'menu-bar': 34, 'border': 1, 'caption': 40, 'offset': (12, 52), 'frame': (12, 12, 52, 12)}
2024-09-03 20:03:17,390 setup_window() position=(5110, 1204), set_initial_position=False, OR=True, decorated=True
2024-09-03 20:03:17,390 after removing areas visible on Samsung Electronics Co.,Ltd. Samsung OLED Display from [R(5110, 1204, 705, 385)]: []
2024-09-03 20:03:17,390 OR offsets=None
2024-09-03 20:03:17,390 set_size_constraints(typedict({}), (32767, 32767))

[unisons]

Log when starting xpra on Ubuntu 24.04 + Xdummy

2024-09-03 20:31:15,323 may_adjust_scaling() server_is_desktop=False, desktop_fullscreen=False
2024-09-03 20:31:15,324 validating server_max_desktop_size=(8192, 4320) vs root size=(6464, 2513)
2024-09-03 20:31:15,324 maximum packet size set to 134221824
2024-09-03 20:31:15,325 debug enabled for ['xpra.platform.gui', 'screen']
2024-09-03 20:31:15,328 get_icc_info() intents={<Intent.RELATIVE_COLORIMETRIC: 1>: 'relative-colorimetric', <Intent.SATURATION: 2>: 'saturation', <Intent.ABSOLUTE_COLORIMETRIC: 3>: 'absolute-colorimetric'}
2024-09-03 20:31:15,334 get_icc_info() display_profile=<PIL.ImageCms.ImageCmsProfile object at 0x0000025e44c6d110>
2024-09-03 20:31:15,336 <module 'PIL.ImageCms' from 'C:\\Program Files\\Xpra\\lib\\PIL\\ImageCms.pyc'> lacks getData

(Xpra_cmd.exe:65908): Pango-WARNING **: 20:31:15.853: couldn't load font "DejaVu Serif Not-Rotated 59.797", falling back to "Sans Not-Rotated 59.797", expect ugly output.

(Xpra_cmd.exe:65908): Pango-WARNING **: 20:31:15.864: couldn't load font "URW Bookman Not-Rotated 52.762", falling back to "Sans Not-Rotated 52.762", expect ugly output.
2024-09-03 20:31:15,883 running
2024-09-03 20:31:15,885 server has resized the desktop to: 8192x4096 (max 8192x4320)
2024-09-03 20:31:15,885 may_adjust_scaling() server_is_desktop=False, desktop_fullscreen=False

Log when starting xpra with Fedora docker

2024-09-03 20:31:40,709 may_adjust_scaling() server_is_desktop=False, desktop_fullscreen=False
2024-09-03 20:31:40,709 validating server_max_desktop_size=(8192, 4320) vs root size=(6464, 2513)
2024-09-03 20:31:40,709 maximum packet size set to 134221824
2024-09-03 20:31:40,709 debug enabled for ['xpra.platform.gui', 'screen']
2024-09-03 20:31:40,714 get_icc_info() intents={<Intent.RELATIVE_COLORIMETRIC: 1>: 'relative-colorimetric', <Intent.SATURATION: 2>: 'saturation', <Intent.ABSOLUTE_COLORIMETRIC: 3>: 'absolute-colorimetric'}
2024-09-03 20:31:40,724 get_icc_info() display_profile=<PIL.ImageCms.ImageCmsProfile object at 0x000001f643ebcd50>
2024-09-03 20:31:40,724 <module 'PIL.ImageCms' from 'C:\\Program Files\\Xpra\\lib\\PIL\\ImageCms.pyc'> lacks getData
2024-09-03 20:31:40,747 running

[totaam]

The issues is not reproduced with the same client (windows 11) and fedora docker.

But earlier you said:

I setup the fedora docker and run xpra via tcp. The issue is reproduced but a little bit differently.

So I thought that Xdummy didn't help. Perhaps it does and there is a second, different bug?

[unisons]

Updated: When I reattach the xpra with two monitors connected, it is working well. The above issue occured when I connect new monitor after attaching to xpra.

I added this for Fedora test.

I think the issue is not occured when the app(android studio) recognized that there is no more space to draw the popup window. In this case, the app can decided to draw the popup window on the upper direction from. It is a basic behaviour, I think. As a result, when no offset is generated, the issue is not generated.

[unisons]

@totaam I found the workaround for this issue and what causes this issue.

When I connect with single monitor, the screen size is decided like the below.

2024-09-04 17:46:59,105  client root window size is 2880x1800
2024-09-04 17:46:59,105 debug enabled for ['xpra.util.screen', 'screen']
2024-09-04 17:46:59,105   Default (435x272 mm - DPI: 168x168) workarea: 2880x1716
2024-09-04 17:46:59,105     Samsung Electronics Co.,Ltd. Samsung OLED Display (344x215 mm - DPI: 213x213)
2024-09-04 17:46:59,105 current server resolution is 8192x4096     <<<< Initial screen size of server
2024-09-04 17:46:59,105 maximum client resolution is 2880x1800
2024-09-04 17:46:59,105 minimum client resolution is 2880x1800
...
2024-09-04 17:46:59,108 configure_best_screen_size()=(2880, 1800)
2024-09-04 17:46:59,114 new screen dimensions: 8192x4096 <<< the new server screen size is 8192x4096
...
2024-09-04 17:46:59,136 client   1 @12.875 validating server_max_desktop_size=(8192, 4320) vs root size=(2880, 1800)

And it works well. After this, when I follow the below steps, the issue is NOT reproduced.

1. Close the current xpra connection
2. Connecting new monitor
3. Reattaching the xpra server

I had the below log.

2024-09-06 10:44:07,823 do_parse_screen_info(ClientConnectionMuxer(3 : Protocol(socket socket:@xpra/100)), (6464, 2513))
2024-09-06 10:44:07,823  client root window size is 6464x2513
2024-09-06 10:44:07,823 debug enabled for ['xpra.util.screen', 'screen']
2024-09-06 10:44:07,824   Default (977x379 mm - DPI: 168x168) workarea: 6464x2429
2024-09-06 10:44:07,824     Samsung Electronics Co.,Ltd. Samsung OLED Display 2880x1800 at 3584x0    (344x215 mm - DPI: 213x213) workarea: 2880x1716 at 3584x0
2024-09-06 10:44:07,824     LS27B61x         3584x2016 at    0x497  (598x336 mm - DPI: 152x152) workarea: 3584x1932 at    0x497
2024-09-06 10:44:07,824 current server resolution is 2880x1800    <<<< previous size is used, I don't know where it came.
2024-09-06 10:44:07,824 maximum client resolution is 6464x2513
2024-09-06 10:44:07,824 minimum client resolution is 6464x2513
...
2024-09-06 10:44:07,848 configure_best_screen_size()=(6464, 2513)
2024-09-06 10:44:07,849 client resolution is (6464, 2513), current server resolution is 2880x1800
...
2024-09-06 10:44:07,858 do_screen_changed(<GdkX11.X11Screen object at 0x738878062940 (GdkX11Screen at 0x167fd60)>)
2024-09-06 10:44:07,858 new screen dimensions: 6464x1800 <<< the new server screen size is 6464x1800

At the last case, I close the xpra server and connect to xpra server with two monitor get connected. The issue is reproduced and I had the below log.

2024-09-06 20:07:48,305 do_parse_screen_info(ClientConnectionMuxer(1 : Protocol(socket socket:/run/user/1000/xpra/dandeon-100)), (6464, 2513))
2024-09-06 20:07:48,305  client root window size is 6464x2513
2024-09-06 20:07:48,305 debug enabled for ['xpra.util.screen', 'screen']
2024-09-06 20:07:48,305   Default (977x379 mm - DPI: 168x168) workarea: 6464x2429
2024-09-06 20:07:48,305     Samsung Electronics Co.,Ltd. Samsung OLED Display 2880x1800 at 3584x0    (344x215 mm - DPI: 213x213) workarea: 2880x1716 at 3584x0
2024-09-06 20:07:48,305     LS27B61x         3584x2016 at    0x497  (598x336 mm - DPI: 152x152) workarea: 3584x1932 at    0x497
2024-09-06 20:07:48,305 current server resolution is 8192x4096  <<< initial screen size
2024-09-06 20:07:48,305 maximum client resolution is 6464x2513
2024-09-06 20:07:48,305 minimum client resolution is 6464x2513
...
2024-09-06 20:07:48,311 configure_best_screen_size()=(6464, 2513)
2024-09-06 20:07:48,311 client resolution is (6464, 2513), current server resolution is 8192x4096
2024-09-06 20:07:48,312 get_max_screen_size()=(8192, 4320)
2024-09-06 20:07:48,317 do_screen_changed(<GdkX11.X11Screen object at 0x76c154d4f600 (GdkX11Screen at 0x29b2d60)>)
2024-09-06 20:07:48,318 new screen dimensions: 8192x4096  <<< the new server screen size 

I suspected that when the initial screen size bigger than new calculated size, the update would not happen. So I used the below command line to use smaller init server display size and the issue is gone. (Need to restart the xpra server to make environment variable effective)

& 'C:\Program Files\Xpra\Xpra_cmd.exe' start ssh://[ID@IP_ADDR/DISPLAY] --keyboard-sync=no --audio=no --encoding=jpeg --env=XPRA_DEFAULT_VFB_RESOLUTION=640x480 --video=no -d screen,geometry

2024-09-06 20:18:27,445 current server resolution is 640x480  <<< 
2024-09-06 20:18:27,445 maximum client resolution is 6464x2513
2024-09-06 20:18:27,445 minimum client resolution is 6464x2513
...
2024-09-06 20:18:27,484 new screen dimensions: 6464x2513 <<< the new server screen size is correct.

I can't find out the reason of this but you can find the cause and make the patch for this.

The init server screen is obtained by the below code:

https://github.com/Xpra-org/xpra/blob/37fe0a0af52e6a03129e68ab00ecb828f872003d/xpra/x11/vfb_util.py#L72

https://github.com/Xpra-org/xpra/blob/37fe0a0af52e6a03129e68ab00ecb828f872003d/xpra/x11/vfb_util.py#L83

At last, I think it would be good to set the screen size to workarea size to possibly prevent from drawing over the task bar.

[unisons]

it seems that this is a platform specific issue of Ubuntu 24.04 or debian. I found this error log and this prevents from setting a display with calculated best resolution from client resolution. I can't find this error log when I am testing with fedora docker image. Anyway still the workaround is working. When the server resolution is smaller than calculated one, the reconfiguration of server resolution is working with the below error logs.

2024-09-10 16:00:06,680 do_add_screen_size(6464x2513@50, 6464, 2513, 50000)
...
2024-09-10 16:00:06,710 deleting monitor 2: DUMMY1
2024-09-10 16:00:06,710 found 5 monitors still active: VFB0-94536.285453294, VFB0-94533.800961292, VFB-0, VFB1-94536.285475618, VFB2-94536.285495329
2024-09-10 16:00:06,710 matching monitor index 0 to 0: {'geometry': (3584, 0, 2880, 1800), 'primary': True, 'refresh-rate': 60000, 'scale-factor': 1, 'width-mm': 344, 'height-mm': 215, 'manufacturer': 'Samsung Electronics Co.,Ltd.', 'model': 'Samsung OLED Display', 'subpixel-layout': 'unknown', 'workarea': (3584, 0, 2880, 1716), 'name': 'Samsung Electronics Co.,Ltd. Samsung OLED Display'}
2024-09-10 16:00:06,710 XRRSetMonitor(0x24c3930, 0x44b, 0x7ffff8966d60) output=78, geometry=(3584, 0, 2880, 1800) (344x215 mm)
2024-09-10 16:00:06,710 monitor 0 is 'Samsung Electronics Co.,Ltd. Samsung OLED Display' 2880x1800
2024-09-10 16:00:06,710 matching monitor index 1 to 1: {'geometry': (0, 497, 3584, 2016), 'primary': False, 'refresh-rate': 74970, 'scale-factor': 1, 'width-mm': 598, 'height-mm': 336, 'manufacturer': '(표준 모니터 종류)', 'model': 'LS27B61x', 'subpixel-layout': 'unknown', 'workarea': (0, 497, 3584, 2016), 'name': '(표준 모니터 종류) LS27B61x'}
2024-09-10 16:00:06,710 XRRSetMonitor(0x24c3930, 0x44b, 0x7ffff8966d60) output=79, geometry=(0, 497, 3584, 2016) (598x336 mm)
2024-09-10 16:00:06,710 monitor 1 is 'LS27B61x' 3584x2016
2024-09-10 16:00:06,710 get_X_error(..) initialized error names: {0: 'Success'}
2024-09-10 16:00:06,711 Warning: 'XError: BadValue (integer parameter out of range for operation)' detected while already in unwind; discarding

[totaam]

it seems that this is a platform specific issue of Ubuntu 24.04 or debian.

And not for the first time, which is why they are tier-2 for now - and probably will be downgraded further before too long: https://github.com/Xpra-org/xpra/wiki/Platforms

Their downstream packaging is even worse - so bad it's shocking: https://github.com/Xpra-org/xpra/wiki/Distribution-Packages

---

What version of the dummy driver package do you have installed? Our debian repo should include: https://github.com/Xpra-org/xpra/blob/cc880e36fe1a5605c408b23a523da900cd068bad/packaging/debian/xserver-xorg-video-dummy/changelog#L1

I am closing this since there's nothing to fix in xpra itself AFAICT.

[unisons]

apt list | grep xserver-xorg-video-dummy

xserver-xorg-video-dummy-hwe-18.04/noble 3:14.6 amd64
xserver-xorg-video-dummy/noble,now 1:0.4.1-3 amd64 [installed]

[unisons]

@totaam I have one doubt about this issue. It seems that when the server resolution is smaller than the client resolution, the update to client resolution happens. But when the server resolution is bigger than the client resolution, it doesn't happen. I think the update should happen always. I have tried to find that condition but failed.

Can you check this logic and fix to update the server solution always according to the client's one (maybe only one client case)?

I think when there are many clients to the server, this issue will happen on the client having different resolution with the server.

[unisons]

I think I can mitigate this issue by changing the default res to small enough value such as 640x480. If you think it is good, I can submit the change.

def parse_env_resolutions(envkey="XPRA_DEFAULT_VFB_RESOLUTIONS",
                          single_envkey="XPRA_DEFAULT_VFB_RESOLUTION",
                          default_res="8192x4096", <<-- change to 640x480

In addition to this, for desktop, the default value is small,

def get_desktop_vfb_resolutions(default_refresh_rate=DEFAULT_REFRESH_RATE//1000):
    return parse_env_resolutions("XPRA_DEFAULT_DESKTOP_VFB_RESOLUTIONS",
                                 "XPRA_DEFAULT_DESKTOP_VFB_RESOLUTION",
                                 "1280x1024",
                                 default_refresh_rate=default_refresh_rate)

[totaam]

This is a Debian / Ubuntu bug since we can't reproduce on other distros. No, we can't change the default resolution down - that causes other problems. Please use a better distro.

Can you check this logic and fix to update the server solution always according to the client's one (maybe only one client case)?

That's already the case.

I think when there are many clients to the server, this issue will happen on the client having different resolution with the server.

In that case, we use the largest resolution to ensure all the clients can fit.