matthieu.lochegn...@altissemiconductor.com wrote on 10/11/2011 11:30:53:
> I agree with you this is very mysterious. I've tried various source RPMs
> from RedHat's site matching my version, rebuilt them: none of them uses
> the mode, only the "official" version installed on my machine does.
H
On 11/10/2011 11:30 AM, matthieu.lochegn...@altissemiconductor.com wrote:
> DRC wrote on 09/11/2011 20:28:56:
>
>> Very mysterious. Hoping someone else can shed some light on it. As far
>> as I can tell, our code never sends that pseudo-encoding. It only
>> decodes it in the viewer (same as gra
DRC wrote on 09/11/2011 20:28:56:
> Very mysterious. Hoping someone else can shed some light on it. As far
> as I can tell, our code never sends that pseudo-encoding. It only
> decodes it in the viewer (same as gradient encoding-- we decode that as
> well but never send it.)
I agree with you
On 11/9/11 1:15 PM, matthieu.lochegn...@altissemiconductor.com wrote:
> I ran into it when using Xvnc from the RHEL6 package:
> tigervnc-server-1.0.90-0.10.20100115svn3945.el6.x86_64.
> I just did what you told: I started a Xvnc with depth 16, displayed on it
> a terminal (with a window manager), a
DRC wrote on 09/11/2011 19:22:37:
> I checked in the fix, but I'm still not able to figure out how to get
> the copy filter to engage. How are you doing that? None of the
> TightVNC family of VNC servers even generates that subencoding on the
> server end. It's not in TightVNC, even as far bac
I checked in the fix, but I'm still not able to figure out how to get
the copy filter to engage. How are you doing that? None of the
TightVNC family of VNC servers even generates that subencoding on the
server end. It's not in TightVNC, even as far back as 1.0.
On 11/9/11 3:23 AM, matthieu.loc
DRC wrote on 09/11/2011 10:46:42:
> It probably needs to be w * sizeof(PIXEL_T), but I'd feel better if
> someone could test it, as apparently whatever I'm doing isn't invoking
> the copy filter (not sure how that filter is ever invoked, because I'm
> exercising all of the others by running vario
It probably needs to be w * sizeof(PIXEL_T), but I'd feel better if
someone could test it, as apparently whatever I'm doing isn't invoking
the copy filter (not sure how that filter is ever invoked, because I'm
exercising all of the others by running various programs in the Xvnc
session, moving wind
DRC wrote on 08/11/2011 19:37:33:
> Odd that valgrind didn't trap it. Perhaps the low-level datasets aren't
> ever exercising the Tight Copy filter.
Hi,
are you confident with the few lines for the Tight Copy filter, below
Pierre's fix?
Those were changed this way by commit 4763 :
On 11/8/11 9:15 AM, Pierre Ossman wrote:
> Some bad pointer management. Fixed in trunk now.
Odd that valgrind didn't trap it. Perhaps the low-level datasets aren't
ever exercising the Tight Copy filter.
--
RSA(R) Confere
On Tue, 8 Nov 2011 14:38:22 +0100
Pierre Ossman wrote:
> On Tue, 8 Nov 2011 14:33:53 +0100
> Pierre Ossman wrote:
>
> > Somewhere between r4754 and r4765 (i.e. DRC's latest optimisations),
> > the tight decoder got broken. When used with an older Xvnc, it garbles
> > the data. It's easy to repr
On Tue, 8 Nov 2011 14:33:53 +0100
Pierre Ossman wrote:
> Somewhere between r4754 and r4765 (i.e. DRC's latest optimisations),
> the tight decoder got broken. When used with an older Xvnc, it garbles
> the data. It's easy to reproduce using just gnome-terminal where most of
> the text will get mes
Somewhere between r4754 and r4765 (i.e. DRC's latest optimisations),
the tight decoder got broken. When used with an older Xvnc, it garbles
the data. It's easy to reproduce using just gnome-terminal where most of
the text will get messed up. It does not seem to be in the JPEG
decompressor as turnin
13 matches
Mail list logo
