ExtendedDesktopSize support?

[coredump4]

Hi, When using a noVNC v1.0.0 client with "remote resize" enabled, the user's desktop can be resized to fit the browser window if the server supports ExtendedDesktopSize encoding. For me, the resizing does not work for x11vnc v0.9.16, but does if I switch to Xvnc.

Does x11vnc support ExtendedDesktopSize? If it does, I could use some help figuring out why the client & server are not in agreement on their protocol extensions. Also, see this issue.

Thanks.

---

IssueHunt Summary

Backers (Total: $50.00)

• maxnet ($50.00)

Become a backer now!

Or submit a pull request to get the deposits!

Tips

• Checkout the Issuehunt explorer to discover more funded issues.
• Need some help from other developers? Add your repositories on IssueHunt to raise funds.

---

IssueHunt has been backed by the following sponsors. Become a sponsor

[clementnero]

Hello, Does someone have any update on this topic ? Thx

[coredump4]

I've had to move on to other tasks, but would still like to get away from Xvnc someday. I've searched through the x11vnc code a bit and can't find any evidence it supports ExtendedDesktopSize. None of the commits since 0.9.16 are in this area, so it looks like something (hopefully) on the backlog.

[coredump4]

Thank you! I'm eager to test this out.

[issuehunt-oss[bot]]

@maxnet has funded $50.00 to this issue.

---

• Submit pull request via IssueHunt to receive this reward.
• Want to contribute? Chip in to this issue via IssueHunt.
• Checkout the IssueHunt Issue Explorer to see more funded issues.
• Need help from developers? Add your repository on IssueHunt to raise funds.

[maxnet]

Added some pizza money for the reviewer ;-)

[coredump4]

I built x11vnc from your branch along with LibVNC/libvncserver, which already has your patch merged. And it almost works but not quite. When my noVNC client attaches I see: 01/08/2019 21:02:53 Enabling NewFBSize protocol extension for client 127.0.0.1 01/08/2019 21:02:53 Enabling ExtDesktopSize protocol extension for client 127.0.0.1 ...which looks good. But when dragging the corner of the browser window around randomly, it doesn't resize, and I see: 01/08/2019 21:03:20 Client requested resolution change to (1782x905) 01/08/2019 21:03:20 Sending rfbEncodingExtDesktopSize for size (2048x1536) resize prohibited 01/08/2019 21:03:35 Client requested resolution change to (1862x769) 01/08/2019 21:03:35 Sending rfbEncodingExtDesktopSize for size (2048x1536) resize prohibited 01/08/2019 21:04:15 Client requested resolution change to (1862x927) 01/08/2019 21:04:15 Sending rfbEncodingExtDesktopSize for size (2048x1536) resize prohibited Why would resize be prohibited? I confirmed noVNC is in remote resizing mode.

[maxnet]

Are that all messages you see in the log?

In addition to the log lines you see that are generated by libvncserver, x11vnc itself should print some additional lines as well (starting with "Received SetDesktopSize message from client requesting (%dx%d) framebuffer with screen configuration:")

If you do not see that, it is likely that x11vnc has not been compiled correctly with support for setdesktopsize hook. When you did ./configure it did print out it detected xrandr and "_rfbScreenInfo.setDesktopSizeHook" ?

And when running x11vnc it does not spit out any error messages mentioning xrandr? (e.g. "Need at least RANDR 1.3 to support scaling, only %d.%d available")

[coredump4]

Based on config.log, it seemed to find RANDR and "_rfbScreenInfo.setDesktopSizeHook": ac_cv_lib_Xrandr_XRRSelectInput=yes ac_cv_member_struct__rfbScreenInfo_setDesktopSizeHook=yes However there is no mention of RANDR in the x11vnc log file at runtime... I did find that odd.

[maxnet]

You did start x11vnc with -setdesktopsize ?

[coredump4]

With -setdesktopsize, I'm closer still, but I get: resize failed: invalid screen layout Is it able to resize to arbitrary sizes? FWIW I'm using the X "dummy" driver.

[maxnet]

Size must be in the ranges supported by your graphic driver. What does running the "xrandr" command under X report? E.g.:

$ xrandr
Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 16384 x 16384

Have not tested any dummy drivers. In fact the embedded device it was written for always reports having a screen even if nothing is connected. So have not tested headless that extensively either.

[maxnet]

Suspecting that the dummy X driver may not be supporting randr at all.

Currently it bails out directly in the code then:

   if (!xrandr_present)
        return FALSE;

Guess I should add a line that logs an error there.

Perhaps the new Virtual KMS driver is a better option if you have a system without any GPU. https://www.phoronix.com/scan.php?page=news_item&px=Virtual-KMS-VKMS-Linux-4.19 (Have not tested that either though)

[coredump4]

Dummy is supposed to support RANDR and should be a reasonable choice for a headless system. However I had Xinerama enabled in my xorg.conf, which conflicts with RANDR, so I subsequently disabled Xinerama. However, x11vnc now starts up but quickly exits. It doesn't report much in the log when this happens, but you can see where it received a SetDesktopSize message from the client, but then reports "caught X11 error" and dies. The line below "caught X11 error" is "deleted 64 tile_row polling images." but it's unclear to me if that's actually related. I'll take a look at the Virtual KMS driver as well as try to test with a real GPU.

[maxnet]

Recall you need to start with -dbg to see the backtrace which could give a clue which command gives an error.

[coredump4]

With -dbg, I see the "Welcome to the x11vnc crash shell" message following "caught X11 error," but nothing else that points to a problem.

[coredump4]

I've now been successful testing on a host with a GPU and the proprietary Nvidia driver. I will need a solution for headless non-GPU systems too, but this is exciting! Thanks for all your work.

[coredump4]

Looks like I'd assumed too much about RANDR support in the X dummy driver. Per this message, it looks like dummy lacks XRRSetScreenSize. That post is a few years old, but nobody's done much with dummy since then either. I will change gears and look at Xvfb instead.

[coredump4]

Yep, I'll look at Virtual KMS too, thanks for that. I've confirmed that Xvfb v1.20.1 has the RANDR extension, but I'll have to test to see if it's fully-functional.

[coredump4]

The minimum kernel level for VKMS is 4.19, but my environment is currently based on CentOS 7 (kernel 3.10.0). I'll try to stand up something newer to test VKMS when I get some cycles.

[sabrehagen]

@coredump4 Your work is greatly appreciated, please continue on this! :pray:

[Fuseteam]

Oh this seems to be the issue encountered, what blocks this?

[bk138]

Lack of time due to 👶care intensified due to 👑. Will tackle this once the pandemic situtation has settled here.

[GlassedSilver]

An app I use uses x11vnc as middleware, is there any update on this? :)

[tomty89]

AFAIK it would require x11vnc to create and add mode, something like this but through a programmatic interface (assuming that exists):

xrandr --newmode 1920x1080 0 1920 0 0 0 1080 0 0 0
xrandr --addmode screen 1920x1080

and it would probably be much harder (if possible at all) implement the support for the Xorg (as opposed to Xvfb) case.

(EDIT: what's worse is that Xvfb screen size is bound by its initial dimension, meaning that you can't add a mode latter that is wider and/or taller than the size.)

I haven't really checked how exactly Xvnc (i.e. TigerVNC) implemented it, but it might be worth mentioning that it uses its own X server implementation instead of Xvfb. (Well, AFAICT.)