On Fri, 28 Jun 2013, Christian Steinle wrote:

Dear TigerVNC developers,

when I had to update the X-Server in combination with the loadable TigerVNC module in our OS, I was surprised that I had to have still two separate build procedures due to the requirements in the configure options. Maybe I missed some issues requiring that procedure. Nevertheless I spent for that reason some time to completely integrate the TigerVNC 1.2.90 build process of the VNC module into the build process of the X-Server 1.10.1. So the attached patches xserver.patch and build.patch might be interesting for the community, because they simply add the configure option --enable-xvnc to the X-Server, which enables the generation of VNC without the need for other configure options likes --disable-dri, etc. Consequentially I can fetch the sources of the X-Server, the sources of TigerVNC into xserver/hw/vnc and directly compile the X-Server as well as the loadable VNC module.

Maybe there could be also the possibility that the X-Server community accepts the modifications in their maintained files, because nothing is broken, if the directory xserver/hw/vnc does not exist, and XVNC is analog to XNEST, XVFB and so on.

I understand your use case, but I believe it is somewhat unusual that you want to build the Xserver as well as Xvnc from the same source. Linux distributions, for example, have separate packages for the normal Xserver and Xvnc/vnc.so. For a casual Xvnc builder, it will just make things more complicated when you have to specify --enable-xvnc.

If upstream Xorg would accept a generic VNC patch that could be interesting, but in that case we probably need to remove references to "tigervnc".

Having to apply a patch to the Xserver before building Xvnc/vnc.so is not necessarily a bad thing. From time to time, the patch might be small, but it gives us an oppurtunity to change certain aspects, when necessary. For example, if you take a look at xserver114.patch you will see that we are also modifying "WaitForSomething". But of course, if we can minimize the number of things we need to change, compared to upstream, that is good.

Regards, ---
Peter Åstrand           ThinLinc Chief Developer
Cendio AB               http://cendio.com
Teknikringen 8          http://twitter.com/ThinLinc
583 30 Linköping        http://facebook.com/ThinLinc
Phone: +46-13-214600    http://plus.google.com/112509906846170010689
This SF.net email is sponsored by Windows:

Build for Windows Store.

Tigervnc-devel mailing list

Reply via email to