Accessing :0 like x11vnc about turbovnc HOT 9 CLOSED

No. I recommend that people use x11vnc if they need to do that. Recent versions of libvncserver (upon which x11vnc is based) contain the TurboVNC encoder, so that solution is probably as fast as anything I could design (at least on a LAN. It won't be as fast as TurboVNC on a slow network, because libvncserver lacks the RFB flow control extensions.) No sense in reinventing the wheel. Accessing a real X server using VNC is not an easy problem (it will become astronomically easier under Wayland, once that technology becomes commonplace.)

I also question the general necessity of accessing the root X server with VNC. It's been my experience that there are basically three reasons why someone would want to do that:

• Hardware-accelerated 3D. But most screen-scraping remote display solutions targeted at physical X displays don't really support that very well (if at all.) Furthermore, VirtualGL gives you the ability to access hardware-accelerated 3D from within the TurboVNC virtual X server.
• Starting an application at work and accessing it from home. I certainly appreciate that use case, but it is somewhat out-of-scope for TurboVNC. The driver behind TurboVNC's development (and thus what determines which features we focus on and which we don't) is large-scale enterprise multi-user remote desktop deployments, mostly dealing with high-end 3D applications. Furthermore, if the application you're trying to access from home is a 3D application, it might still require VirtualGL in order to display properly in a screen scraping environment.
• Remote display of the root desktop in a virtual machine. There isn't really a reason for this unless you're running Windows as the guest O/S and using some sort of GPU virtualization technology (which would make the GPU appear as a physical GPU in the virtual machine guest.) In that case, use the UltraVNC Server in the guest. Otherwise, for Linux guests, I struggle to imagine why anyone would want to virtualize applications in this manner rather than to simply run TurboVNC and VirtualGL on the Linux host.

from turbovnc.

Thanks for the info.

The main reason for looking into this is to support the few applications that only run on real X11. For example, TeamViewer 11 will display but won't sign in when displayed on VNC; it requires a real X11 desktop that it can serve.

from turbovnc.

Why would you need to run TeamViewer in VNC? TurboVNC already has built-in collaboration features.

from turbovnc.

But if you absolutely need to run that, I'm sure there is a way to make it run inside of TurboVNC. I would just need to understand exactly what it is looking for-- that is, what parameter it is examining to determine whether or not it's running on a local display.

from turbovnc.

I use both products. Each has its own strengths.

I don't know what the issue is with TeamViewer not running under TurboVNC.

from turbovnc.

Do they have a demo version? I could poke around. I doubt that the fix would be very complicated. They're probably just doing something stupid like looking for a particular X vendor string.

from turbovnc.

TeamViewer is free for personal use
http://www.teamviewer.com/en-us/download/linux/

I think it is also available via PPA repo, RPM and Yum

from turbovnc.

You're right. TeamViewer in a VNC session is well and truly broken. GUI buttons don't work, it complains about being unable to connect, etc. No idea why simply running it in an X proxy would cause it to behave that way. I tried to run it in a VNC session that was assigned display :0, and no such luck. So apparently it isn't the display number that's tripping it up. I tried running it in TigerVNC, then running it in TurboVNC with VirtualGL, on the off chance that the lack of a GLX extension was tripping it up. Also no luck. I tried using the new NV-CONTROL emulator in TurboVNC 2.1, on the off chance that TV was making use of that extension. No luck. I also tried running it in Xvfb, which should by all rights be as close as you can get to the "real" X server. No luck. It simply doesn't like X proxies, period. There may be a design reason behind that, but I can't imagine what it would be. I can run other screen scrapers (including x11vnc) inside of a TurboVNC session with no problems, so the relevant extensions (XFIXES, XTEST, etc.) apparently work. I don't have time to look into it further at the moment, but if you stumble upon any clues that might help understand what this application is expecting, please add them here.

from turbovnc.

Wow, you really dug into this. Thanks!

from turbovnc.