-
-
Notifications
You must be signed in to change notification settings - Fork 171
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Menu by mouse right click doesn't render correctly. #4341
Comments
What is the total resolution you are running at? (this is shown in the server log) |
When I connect two monitors, the menu is not ok and I got : client root window size is 6464x2264 When I disconnect second monitor, the menu is ok and I got : received updated display dimensions |
Can you attach a screenshot? |
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. |
Possibly.
Debian uses the
Whereas other distributions use Xdummy. Only the latter supports virtual monitors. That's most of it. |
Can you suggest other linux distro? |
AFAIK, only debian messes up xorg, so anything else should work better. |
Do you think I can use fedora docker image on ubuntu host to test the issue is ok? |
I don't see why not |
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. I will test this with fedora docker image and leave the result once done. |
I setup the fedora docker and run xpra via tcp. Updated: |
OK, so you can use Xdummy without needing tty tricks, but I still would not recommend it: #2834 (comment)
Damn. That's a shame.
I would not expect any differences with Debian + Xdummy.
That's surprising.
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 |
I shared the above but my actual monitor resolution on left size is 2560x1440, not 3584x2016. The right one is correct. |
On client,
|
I did some calculation. The size, "3584x2016" is just relative value as you said. It is not the actual monitor resolution. Log for HIDPI ratio 175 on both monitor:
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,
|
I found that the offset height is not drawn but move.
In the case of popup is not in a monitor and offset is calculated(-530), the issue is reproduced.
In the case of popup is in a monitor and no offset, the issue is not reproduced.
|
To fix this bug we need one of these two options:
|
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.
|
Log when starting xpra on Ubuntu 24.04 + Xdummy
Log when starting xpra with Fedora docker
|
But earlier you said:
So I thought that Xdummy didn't help. Perhaps it does and there is a second, different bug? |
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. |
@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.
And it works well. After this, when I follow the below steps, the issue is NOT reproduced.
I had the below log.
At the last case, I close the xpra server and connect to xpra server with two monitor get connected.
I suspected that when the initial screen size bigger than new calculated size, the update would not happen.
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: Line 72 in 37fe0a0
Line 83 in 37fe0a0
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. |
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: Their downstream packaging is even worse - so bad it's shocking: What version of the dummy driver package do you have installed?
I am closing this since there's nothing to fix in xpra itself AFAICT. |
|
@totaam I have one doubt about this issue. 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. |
I think I can mitigate this issue by changing the default res to small enough value such as 640x480.
In addition to this, for desktop, the default value is small,
|
This is a Debian / Ubuntu bug since we can't reproduce on other distros.
That's already the case.
In that case, we use the largest resolution to ensure all the clients can fit. |
I think the issue is same with #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
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.
The text was updated successfully, but these errors were encountered: