FullScreen mode in xpra client

[totaam]

Issue migrated from trac ticket # 972

component: client | priority: major

2015-09-01 11:49:27: akaWolf created the issue

---

It would be nice, if xpra would have possibility to going into full screen mode, when attach to remote shadow session.
Like so: xpra attach --fullscreen

[totaam]

Problem: we don't know in advance if the remote session is the same size as the client's screen.
If it's smaller, we could show it with borders (no, we don't so scaling yet), but this is going to require quite a lot of code for managing the offsets.
If it's bigger, it is not going to work (would need downscaling).

If the client then resizes its screen, everything breaks...

@akaWolf: thoughts?

[totaam]

2015-09-03 09:59:02: akaWolf commented

---

@antoine

If it's smaller, there is no other way, than showing it with borders.
If it's bigger, we can just show part of screen and show scroll bar for moving the view-able part.
For beginning, there is no need to handle resizing of client screen (I can always just restart xpra client).

[totaam]

#976 could also help: we could also upscale the remote display if the dimensions are so far out that the local display would show only a small rectangle in the middle (as is the case when using a 4k display).

[totaam]

2015-09-04 10:00:55: akaWolf commented

---

@antoine, yeah, but better not hardcoded, but as enable option.

[totaam]

Done using scaling in r10645 (man page update in r10647), use it like so:

xpra attach --shadow-fullscreen=yes ...

And the remote display will be scaled to the size of the local one (see #976 for scaling implementation details).

Caveat: this does not handle multiple monitors well on all platforms, if any!

I may still try to do unscaled fullscreen, but probably not in this release, in which case the shadow-fullscreen flag may change from a boolean to a no|centered|scaled type of option.
This would require window contents to be offset from the top-left corner (somewhat similar to what would be needed for #508 with the "gtk menu" option).

@akaWolf: feedback welcome.

[totaam]

2015-09-16 09:05:07: akaWolf commented

---

@antoine

yeah, scaling should be an option.
for example:

  Scaling        - Scale the host computer's desktop relative to the size of
                   the VNC Viewer application window (Fit | AspectFit |
                   <width>x<height> | <width>x | x<height> | <percentage size>%
                   | <percentage width>%x<percentage height>%), or None to not
                   scale. (default=None)

only one more notice: can xpra also grab all keyboard events in fs mode?
see https://bugs.launchpad.net/ubuntu/+source/tightvnc/+bug/584823
remmina and realvnc have such functionality.

[totaam]

Fullscreen now works quite well for "start-desktop" mode (#1567), you can also make your remote shadow window fullscreen with Shift+F11 but we have not addressed the scrolling / scaling issues yet.

See also:

• allow client side shadow windows to be resized #530 resize client side shadow windows
• Resize desktop size with regard to browser window size #1557 resize desktop to match browser window
• fix fullscreen handling #1567 full screen client

[totaam]

2017-07-14 14:58:58: antoine uploaded file fullscreen-scaling.patch (5.6 KiB)

use scaling to fullscreen fixed size windows

[totaam]

The patch above kinda works, but is not ready for merging yet:

• the "window_scaling" part should be made generic, and maybe even replace the "desktop-scaling": keeping only one scaling value per window, allowing each window to be scaled independently (difficulty: not sure how we would adjust when the screen size changes or when the user changes the global desktop-scaling value...)
• there is no configuration option for this scaling, we just scale to fullscreen (no aspect ratio, etc) if the window is meant to be fixed size
• we should probably also handle windows which can be resized but that have size increments that don't match the fullscreen dimensions?
• we should remove the "desktop_fullscreen" option, and just use this instead

Related issues fixed:

• r16342: only send window state updates that the server is actually interested in
• r16344: when the shadow server is resized via randr, update the client window geometry (r16343: related scroll encoding error)

Re-scheduling.