On 5/17/10 12:18 PM, Peter Åstrand wrote:
Per my previous message, there are a lot of additional components
required, not just MinGW. We'd have to distribute the necessary MSYS
components as well.
MSYS is a part of the MinGW project; not a big problem.
In total, this would amount to
, Pierre Ossman wrote:
On Wed, 28 Apr 2010 14:53:10 -0500
DRC dcomman...@users.sourceforge.net wrote:
I believe that the behavior should be as follows:
-- A mechanism other than PKG_CHECK_MODULES should be used to detect the
presence of GNU TLS (AC_CHECK_LIB or AC_CHECK_HEADER, probably
Martin wrote:
On 04/29/2010 05:59 AM, DRC wrote:
Yes, in the trunk.
Good.
Do you use MinGW on Windows or as a cross compiler on some other platform?
I'm new to mingw (and using it as cross compiler), so I dont really know
how to proceed past:
cd tigervnc/trunk/win
Any more pointers
I don't know if the X server build in general is supposed to work on
non-GCC compilers, but -Wl would certainly fail on anything but GCC, so
I am not comfortable introducing that incompatibility unless the
incompatibility already exists.
It would definitely fail on OS X, but I think there are
, which is installed with XCode.
DRC
--
___
Tigervnc-devel mailing list
Tigervnc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
On 4/27/10 3:07 PM, Alan Coopersmith wrote:
It would definitely fail on OS X, but I think there are probably 50
other things in the Xvnc build that would fail first. :) The more
relevant question is whether it will fail on Solaris, and I think the
answer is yes there as well.
Whether it
...@piments.com wrote:
On 03/04/10 10:06, DRC wrote:
ti...@piments.com wrote:
On 03/03/10 22:31, DRC wrote:
ti...@piments.com wrote:
VNC context:
All tiger vnc software is run on the remote kubuntu box
via ssh
from
local linux system.
r...@local# ssh -C -X -L 5900
}
where n is the display number of the VNC server, e.g.
http://myvncserver:5801
Ruben Kerkhof wrote:
On Wed, Mar 3, 2010 at 01:40, DRC dcomman...@users.sourceforge.net wrote:
Ruben Kerkhof wrote:
I'm afraid the Java stuff isn't properly maintained as it is, so adding
another build system
ti...@piments.com wrote:
VNC context:
All tiger vnc software is run on the remote kubuntu box via ssh from
local linux system.
r...@local# ssh -C -X -L 5900:localhost:5900 remote.dyndns.info
r...@remote:~# vncviewer localhost:0
I'm wondering whether running this way
Pierre Ossman wrote:
Note that the 1.0.0 release did not have SIMD acceleration for x86_64,
so you might want to try checking out a copy from svn. Or building it
on a 32-bit machine.
It's not necessary to build on a 32-bit machine. You can simply do:
configure --host i686-pc-linux-gnu
this at a programmatic level
without exposing the environment variables, but I don't know of a way to
do that.
DRC wrote:
That's exactly the point. This is an undocumented interface used for
forcing the MMX and SSE code paths on an SSE2-capable system so I can
verify the performance
ti...@piments.com wrote:
Thanks ,
I pulled trunk but it does not seem to have all the configure and make
files . I could just copy them across one at a time from 1.0.0 but how
should I get the proper build structure? What am I missing?
autoreconf -fiv
generates the configure scripts.
I will look at it right now. I think we can back out 3958 now, because
I have the SourceForge project online for libjpeg-turbo, and thus I
don't need to build a shared version of libjpeg/SIMD out of the TigerVNC
repository anymore.
Adam Tkac wrote:
Hi all,
after r3958 I'm unable to build
forestall the need to purchase new hardware.
DRC
DRC wrote:
A developer contacted me wanting to build libjpeg/SIMD as a shared
library and install it in place of the system libjpeg. I don't
understand enough about autotools to know how to modify configure.ac or
Makefile.am in such a way
Antoine Martin wrote:
So I tried to install libtool version 2 in /usr/local whilst keeping 1
in /usr:
make[3]: Entering directory `/usr/src/tigervnc-1.0.0/common/os'
/bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I.
-I.. -DHAVE_COMMON_CONFIG_H -g -O2 -Wall -MT print.lo
I would tend to agree. Also, we're going to start building with MinGW
at some point in the not-so-distant future.
Pierre Ossman wrote:
I'd prefer if this was backed out. As I said, this just hides the
obvious unicode handling errors without actually verifying that the
rest of the code can
I regularly build on CentOS 4, which has autoconf 2.59 and automake
1.9.2. I haven't tried earlier versions, but I don't expect it to work.
Bengt-Arne Fjellner wrote:
I managed to download the source from svn but how do I create the
configure scripts? Which version of autotools is needed?
.
Pierre Ossman wrote:
On Thu, 08 Oct 2009 12:32:15 -0500
DRC dcomman...@users.sourceforge.net wrote:
I want to start putting together packages for all platforms, including
Ubuntu, but I need to know where I can check in the relevant build scripts.
I have no strong opinions
/Developer/SDKs/MacOSX10.4u.sdk -mmacosx-version-min=10.4 -m32'
CPPFLAGS='-isysroot /Developer/SDKs/MacOSX10.4u.sdk
-mmacosx-version-min=10.4' CC=gcc-4.0 CXX=g++-4.0 CPP=cpp-4.0
DRC
Adam Tkac wrote:
On Thu, Oct 01, 2009 at 11:49:50PM -0500, DRC wrote:
I've uncovered a pretty serious problem
Adam Tkac wrote:
Hm, this is a nasty problem and finding the solution will be even nastier.
I have no experience with Xcode but I would recommend to build library
without all optimizations (disable both compiler and nasm
optimizations) and check if it is still broken.
Yep. Still broken.
At least for now, I think I've done pretty much all I can do to optimize
the JPEG codec. The latest round of optimizations in r3902 speed up the
Huffman decoder by employing some of the same techniques I employed with
the encoder, including register reduction, using a 64-bit holding
register on
2 or 3 would be my vote, with a small preference toward 3.
Adam Tkac wrote:
Hi all,
string handling is very different if you look in various parts of
code. It would be nice to start to standardize it and use unified
mechanism. I see three possible ways:
1. Use the C++ String class
2.
Yeah, VGL uses a somewhat esoteric build system based on GNU Make, so I
haven't tried to build libjpeg/SIMD using the TigerVNC dsw files. This
issue looks familiar, however, like something I probably already had to
fix when moving the code over into VGL's build system. I'll take a look
and see
Hmmm Well, upon further examination, the reason is that it's not
assembling the SIMD files and including them in the link.
Just for my own clarity, though, aren't we moving away from VC at some
point? I'm happy to fix this and make it work for the moment, if we
think we want to be able to
OK, I guess the question I'm asking is -- is it worth it to try to bring
the assembly files into the dsw/dsp projects, create custom build rules
for NASM, etc., or would it be better to just hold off until we port to
MinGW? My inclination is the latter, because I just realized I don't
actually
I have the 64-bit accelerated JPEG codec ready to check in. Are we
still freezing the trunk?
--
___
Tigervnc-devel mailing list
Tigervnc-devel@lists.sourceforge.net
We most definitely should not clear the environment. That will break a
lot of things. For instance, passing environment variables into the VNC
session is necessary when using VirtualGL and VNC in a batch queuing
environment. With current solutions (based on TurboVNC), the scheduler
will choose
Isn't that the point? You want a new session for VNC. Otherwise I'd say
this patch is wrong as it creates another DBUS (i.e. a new session
from a DBUS point of view).
You don't want a whole new user session. You only want a new X session.
You want to be able to inherit whatever is set in
Pierre Ossman wrote:
The problem is that many of the modern technologies don't really make
that distinction. For example, what happens with the ConsoleKit session
inside VNC when the user logs out the local session that ran vncserver?
I don't know enough about ConsoleKit to understand the
, 2009 at 02:02:33PM -0500, DRC wrote:
Any ideas about why I'm unable to start Xvnc with -fp
catalogue:/etc/fontpath.d? I'm in a holding pattern and can't check in
my modifications to vncserver until I can resolve that issue.
Hm, it's odd. Are you able to start distribution Xorg on F10
Pierre Ossman wrote:
I haven't kept up with this issue so this might be something that's
already been mentioned, but have you made sure you have the fixed font
installed? A default installation of a modern fedora does not include
that font. I think it's the xorg-x11-fonts-misc package that
I have seen the same symptom here as well, but not just with dbus. When
using TigerVNC with Konsole, I have observed keystrokes disappearing if
I type too fast.
Peter Åstrand wrote:
We're debugging a really strange problem with TigerVNC:s Xvnc: After
executing:
eval `dbus-launch
Tkac wrote:
On Fri, Apr 17, 2009 at 03:16:33PM -0500, DRC wrote:
I guess we're approaching this from two different angles. I'm trying to
create a version of the TigerVNC server that will run on as many
different platforms as possible. I think that is Cendio's goal as
well. So rather
Peter Åstrand wrote:
You keep saying that, but I don't understand why. I just tried
installing MinGW + MSYS + MSYS DTK on my Vista machine and now I have
the full Autotools toolchain, without Cygwin. The installation only
took a few minutes.
Hmmm... OK, so apparently I was missing the DTK
Adam Tkac wrote:
Yes, it seems fine for me. Unfortunately current vncserver script in
svn is still broken.
When you run vncserver script it creates socket called 7100 in working
directory:
$ ls -l 7100
srwxrwxr-x 1 atkac atkac 0 2009-04-15 10:57 7100
It seems there is problem somewhere
Adam Tkac wrote:
If I start without -fp parameter all works fine. Btw newer Xorg
doesn't use xfs nor standard /usr/share/X11/fonts directory and
friends.
commit r3725 caused regression on all new systems. For example Xorg in
Fedora 11 handles font via font catalogue (/etc/X11/fontpath.d)
Adam Tkac wrote:
I don't think it is a good idea. Autotools might look quite strange
but they are widely used and it is known that they work fine on vast
majority of systems. You are right that compilation of Win executables
might be quite hard but if you get MinGW working it's not problem.
Well, except for that fact that it would require building TigerVNC
against OpenSSL, which has its own set of issues. Why not just set up a
separate SFTP or SSh server on the Windows server? I use the Cygwin SSh
daemon to accomplish this, but there are others that are easier to set
up. There are
We may have discussed it before the list was created, because I can't
seem to find the thread in the archives. However, IIRC, the reason was
mainly that the feature was broken and we didn't have anyone who cared
about it enough to fix it and maintain it. File transfer only exists in
the Windows
For complicated reasons that I won't go into here (but which relate my
need to build and release backward-compatible versions of VirtualGL), I
unfortunately had to downgrade my build machine to RHEL 4. This of
course broke my TigerVNC build, but it's given me a chance to see
whether or not it
What happens when you start it with no -fp parameter? Will that default
to using xfs? I'm OK with xfs being the default as long as the -fp
approach is a fallback. I can make those modifications easily.
Adam Tkac wrote:
Hi all,
commit r3725 caused regression on all new systems. For example
optimizing, as well as the interplay between the two (the latter would
bring us more in line with TurboVNC 0.5.)
In short, apart from adding 'deferUpdate 1' to vncserver, I think 3757
is ready. Pending everyone's approval, can someone make that vncserver
change and also back out 3758 and 3759?
DRC
That's a good point. Not all compilers use -O3 (for instance, that
option would cause an error on Sun Studio.) So I guess it isn't really
a good idea to modify the CFLAGS/CXXFLAGS in that manner. I will look
into changing the default for post 1.0.0. I also need to quantify
exactly how much
Peter Åstrand wrote:
Is it necessary to pass -m32 to ld? I cannot find anything in the
manpage about this. Assuming -m32 isn't necessary for ld, you can use:
make AM_CXXFLAGS=-m32 AM_CFLAGS=-m32
If ld needs it as well, there's an AM_LDFLAGS.
Since this is a generic mechanism, I'm not yet
Peter Åstrand wrote:
Regardless of which libraries we decide to use, we need to select a
decent assembler. In my opinion, NASM is a great assembler. Before we
decided to use it for SIMD/jpeg, we evaluated different options and
NASM certainly looked like the most promising solution, and I think
Could someone please verify that changes in the custom compress level
are being sent to the server? The behavior I'm observing indicates that
changing the compress level on the client has no effect on the server,
and as far as I can tell, these messages are never being sent.
Peter Åstrand wrote:
http://en.wikipedia.org/wiki/Tivoization seems to explain it quite good.
I guess that after reading this, I come down on the side of Linus.
Software licenses are not contracts, and they aren't intended to
guarantee that you can hack any hardware that the software is used
Well, I know what was going wrong. I was running Xvnc out of my home
directory, but the vncserver script was looking for Xvnc in the PATH
instead and was loading /usr/bin/Xvnc, which is from an installed copy
of RealVNC 4. Thus, it didn't have the Tight extensions and wasn't
responding to the
Are these benchmark tools distributed? If not, there's no need to upgrade
the license. If they are, perhaps it makes sense to include them in the
TigerVNC project?
They're distributed via the VirtualGL CVS repository. I'm not sure I
understand what you mean about upgrading the license.
I checked in a patch which seems to allow me to build Xvnc on RHEL 5
using the Xorg server 1.1 branch. Using this patch, I do:
git clone git://git.freedesktop.org/git/xorg/xserver xorg
cd xorg
git checkout origin/server-1_1-branch
cd ..
cp -r xorg/* xserver
cd xserver
patch -p1
For some reason, I am unable to build Xvnc on my machine (RHEL 5 64-bit)
Steps taken:
cd tigervnc/unix/
git clone git://git.freedesktop.org/git/xorg/xserver xorg
cd xorg
git checkout origin/server-1.5-branch
cp -r xorg/* xserver
cd xserver
patch -p1 ../xserver15.patch
cd xserver
./configure
As long as it can be built with autoconf 2.57, automake 1.6.3, and m4
1.4.1, then I'm fine with not having the auto-generated files in there.
Pierre Ossman wrote:
Can we please reconsider these? I'm working on removing the
filetransfer support, and the diff is becoming huge, needlessly so,
While we're asking about protocol extensions, do we want to bring up
adding the TurboVNC extensions as well? These extensions are a superset
of the existing vnc-tight extensions, so I'm not sure if the RealVNC
list would even care.
Pierre Ossman wrote:
Hi,
We've been working on client
It should work properly with cjpeg now.
Note, however, that something broke the build for me. I checked out a
clean repository and did the following:
cd tigervnc/unix
autoreconf -fiv
./configure --host i686-pc-linux-gnu --with-included-jpeg CFLAGS=-m32
CXXFLAGS=-m32 LDFLAGS=-m32
make
When
Refer to the spreadsheet I attached in the previous message. IPP is
still somewhat faster.
Karl J. Runge wrote:
For reference, how do these compare with IPP?
Karl
--
Apps built with the Adobe(R) Flex(R)
Pierre Ossman wrote:
Feel free to commit.
Do you have an optimised version for jdhuff as well?
No, I never did any optimizations to the decoder.
Fantastic news. openmlib seems to be kicking libjpeg/SIMD's ass when it
comes to grayscale data though. I'm not sure how interesting that is
PATH: /usr/lib64/qt-3.3/bin
PATH: /usr/kerberos/bin
PATH: /usr/local/bin
PATH: /bin
PATH: /usr/bin
PATH: .
PATH: /home/drc/src/vgl/linux64/bin
PATH: /home/drc/src/vgl/linux/bin
PATH: /sbin
PATH: /usr/sbin
PATH: /home/drc/bin
## --- ##
## Core tests. ##
## --- ##
configure:1981
I hate not having the feature enabled as much as you hate having it
enabled. I don't know how to make both of us happy.
To me, the potential downside of missing some critical conversation
(which often happens when people reply to someone and forget to make the
reply go to the list) far exceeds
Raw by itself is completely useless. However, using a combination of
Raw tiles and paletted tiles, both encoded using the Tight encoder, is
useful. TurboVNC 0.5 does that for its mathematically lossless modes.
What we found is that there is really no reason to use any encoder other
than the
301 - 359 of 359 matches
Mail list logo
