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 it
On Fri, Mar 13, 2009 at 01:23:14PM -0500, DRC wrote:
> Are you two testing it differently? I can confirm that the cjpeg
> utility is broken, but the encoder should work fine when used with
> TigerVNC. The difference is that cjpeg uses disk-based encoding rather
> than memory-based encoding. One
Are you two testing it differently? I can confirm that the cjpeg
utility is broken, but the encoder should work fine when used with
TigerVNC. The difference is that cjpeg uses disk-based encoding rather
than memory-based encoding. One of the optimizations I made to jchuff.c
was to prevent it fro
On Fri, Mar 13, 2009 at 06:15:39PM +0100, Pierre Ossman wrote:
> The new huffman code seems to be broken in some way. I get corruption
> and lots of noise about corruption and premature end of data.
>
> Did you do a test run after you had merged the code?
>
Interesting. I tested that code on 64b
On Fri, 13 Mar 2009 11:37:18 -0500
DRC wrote:
> 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.
>
We nee
The new huffman code seems to be broken in some way. I get corruption
and lots of noise about corruption and premature end of data.
Did you do a test run after you had merged the code?
Rgds
--
Pierre OssmanOpenSource-based Thin Client Technology
System Developer Telephone: +4
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 init
I think having it compilable with RHEL 5 Java compilers is a desirable
option but not critical. I've been actively developing the Java client
for years using Sun's Java compiler, which is free and open source.
I have volunteered to maintain the Java code, so I'll look into this,
but most likely n
On Fri, 13 Mar 2009 12:29:10 +0100
Adam Tkac wrote:
> On Fri, Mar 13, 2009 at 05:51:54AM -0500, DRC wrote:
> > 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.
>
> Let me try tune configure.ac & Make
fre 2009-03-13 klockan 11:45 +0100 skrev Adam Tkac:
> On Fri, Mar 13, 2009 at 10:07:12AM +0100, Pierre Ossman wrote:
> > On Wed, 4 Mar 2009 13:50:36 +0100
> > Pierre Ossman wrote:
> >
> > > It seems like the java client was last rebuilt in 2006. I propose
> > > nuking the checked in copy, along w
Hi,
We've been working on client initiated screen size changes and need to
extend the protocol to do that.
In order to minimise the number of extensions, we'd also like to
accommodate multi-head configurations with this new protocol.
So we'd like your feedback on the protocol, and allocation of
On Fri, 13 Mar 2009 11:45:12 +0100
Adam Tkac wrote:
>
> If we start porting to newer compilers I propose to switch to GCJ
> as a default compiler because we already have GCC as our default
> C/C++ compiler. Do you have any comment?
>
I have no preferences either way.
Rgds
--
Pierre Ossman
On Fri, Mar 13, 2009 at 05:51:54AM -0500, DRC wrote:
> 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.
Let me try tune configure.ac & Makefile.am. Btw which version of
gettext are you using?
> Pierre O
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,
> b
On Fri, Mar 13, 2009 at 10:07:12AM +0100, Pierre Ossman wrote:
> On Wed, 4 Mar 2009 13:50:36 +0100
> Pierre Ossman wrote:
>
> > It seems like the java client was last rebuilt in 2006. I propose
> > nuking the checked in copy, along with the RealVNC gif in the same
> > directory as there is no ref
On Wed, 11 Mar 2009 09:23:18 +0100
Adam Tkac wrote:
> On Wed, Mar 11, 2009 at 09:03:20AM +0100, Peter Åstrand wrote:
> > On Wed, 11 Mar 2009, Adam Tkac wrote:
> >
> >>> However, I'm not proposing for TigerVNC to do either of the above. I
> >>> just want to use a version of automake/autoconf that
On Fri, 13 Mar 2009, Adam Tkac wrote:
Then there's the question of if we should keep or remove
miInitializeBackingStore(). I suggest that we try to stay as close as
possible to Xvfb; this means keep miInitializeBackingStore().
It's not only "as close as possible to Xvfb" reason. If I read code
On Wed, 4 Mar 2009 13:50:36 +0100
Pierre Ossman wrote:
> It seems like the java client was last rebuilt in 2006. I propose
> nuking the checked in copy, along with the RealVNC gif in the same
> directory as there is no reference to it in the existing Java code.
>
It's now gone.
--
Pierre Ossm
On Fri, Mar 13, 2009 at 08:55:57AM +0100, Peter Åstrand wrote:
> On Thu, 12 Mar 2009, Peter Åstrand wrote:
>
My primary objective is to make sure Xvnc in TigerVNC can properly run
KDE4. The easy solution is to simply remove
"pScreen->backingStoreSupport=Always", but I'd like to know
On Wed, 11 Mar 2009 10:11:28 +0100
Pierre Ossman wrote:
> On Wed, 11 Mar 2009 11:46:56 +0600
> Constantin Kaplinsky wrote:
>
> >
> > If you plan to release the Windows version as well, please remove
> > implementation of file transfers. The version of file transfers in the
> > TigerVNC code ba
On Thu, 12 Mar 2009, Peter Åstrand wrote:
My primary objective is to make sure Xvnc in TigerVNC can properly run
KDE4. The easy solution is to simply remove
"pScreen->backingStoreSupport=Always", but I'd like to know if this is
the "correct" way of doing it. Of course, it will still crash if "+b
21 matches
Mail list logo
