[Tigervnc-devel] building non legacy sketchy-guide patch for BUILDING.txt
Hi dev team, It would be helpful if the BUILDING.txt file provides a starting point to build non legacy Xvnc. The attached patch illustrates what I have in mind. Those steps work for me. Marc Weber building-non-legacy-sketchy-guide.patch Description: Binary data -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
[Tigervnc-devel] [ tigervnc-Bug Tracker-3305357 ] Enabling custom compression level on client crashes server
Bug Tracker item #3305357, was opened at 2011-05-20 18:00 Message generated for change (Comment added) made by dcommander You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1126848aid=3305357group_id=254363 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: UN*X version Group: 1.1.X Status: Open Resolution: None Priority: 5 Private: No Submitted By: Brian Hinz (bphinz) Assigned to: Adam Tkac (atkac) Summary: Enabling custom compression level on client crashes server Initial Comment: Enabling custom compression causes the server to crash with the following log message: Fri May 20 18:39:07 2011 VNCSConnST: Client pixel format depth 24 (32bpp) little-endian rgb888 Fri May 20 18:40:11 2011 Connections: closed: 10.1.1.20::42053 (ZlibOutStream: deflate failed) SMsgWriter: framebuffer updates 148 SMsgWriter:copyRect rects 43, bytes 688 SMsgWriter:Tight rects 592, bytes 311570 SMsgWriter:raw bytes equivalent 18822164, compression ratio 60.410707 Segmentation fault Tried from both java and Windows exe. Tried DRC's latest nightly build as well as r4428 (1_1 branch) built on RHEL4. -- Comment By: D. R. Commander (dcommander) Date: 2011-08-02 21:43 Message: Let's focus on the 1.1 branch right now to avoid confusion. Do you still observe the crash using the 7/23 1.1 post-beta? When I use that build, I definitely do observe a crash when setting compress level=1-4, and the error message in the server's log is identical to the one that the encoder gives me when running at the low level. Nothing has changed in the 1.1 branch between 6/14 and 7/23 that would account for this. I also observe the crash in 6/14, but oddly, it is harder to reproduce in that build. 7/23 fails almost instantly, whereas I had to play with the 6/14 build for a while to make it fail. -- Comment By: Brian Hinz (bphinz) Date: 2011-08-02 21:16 Message: OK, I was using one of your older (June 14) pre-release builds. With the latest pre-alpha it crashes even just going to 1. -- Comment By: D. R. Commander (dcommander) Date: 2011-08-02 20:59 Message: How are you building TigerVNC? It is definitely reproducible in my builds. -- Comment By: D. R. Commander (dcommander) Date: 2011-08-02 20:58 Message: It's a hidden option. 0 pipes the data through the Zlib compressor, which doesn't actually compress anything. However, 1 or any other number = 4 also produces the error. -- Comment By: Brian Hinz (bphinz) Date: 2011-08-02 20:57 Message: Correction, -1 is the default, 0 is no compression. So is there any reason to enable 0? I can't reproduce it by going between 1 and 4, it seems like it's specific to 0. -- Comment By: Brian Hinz (bphinz) Date: 2011-08-02 20:51 Message: The easiest way to repro is to set the custom level to 0, then back up to 1. You might also try disabling JPEG compression before doing that, as it seems to make it happen more readily. Should 0 be an option? I know it's actually the default, but the viewer dialog says 1= fast, 9=best. Perhaps like you say it's at a higher level and the server doesn't expect to receive anything outside the range 1-9? (I don't remember seeing anything like that). -- Comment By: D. R. Commander (dcommander) Date: 2011-08-02 20:24 Message: More information on this. In the process of mocking up the TigerVNC encoder at the lowest levels using the compare-encodings benchmark (which is used to model low-level encoder performance using captured VNC sessions), I observed that I would get an error in deflateParams() whenever setting the compression level to 4 or lower. Backing out the patch we made to attempt to fix this bug seems to make everything work fine at the low level. In short, the original ZlibOutStream implementation seems to be correct. Perhaps the bug is at a higher level of the program. -- Comment By: D. R. Commander (dcommander) Date: 2011-07-28 12:40 Message: Something else I noticed, at least in trunk, is that there still seems to be a dependency on libz.so.1 even though USE_INCLUDED_ZLIB=1. I'm investigating that. It may be that this is a conflict between the static and shared lib versions. -- Comment By: Brian Hinz (bphinz) Date: 2011-07-28 10:08 Message: Are the in-tree
[Tigervnc-devel] [ tigervnc-Bug Tracker-3305357 ] Enabling custom compression level on client crashes server
Bug Tracker item #3305357, was opened at 2011-05-20 19:00 Message generated for change (Comment added) made by bphinz You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1126848aid=3305357group_id=254363 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: UN*X version Group: 1.1.X Status: Open Resolution: None Priority: 5 Private: No Submitted By: Brian Hinz (bphinz) Assigned to: Adam Tkac (atkac) Summary: Enabling custom compression level on client crashes server Initial Comment: Enabling custom compression causes the server to crash with the following log message: Fri May 20 18:39:07 2011 VNCSConnST: Client pixel format depth 24 (32bpp) little-endian rgb888 Fri May 20 18:40:11 2011 Connections: closed: 10.1.1.20::42053 (ZlibOutStream: deflate failed) SMsgWriter: framebuffer updates 148 SMsgWriter:copyRect rects 43, bytes 688 SMsgWriter:Tight rects 592, bytes 311570 SMsgWriter:raw bytes equivalent 18822164, compression ratio 60.410707 Segmentation fault Tried from both java and Windows exe. Tried DRC's latest nightly build as well as r4428 (1_1 branch) built on RHEL4. -- Comment By: Brian Hinz (bphinz) Date: 2011-08-03 00:04 Message: Yes, I get essentially the same behavior. I'll keep poking around to see if I can make any headway with this. -- Comment By: D. R. Commander (dcommander) Date: 2011-08-02 22:43 Message: Let's focus on the 1.1 branch right now to avoid confusion. Do you still observe the crash using the 7/23 1.1 post-beta? When I use that build, I definitely do observe a crash when setting compress level=1-4, and the error message in the server's log is identical to the one that the encoder gives me when running at the low level. Nothing has changed in the 1.1 branch between 6/14 and 7/23 that would account for this. I also observe the crash in 6/14, but oddly, it is harder to reproduce in that build. 7/23 fails almost instantly, whereas I had to play with the 6/14 build for a while to make it fail. -- Comment By: Brian Hinz (bphinz) Date: 2011-08-02 22:16 Message: OK, I was using one of your older (June 14) pre-release builds. With the latest pre-alpha it crashes even just going to 1. -- Comment By: D. R. Commander (dcommander) Date: 2011-08-02 21:59 Message: How are you building TigerVNC? It is definitely reproducible in my builds. -- Comment By: D. R. Commander (dcommander) Date: 2011-08-02 21:58 Message: It's a hidden option. 0 pipes the data through the Zlib compressor, which doesn't actually compress anything. However, 1 or any other number = 4 also produces the error. -- Comment By: Brian Hinz (bphinz) Date: 2011-08-02 21:57 Message: Correction, -1 is the default, 0 is no compression. So is there any reason to enable 0? I can't reproduce it by going between 1 and 4, it seems like it's specific to 0. -- Comment By: Brian Hinz (bphinz) Date: 2011-08-02 21:51 Message: The easiest way to repro is to set the custom level to 0, then back up to 1. You might also try disabling JPEG compression before doing that, as it seems to make it happen more readily. Should 0 be an option? I know it's actually the default, but the viewer dialog says 1= fast, 9=best. Perhaps like you say it's at a higher level and the server doesn't expect to receive anything outside the range 1-9? (I don't remember seeing anything like that). -- Comment By: D. R. Commander (dcommander) Date: 2011-08-02 21:24 Message: More information on this. In the process of mocking up the TigerVNC encoder at the lowest levels using the compare-encodings benchmark (which is used to model low-level encoder performance using captured VNC sessions), I observed that I would get an error in deflateParams() whenever setting the compression level to 4 or lower. Backing out the patch we made to attempt to fix this bug seems to make everything work fine at the low level. In short, the original ZlibOutStream implementation seems to be correct. Perhaps the bug is at a higher level of the program. -- Comment By: D. R. Commander (dcommander) Date: 2011-07-28 13:40 Message: Something else I noticed, at least in trunk, is that there still seems to be a dependency on libz.so.1 even though USE_INCLUDED_ZLIB=1. I'm
[Tigervnc-devel] [ tigervnc-Bug Tracker-3305357 ] Enabling custom compression level on client crashes server
Bug Tracker item #3305357, was opened at 2011-05-20 19:00 Message generated for change (Comment added) made by bphinz You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1126848aid=3305357group_id=254363 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: UN*X version Group: 1.1.X Status: Open Resolution: None Priority: 5 Private: No Submitted By: Brian Hinz (bphinz) Assigned to: Adam Tkac (atkac) Summary: Enabling custom compression level on client crashes server Initial Comment: Enabling custom compression causes the server to crash with the following log message: Fri May 20 18:39:07 2011 VNCSConnST: Client pixel format depth 24 (32bpp) little-endian rgb888 Fri May 20 18:40:11 2011 Connections: closed: 10.1.1.20::42053 (ZlibOutStream: deflate failed) SMsgWriter: framebuffer updates 148 SMsgWriter:copyRect rects 43, bytes 688 SMsgWriter:Tight rects 592, bytes 311570 SMsgWriter:raw bytes equivalent 18822164, compression ratio 60.410707 Segmentation fault Tried from both java and Windows exe. Tried DRC's latest nightly build as well as r4428 (1_1 branch) built on RHEL4. -- Comment By: Brian Hinz (bphinz) Date: 2011-08-03 00:15 Message: Looking at that patch, I think that the flush parameter in the else block of checkCompressionLevel should be Z_NO_FLUSH rather than Z_SYNC_FLUSH. It doesn't seem like that alone should cause the server to bail out though. It's probably is degrading performance though. -- Comment By: Brian Hinz (bphinz) Date: 2011-08-03 00:04 Message: Yes, I get essentially the same behavior. I'll keep poking around to see if I can make any headway with this. -- Comment By: D. R. Commander (dcommander) Date: 2011-08-02 22:43 Message: Let's focus on the 1.1 branch right now to avoid confusion. Do you still observe the crash using the 7/23 1.1 post-beta? When I use that build, I definitely do observe a crash when setting compress level=1-4, and the error message in the server's log is identical to the one that the encoder gives me when running at the low level. Nothing has changed in the 1.1 branch between 6/14 and 7/23 that would account for this. I also observe the crash in 6/14, but oddly, it is harder to reproduce in that build. 7/23 fails almost instantly, whereas I had to play with the 6/14 build for a while to make it fail. -- Comment By: Brian Hinz (bphinz) Date: 2011-08-02 22:16 Message: OK, I was using one of your older (June 14) pre-release builds. With the latest pre-alpha it crashes even just going to 1. -- Comment By: D. R. Commander (dcommander) Date: 2011-08-02 21:59 Message: How are you building TigerVNC? It is definitely reproducible in my builds. -- Comment By: D. R. Commander (dcommander) Date: 2011-08-02 21:58 Message: It's a hidden option. 0 pipes the data through the Zlib compressor, which doesn't actually compress anything. However, 1 or any other number = 4 also produces the error. -- Comment By: Brian Hinz (bphinz) Date: 2011-08-02 21:57 Message: Correction, -1 is the default, 0 is no compression. So is there any reason to enable 0? I can't reproduce it by going between 1 and 4, it seems like it's specific to 0. -- Comment By: Brian Hinz (bphinz) Date: 2011-08-02 21:51 Message: The easiest way to repro is to set the custom level to 0, then back up to 1. You might also try disabling JPEG compression before doing that, as it seems to make it happen more readily. Should 0 be an option? I know it's actually the default, but the viewer dialog says 1= fast, 9=best. Perhaps like you say it's at a higher level and the server doesn't expect to receive anything outside the range 1-9? (I don't remember seeing anything like that). -- Comment By: D. R. Commander (dcommander) Date: 2011-08-02 21:24 Message: More information on this. In the process of mocking up the TigerVNC encoder at the lowest levels using the compare-encodings benchmark (which is used to model low-level encoder performance using captured VNC sessions), I observed that I would get an error in deflateParams() whenever setting the compression level to 4 or lower. Backing out the patch we made to attempt to fix this bug seems to make everything work fine at the low level. In short, the
