xpra icon
Bug tracker and wiki

Opened 2 months ago

Closed 2 months ago

#2135 closed defect (wontfix)

Ambiguous / Erroneous logic on commandline flag "-desktop-scaling"

Reported by: thiner Owned by: thiner
Priority: major Milestone: 2.5
Component: client Version: 2.4.x
Keywords: desktop-scaling Cc:

Description (last modified by Antoine Martin)

xpra/client/scaling_parser.py

"The desktop−scaling value can take the form:

desktop−size
the scaling will be enabled and the server will render to the given size. ie: 1600x1200
"

Basically I expect the "desktop-size" to work like: the pair I assign to it become the final xpra window size.

But there are at least two problems here:

  1. As for now r21542 it seems that the code contains an annoying bug on somewhere near line 108-109, where the integer division is done rather than a float division.

PoC: xpra attach :7 --desktop-scaling=10x10

There will be a line of log says something like:

2019-02-06 14:05:09,118 Warning: scaling values 0.0x0.0 are out of range

whereas --desktop-scaling=10.0x10.0 indicates otherwise.

I have no idea whether it is a feature but it follows a buggy pattern.

  1. Even without the float point number problem, The formula used in the source code is (width/root_width, height/root_height)

Consider that the X screen is 400x300 and my monitor is 1600x1200, to fit the X screen to my monitor I need to scale to 4x the original size, so width/1600 = 4, height/1200 = 4, yields that width=6400, height=4800, I will need to send 6400x4800 to make a 4x scaling, so that the final rendering window is 1600x1200.

I believe there is more likely a bug than a feature here...

Change History (4)

comment:1 Changed 2 months ago by Antoine Martin

Description: modified (diff)
Status: newassigned

comment:2 Changed 2 months ago by Antoine Martin

Owner: changed from Antoine Martin to thiner
Status: assignednew
  • the bug where 10 and 10.0 would give different results is fixed in r21559 - thanks for pointing that out - be aware that scaling values greater than 8 will be rejected: the client will try to use those values as a virtual screen size, which is too small
  • as for the second point:

    Consider that the X screen is 400x300

"X screen"?
You mean the server side virtual screen? Or just a specific X11 application window?

and my monitor is 1600x1200,

OK.

to fit the X screen to my monitor I need to scale to 4x the original size,
so width/1600 = 4, height/1200 = 4, yields that width=6400, height=4800, I will need to send 6400x4800 to make a 4x scaling, so that the final rendering window is 1600x1200.

Or just desktop-scaling=4.

I believe there is more likely a bug than a feature here...

I'm not really following, can you explain what doesn't work or isn't well documented?

comment:3 Changed 2 months ago by thiner

For the second point maybe I did not say it very clearly ...

Actually there are many sizes: physical monitor size, xpra desktop size, window size (in my monitor).

As for --desktop-scaling=AxB where A, B is greater than 8, I expect the size to be the final window size. So when the xpra desktop size is 400x300 and I want to scale it to 1920x1080 I do not need some strange algebra to find a strange value as scale and directly pass --desktop-scaling=1920x1080 should work.

However the code seems to divide the input with PHYSICAL MONITOR SIZE rather than xpra desktop size. I think that is wrong. Now when I pass 1920x1080 to it the resulting window is 400x300. How can I have a scaled 1920x1080 window? 9216x3888. That is ridiculous.

comment:4 Changed 2 months ago by Antoine Martin

Resolution: wontfix
Status: newclosed

As for --desktop-scaling=AxB where A, B is greater than 8, I expect the size to be the final window size.

That's not possible, sorry.
There may be multiple windows each with different geometries (ie: shadowing a server with multiple monitors), or you may be connecting to a seamless server. (which is what most people use xpra for).

Note: See TracTickets for help on using tickets.