Re: [Tigervnc-devel] 2D vs 3D performance
On Wed, 28 Dec 2011, DRC wrote: If we start getting into such esoteric stuff as having separate launcher scripts, then why wouldn't I just create a completely different build procedure that gives me all the defaults I want? I don't understand why you think a two-line script is esoteric. The advantage of having two launch scripts instead of a customized build procedure is that only one type of binares are necessary. This also means that you can run multiple Xvnc instances with settings optimal for 2D and 3D at the same time, on the same server. Different users might use different applications or might be on different networks with different performance. Or better yet, why wouldn't I just fork the project so I wouldn't have to deal with your grief anymore? You must answer that question yourself. Rgds, --- Peter Åstrand ThinLinc Chief Developer Cendio AB http://www.cendio.com Wallenbergs gata 4 583 30 LinköpingPhone: +46-13-21 46 00-- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] 2D vs 3D performance
On Dec 28, 2011, at 10:22 AM, Peter Åstrand wrote: > On Wed, 28 Dec 2011, DRC wrote: > > > I'm pretty sure the message from Pierre was that it's not important enough to > block a new release; not that "we have a solution that fits both use cases > optimally". > > We might solve the -DeferUpdate problem, but as long as the > VirtualGL/TurboVNC standpoint is "no compromise at all", "any CPU increase is > a no-no" etc, there will be tons of issues on which we cannot find solutions > that are optimal for both cases. Without room for compromises and tradeoffs, > it's an impossible goal. "Compromise" doesn't mean you always get your way and DRC always gets shouted down. We compromised on the compression level. I conceded re-enabling the CUT on CL 2 and above and making CL 2 the default as long as there was an easy way to get back the Turbo behavior without restarting the server. However, the data supporting your case was, in my opinion, still weak there as well. It was based on quick & dirty benchmarks of two apps. That doesn't quite measure up to my lengthy reports that are the culmination of hundreds of hours of research. I refuse to be vilified for wanting to maintain the same levels of performance for 3D and video apps as TurboVNC. These apps are more performance-critical than Firefox and OpenOffice. But I'm also quite willing to try to find a solution they satisfies both types of apps. I have done this before, as one of the afore-mentioned lengthy reports describes. But you seem so insistent that there is no solution and you'd rather edge me out of the project than try to find one. > Having a special script for the ultimate-performance-on-LAN-case would > be an easy solution. Let's be clear. The difference between DeferUpdate=1 and DeferUpdate=10 is 30%, enough to effectively erase all of the hard-fought performance gains since 1.1. The performance drop affects not just LAN performance but WAN performance. My basic points all along have been that: (a) If you and Cendio have apps that you care more about than the ones I have extensively tested, then you need to develop your own low-level datasets and quantify the performance under those apps in the same way that I have for the apps I care about. Simply arguing vague points like "we can't favor LAN performance over WAN performance" or "we can't favor 3D performance over 2D performance" is useless unless you have established quantitatively that we have to favor one over the other, but you haven't. There are knobs that can be adjusted at the low level that make quite a difference with specific apps, and sometimes those knobs can be adjusted without affecting other apps too severely. (b) Never did I say that I am unwilling to compromise, but what I am unwilling to do is completely write VirtualGL users out of the picture. My only demand is that there is a Turbo-equivalent mode that is client-side configurable. If we start getting into such esoteric stuff as having separate launcher scripts, then why wouldn't I just create a completely different build procedure that gives me all the defaults I want? Or better yet, why wouldn't I just fork the project so I wouldn't have to deal with your grief anymore?-- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
[Tigervnc-devel] [ tigervnc-Bug Tracker-3466037 ] Control keys do not work in viewer
Bug Tracker item #3466037, was opened at 2011-12-27 04:46 Message generated for change (Comment added) made by You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1126848&aid=3466037&group_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: FLTK viewer Group: trunk Status: Open Resolution: None Priority: 5 Private: No Submitted By: Werner B. (werner-b) Assigned to: Pierre Ossman (ossman_) Summary: Control keys do not work in viewer Initial Comment: I found that control keys do not work in current vnc viewer (1.1.90/1.2 beta 1): (e.g. Ctrl-C in xterm (linux / mac os) or cmd.exe (windows), Ctrl-U / Ctrl-D for page up/down in vi etc.) This worked fine in tiger vnc 1.1.0 but is broken in 1.1.90. In Viewport.cxx, the function Viewport::translateKeyEvent tries to also translate control key codes which leads to some strange key symbols. I have added these 3 lines of code to Viewport.xyy line 728: } new=> // Do not try to translate control keys new=> if(strlen(keyText) == 1 && *keyText < 32) new=> return keyCode; ucs = fl_utf8decode(keyText, NULL, NULL); return ucs2keysym(ucs); } This detects control key codes and prevents UTF8 decode for control key symbols. I think this is a major issue, because you cannot remote administrate a computer via command line (e.g. in xterm) with vnc if the control keys are not working. -- Comment By: https://www.google.com/accounts () Date: 2011-12-28 12:22 Message: Here's some more info. The way I found CTRL-C and CTRL-V non-working, was when I was using a text editor, jEdit. I assume it to be the same issue that werner-b found with xterm and cmd.exe. I've tested a few other places as well, including web browser etc. It is simply not working anywhere in a TigerVNC viewer session. Other things that involve the CTRL key do work, such as CTRL-click-drag in jEdit for rectangular selection, and CTRL-printscreen for screen capture. Thanks so much for the great product, I am otherwise enjoying TigerVNC immensely. -- Comment By: https://www.google.com/accounts () Date: 2011-12-28 11:51 Message: CTRL-C and CTRL-V does not work with the beta build. I encountered this conversation just today after many months using TurboVNC which worked fine in this regard. TigerVNC does work a lot better in many regards. I'm using 1.1.90 (1.2beta1) straight from the sourceforge download page, on Ubuntu 10.04LTS 64-bit. -- Comment By: Werner B. (werner-b) Date: 2011-12-28 02:39 Message: FYI: I removed my "fix" and recompiled with USE_INCLUDED_FLTK=1. This does not help. DCommander: Can you confirm that (e.g.) Ctrl-C does not work with current beta build? -- Comment By: D. R. Commander (dcommander) Date: 2011-12-27 16:55 Message: All of my build scripts set USE_INCLUDED_FLTK=1, so that can't be the issue. -- Comment By: Pierre Ossman (ossman_) Date: 2011-12-27 05:07 Message: Sounds like something went wrong with the build. This is the behaviour of an unmodified FLTK. But we have patches that make FLTK behave more sanely with Ctrl combinations. DRC, could you double check that you didn't get the system version of FLTK? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1126848&aid=3466037&group_id=254363 -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
[Tigervnc-devel] [ tigervnc-Bug Tracker-3466037 ] Control keys do not work in viewer
Bug Tracker item #3466037, was opened at 2011-12-27 04:46 Message generated for change (Comment added) made by You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1126848&aid=3466037&group_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: FLTK viewer Group: trunk Status: Open Resolution: None Priority: 5 Private: No Submitted By: Werner B. (werner-b) Assigned to: Pierre Ossman (ossman_) Summary: Control keys do not work in viewer Initial Comment: I found that control keys do not work in current vnc viewer (1.1.90/1.2 beta 1): (e.g. Ctrl-C in xterm (linux / mac os) or cmd.exe (windows), Ctrl-U / Ctrl-D for page up/down in vi etc.) This worked fine in tiger vnc 1.1.0 but is broken in 1.1.90. In Viewport.cxx, the function Viewport::translateKeyEvent tries to also translate control key codes which leads to some strange key symbols. I have added these 3 lines of code to Viewport.xyy line 728: } new=> // Do not try to translate control keys new=> if(strlen(keyText) == 1 && *keyText < 32) new=> return keyCode; ucs = fl_utf8decode(keyText, NULL, NULL); return ucs2keysym(ucs); } This detects control key codes and prevents UTF8 decode for control key symbols. I think this is a major issue, because you cannot remote administrate a computer via command line (e.g. in xterm) with vnc if the control keys are not working. -- Comment By: https://www.google.com/accounts () Date: 2011-12-28 11:51 Message: CTRL-C and CTRL-V does not work with the beta build. I encountered this conversation just today after many months using TurboVNC which worked fine in this regard. TigerVNC does work a lot better in many regards. I'm using 1.1.90 (1.2beta1) straight from the sourceforge download page, on Ubuntu 10.04LTS 64-bit. -- Comment By: Werner B. (werner-b) Date: 2011-12-28 02:39 Message: FYI: I removed my "fix" and recompiled with USE_INCLUDED_FLTK=1. This does not help. DCommander: Can you confirm that (e.g.) Ctrl-C does not work with current beta build? -- Comment By: D. R. Commander (dcommander) Date: 2011-12-27 16:55 Message: All of my build scripts set USE_INCLUDED_FLTK=1, so that can't be the issue. -- Comment By: Pierre Ossman (ossman_) Date: 2011-12-27 05:07 Message: Sounds like something went wrong with the build. This is the behaviour of an unmodified FLTK. But we have patches that make FLTK behave more sanely with Ctrl combinations. DRC, could you double check that you didn't get the system version of FLTK? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1126848&aid=3466037&group_id=254363 -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
[Tigervnc-devel] [ tigervnc-Feature Request Tracker-3466072 ] "Real" Fullscreen Mode missing
Feature Request Tracker item #3466072, was opened at 2011-12-27 07:10 Message generated for change (Comment added) made by werner-b You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1126849&aid=3466072&group_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: FLTK viewer Group: trunk Status: Open Resolution: None Priority: 5 Private: No Submitted By: Werner B. (werner-b) Assigned to: Pierre Ossman (ossman_) Summary: "Real" Fullscreen Mode missing Initial Comment: It seems that current beta binaries (1.2 beta 1) are compiled without "-DHAVE_FLTK_FULLSCREEN=1" CMake macro. This removes the FullScreen menu entry from the F8 menu and the FullScreen menu entry in the options menu only leads to a "pseudo" fullscreen mode (full screen window, but with window borders). If there is an additional build planned, it would be nice to re-enable this feature (In tigervnc 1.1.0 this feature was also available). Thanks and Best Regards, Werner -- Comment By: Werner B. (werner-b) Date: 2011-12-28 11:24 Message: If I use the precompiled windows binaries for the vncviewer (1.2beta1) I cannot enable FLTK fullscreen because there is no menu checkbox to enable it (see screenshot Tiger-1.2beta1-binary.png). Therefore I compiled my own windows vncviewer from SVN trunk (with USE_INCLUDED_FLTK=1 or HAVE_FLTK_FULLSCREEN=1) and I got the menu checkbox to enable FLTK fullscreen (see screenshot Tiger-trunk-fullscreen.png). I use fullscreen from linux/windows to mac os. It works. Please check the F8 menu. If you have no fullscreen checkbox, something went wrong during compile... -- Comment By: D. R. Commander (dcommander) Date: 2011-12-28 07:22 Message: I guess I'm confused. Has this feature ever worked in the FLTK viewer? If so, how were you able to make it work? -- Comment By: Werner B. (werner-b) Date: 2011-12-28 02:33 Message: I recompiled with USE_INCLUDED_FLTK=1 instead of HAVE_FLTK_FULLSCREEN=1. This also enables fullscreen mode. Nevertheless the precompiled beta binaries (at least the windows binary) do not have this feature enabled... -- Comment By: Werner B. (werner-b) Date: 2011-12-28 01:42 Message: I have attached two F8 menu screenshots: Tiger-1.2beta1-binary.png shows the current 1.2beta1 vncviewer (windows binary) F8 menu, Tiger-trunk-fullscreen.png shows the F8 menu from my own compiled vncviewer (with HAVE_FLTK_FULLSCREEN). -- Comment By: D. R. Commander (dcommander) Date: 2011-12-27 16:59 Message: I assure you that the official builds are all compiled with USE_INCLUDED_FLTK=1, which should cause HAVE_FLTK_FULLSCREEN to be set automatically. I do concur, however, that full-screen doesn't work for me, and I've never been able to make it work with the 1.2 branch. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1126849&aid=3466072&group_id=254363 -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] 2D vs 3D performance
On Wed, 28 Dec 2011, DRC wrote: interest in this. Anything that, say, increases the CPU, even so little, is a no-no. Given these priorities, it seems difficult to find a solution that fits both use cases by default. Not difficult at all. We have a solution that fits both use cases by default: it's the same solution we used with 1.1.0 and are now using with 1.2 beta1, which is setting DeferUpdate to 1 ms. You and Pierre have not provided any test cases which demonstrate that 10 ms is beneficial, and Pierre admitted that the choice of that value was more of a gut instinct, which is why we changed it back until further information can be gathered. Pierre and I have reached at least a temporary agreement regarding this, so I'm not sure what you hope to gain by continuing to argue the point. I'm pretty sure the message from Pierre was that it's not important enough to block a new release; not that "we have a solution that fits both use cases optimally". We might solve the -DeferUpdate problem, but as long as the VirtualGL/TurboVNC standpoint is "no compromise at all", "any CPU increase is a no-no" etc, there will be tons of issues on which we cannot find solutions that are optimal for both cases. Without room for compromises and tradeoffs, it's an impossible goal. Having a special script for the ultimate-performance-on-LAN-case would be an easy solution. --- Peter Åstrand ThinLinc Chief Developer Cendio AB http://www.cendio.com Wallenbergs gata 4 583 30 LinköpingPhone: +46-13-21 46 00-- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] Cendio preparing for new release
On Dec 28, 2011, at 9:25 AM, Peter Åstrand wrote: >> On 12/22/11 2:41 AM, Peter Åstrand wrote: >>> I'll let Pierre give you the details of the -DeferUpdate values, but if >>> it turns out that it's not possible to find a default that fits >>> everyone, then I'm suggesting that we create a special script >>> "turbovncserver", "vglvncserver" or something like that. It can then >>> have defaults that are optimal for the 3D-on-LAN case. >> >> Except that that still requires a user to explicitly do something >> different on the server than they would normally do, and users forget to >> do that. Maybe there is no way to reconcile the differences between 2D >> and 3D apps, but we haven't really tried. I've provided tons of data >> regarding 3D and video app performance, but the equivalent data does not >> exist for 2D apps, so we really don't know what's best for those apps, >> and we can't make that judgment just based on gut feelings or quick & >> dirty benchmarks. We need something more quantifiable. > > I think we have provided quantifiable data. If you did, I never saw it. > I agree that additional tests would be useful though, but there are also > other things that needs attention. I think the core of the problem is there > will always be some kind of tradeoff/compromise, and if I understand the > VirtualGL/TurboVNC perspective correctly, there's no interest in this. > Anything that, say, increases the CPU, even so little, is a no-no. Given > these priorities, it seems difficult to find a solution that fits both use > cases by default. Not difficult at all. We have a solution that fits both use cases by default: it's the same solution we used with 1.1.0 and are now using with 1.2 beta1, which is setting DeferUpdate to 1 ms. You and Pierre have not provided any test cases which demonstrate that 10 ms is beneficial, and Pierre admitted that the choice of that value was more of a gut instinct, which is why we changed it back until further information can be gathered. Pierre and I have reached at least a temporary agreement regarding this, so I'm not sure what you hope to gain by continuing to argue the point. -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] Cendio preparing for new release
On 12/22/11 2:41 AM, Peter Åstrand wrote: I'll let Pierre give you the details of the -DeferUpdate values, but if it turns out that it's not possible to find a default that fits everyone, then I'm suggesting that we create a special script "turbovncserver", "vglvncserver" or something like that. It can then have defaults that are optimal for the 3D-on-LAN case. Except that that still requires a user to explicitly do something different on the server than they would normally do, and users forget to do that. Maybe there is no way to reconcile the differences between 2D and 3D apps, but we haven't really tried. I've provided tons of data regarding 3D and video app performance, but the equivalent data does not exist for 2D apps, so we really don't know what's best for those apps, and we can't make that judgment just based on gut feelings or quick & dirty benchmarks. We need something more quantifiable. I think we have provided quantifiable data. I agree that additional tests would be useful though, but there are also other things that needs attention. I think the core of the problem is there will always be some kind of tradeoff/compromise, and if I understand the VirtualGL/TurboVNC perspective correctly, there's no interest in this. Anything that, say, increases the CPU, even so little, is a no-no. Given these priorities, it seems difficult to find a solution that fits both use cases by default. This is why I'm suggesting a wrapper script. Assuming that you will no longer ship the file /opt/TurboVNC/bin/vncserver, users will need to learn another path/command in any case. I don't think 3D users will find it more difficult to learn to run, say, /opt/TigerVNC/bin/vncserver-vgl than /opt/TigerVNC/bin/vncserver, at least not much more difficult. Btw, wrt the latency work, we have done extensive testing, and it turns out that Pierres work gives a huge improvement. Common usage cases such as writing text in OpenOffice is now much faster on high latency links. The typing "lag" is basically gone. I don't know about that-- I certainly still see a lag when typing (I mean, latency is still latency, and the time between typing a character on the screen and seeing it on your client is still equal to RTT), but the extensions have definitely eliminated the latency-dependent update rate cap. The extensions allow you to now "type ahead" of the latency, which makes it less apparent, but I can still feel it on a 200 ms connection. Of course you can never get rid of the RTT latency; that's why I said "basically gone". What is the status of getting the extensions "officially" adopted as part of the RFB spec? As far as I can tell, all extensions have official numbers. Rgds, --- Peter Åstrand ThinLinc Chief Developer Cendio AB http://www.cendio.com Wallenbergs gata 4 583 30 LinköpingPhone: +46-13-21 46 00-- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
[Tigervnc-devel] [ tigervnc-Bug Tracker-3465459 ] about banner opens unnecesary output dialog
Bug Tracker item #3465459, was opened at 2011-12-25 11:03 Message generated for change (Comment added) made by canavan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1126848&aid=3465459&group_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: canavan (canavan) Assigned to: Adam Tkac (atkac) Summary: about banner opens unnecesary output dialog Initial Comment: The "About" banner should only be displayed if stderr is a tty, otherwise some desktop environments open unnecessary additional windows just for this message, or the console terminal is cluttered with this message. -- >Comment By: canavan (canavan) Date: 2011-12-28 07:28 Message: The Console I'm talking about is a xterm started with -C or -console. A terminal started like this receives conole output, the same that would go into ~/.xsession-errors or maybe in linux the virtual terminal X was started from (using startX). As a matter of fact, al the other messages that get logged _and_ display a dialog (e.g. "connection refused" cause the same kind of output window to open, so I'd love to get rid of those as well, while not suppressing any errors for which no dialog can be opened, e.g. for missing X11 credentials or other fatal X11 errors. -- Comment By: Peter Åstrand (astrand) Date: 2011-12-28 06:17 Message: The problem with "console terminal cluttered" will not be solved by using isatty(), since the console is a TTY. The problem with additional windows could be solved, but the problem is that some people might launch vncviewer as a subprocess but still want to include the about text in, say, a log file. We at Cendio do that, for example. So, I'm not positive to merging this patch as is. Perhaps if the code is surrounded by an IRIX ifdef. The patch also needs to be migrated to the new FLTK viewer, since the old viewer has been removed. -- Comment By: canavan (canavan) Date: 2011-12-28 04:58 Message: The IRIX "Indigo Magic Desktop" or IRIX Interactive Desktop. -- Comment By: Peter Åstrand (astrand) Date: 2011-12-28 00:02 Message: Which desktop environments opens additional windows due to this message? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1126848&aid=3465459&group_id=254363 -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
[Tigervnc-devel] [ tigervnc-Feature Request Tracker-3466072 ] "Real" Fullscreen Mode missing
Feature Request Tracker item #3466072, was opened at 2011-12-27 07:10 Message generated for change (Comment added) made by dcommander You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1126849&aid=3466072&group_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: FLTK viewer Group: trunk Status: Open Resolution: None Priority: 5 Private: No Submitted By: Werner B. (werner-b) Assigned to: Pierre Ossman (ossman_) Summary: "Real" Fullscreen Mode missing Initial Comment: It seems that current beta binaries (1.2 beta 1) are compiled without "-DHAVE_FLTK_FULLSCREEN=1" CMake macro. This removes the FullScreen menu entry from the F8 menu and the FullScreen menu entry in the options menu only leads to a "pseudo" fullscreen mode (full screen window, but with window borders). If there is an additional build planned, it would be nice to re-enable this feature (In tigervnc 1.1.0 this feature was also available). Thanks and Best Regards, Werner -- >Comment By: D. R. Commander (dcommander) Date: 2011-12-28 07:22 Message: I guess I'm confused. Has this feature ever worked in the FLTK viewer? If so, how were you able to make it work? -- Comment By: Werner B. (werner-b) Date: 2011-12-28 02:33 Message: I recompiled with USE_INCLUDED_FLTK=1 instead of HAVE_FLTK_FULLSCREEN=1. This also enables fullscreen mode. Nevertheless the precompiled beta binaries (at least the windows binary) do not have this feature enabled... -- Comment By: Werner B. (werner-b) Date: 2011-12-28 01:42 Message: I have attached two F8 menu screenshots: Tiger-1.2beta1-binary.png shows the current 1.2beta1 vncviewer (windows binary) F8 menu, Tiger-trunk-fullscreen.png shows the F8 menu from my own compiled vncviewer (with HAVE_FLTK_FULLSCREEN). -- Comment By: D. R. Commander (dcommander) Date: 2011-12-27 16:59 Message: I assure you that the official builds are all compiled with USE_INCLUDED_FLTK=1, which should cause HAVE_FLTK_FULLSCREEN to be set automatically. I do concur, however, that full-screen doesn't work for me, and I've never been able to make it work with the 1.2 branch. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1126849&aid=3466072&group_id=254363 -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
[Tigervnc-devel] [ tigervnc-Bug Tracker-3465459 ] about banner opens unnecesary output dialog
Bug Tracker item #3465459, was opened at 2011-12-25 11:03 Message generated for change (Comment added) made by astrand You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1126848&aid=3465459&group_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: canavan (canavan) Assigned to: Adam Tkac (atkac) Summary: about banner opens unnecesary output dialog Initial Comment: The "About" banner should only be displayed if stderr is a tty, otherwise some desktop environments open unnecessary additional windows just for this message, or the console terminal is cluttered with this message. -- >Comment By: Peter Åstrand (astrand) Date: 2011-12-28 06:17 Message: The problem with "console terminal cluttered" will not be solved by using isatty(), since the console is a TTY. The problem with additional windows could be solved, but the problem is that some people might launch vncviewer as a subprocess but still want to include the about text in, say, a log file. We at Cendio do that, for example. So, I'm not positive to merging this patch as is. Perhaps if the code is surrounded by an IRIX ifdef. The patch also needs to be migrated to the new FLTK viewer, since the old viewer has been removed. -- Comment By: canavan (canavan) Date: 2011-12-28 04:58 Message: The IRIX "Indigo Magic Desktop" or IRIX Interactive Desktop. -- Comment By: Peter Åstrand (astrand) Date: 2011-12-28 00:02 Message: Which desktop environments opens additional windows due to this message? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1126848&aid=3465459&group_id=254363 -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
[Tigervnc-devel] [ tigervnc-Bug Tracker-3465459 ] about banner opens unnecesary output dialog
Bug Tracker item #3465459, was opened at 2011-12-25 11:03 Message generated for change (Comment added) made by canavan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1126848&aid=3465459&group_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: canavan (canavan) Assigned to: Adam Tkac (atkac) Summary: about banner opens unnecesary output dialog Initial Comment: The "About" banner should only be displayed if stderr is a tty, otherwise some desktop environments open unnecessary additional windows just for this message, or the console terminal is cluttered with this message. -- Comment By: canavan (canavan) Date: 2011-12-28 04:58 Message: The IRIX "Indigo Magic Desktop" or IRIX Interactive Desktop. -- Comment By: Peter Åstrand (astrand) Date: 2011-12-28 00:02 Message: Which desktop environments opens additional windows due to this message? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1126848&aid=3465459&group_id=254363 -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
[Tigervnc-devel] [ tigervnc-Bug Tracker-3466037 ] Control keys do not work in viewer
Bug Tracker item #3466037, was opened at 2011-12-27 04:46 Message generated for change (Comment added) made by werner-b You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1126848&aid=3466037&group_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: FLTK viewer Group: trunk Status: Open Resolution: None Priority: 5 Private: No Submitted By: Werner B. (werner-b) Assigned to: Pierre Ossman (ossman_) Summary: Control keys do not work in viewer Initial Comment: I found that control keys do not work in current vnc viewer (1.1.90/1.2 beta 1): (e.g. Ctrl-C in xterm (linux / mac os) or cmd.exe (windows), Ctrl-U / Ctrl-D for page up/down in vi etc.) This worked fine in tiger vnc 1.1.0 but is broken in 1.1.90. In Viewport.cxx, the function Viewport::translateKeyEvent tries to also translate control key codes which leads to some strange key symbols. I have added these 3 lines of code to Viewport.xyy line 728: } new=> // Do not try to translate control keys new=> if(strlen(keyText) == 1 && *keyText < 32) new=> return keyCode; ucs = fl_utf8decode(keyText, NULL, NULL); return ucs2keysym(ucs); } This detects control key codes and prevents UTF8 decode for control key symbols. I think this is a major issue, because you cannot remote administrate a computer via command line (e.g. in xterm) with vnc if the control keys are not working. -- >Comment By: Werner B. (werner-b) Date: 2011-12-28 02:39 Message: FYI: I removed my "fix" and recompiled with USE_INCLUDED_FLTK=1. This does not help. DCommander: Can you confirm that (e.g.) Ctrl-C does not work with current beta build? -- Comment By: D. R. Commander (dcommander) Date: 2011-12-27 16:55 Message: All of my build scripts set USE_INCLUDED_FLTK=1, so that can't be the issue. -- Comment By: Pierre Ossman (ossman_) Date: 2011-12-27 05:07 Message: Sounds like something went wrong with the build. This is the behaviour of an unmodified FLTK. But we have patches that make FLTK behave more sanely with Ctrl combinations. DRC, could you double check that you didn't get the system version of FLTK? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1126848&aid=3466037&group_id=254363 -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
[Tigervnc-devel] [ tigervnc-Feature Request Tracker-3466072 ] "Real" Fullscreen Mode missing
Feature Request Tracker item #3466072, was opened at 2011-12-27 07:10 Message generated for change (Comment added) made by werner-b You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1126849&aid=3466072&group_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: FLTK viewer Group: trunk Status: Open Resolution: None Priority: 5 Private: No Submitted By: Werner B. (werner-b) Assigned to: Pierre Ossman (ossman_) Summary: "Real" Fullscreen Mode missing Initial Comment: It seems that current beta binaries (1.2 beta 1) are compiled without "-DHAVE_FLTK_FULLSCREEN=1" CMake macro. This removes the FullScreen menu entry from the F8 menu and the FullScreen menu entry in the options menu only leads to a "pseudo" fullscreen mode (full screen window, but with window borders). If there is an additional build planned, it would be nice to re-enable this feature (In tigervnc 1.1.0 this feature was also available). Thanks and Best Regards, Werner -- >Comment By: Werner B. (werner-b) Date: 2011-12-28 02:33 Message: I recompiled with USE_INCLUDED_FLTK=1 instead of HAVE_FLTK_FULLSCREEN=1. This also enables fullscreen mode. Nevertheless the precompiled beta binaries (at least the windows binary) do not have this feature enabled... -- Comment By: Werner B. (werner-b) Date: 2011-12-28 01:42 Message: I have attached two F8 menu screenshots: Tiger-1.2beta1-binary.png shows the current 1.2beta1 vncviewer (windows binary) F8 menu, Tiger-trunk-fullscreen.png shows the F8 menu from my own compiled vncviewer (with HAVE_FLTK_FULLSCREEN). -- Comment By: D. R. Commander (dcommander) Date: 2011-12-27 16:59 Message: I assure you that the official builds are all compiled with USE_INCLUDED_FLTK=1, which should cause HAVE_FLTK_FULLSCREEN to be set automatically. I do concur, however, that full-screen doesn't work for me, and I've never been able to make it work with the 1.2 branch. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1126849&aid=3466072&group_id=254363 -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
[Tigervnc-devel] [ tigervnc-Feature Request Tracker-3466072 ] "Real" Fullscreen Mode missing
Feature Request Tracker item #3466072, was opened at 2011-12-27 07:10 Message generated for change (Comment added) made by werner-b You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1126849&aid=3466072&group_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: FLTK viewer Group: trunk Status: Open Resolution: None Priority: 5 Private: No Submitted By: Werner B. (werner-b) Assigned to: Pierre Ossman (ossman_) Summary: "Real" Fullscreen Mode missing Initial Comment: It seems that current beta binaries (1.2 beta 1) are compiled without "-DHAVE_FLTK_FULLSCREEN=1" CMake macro. This removes the FullScreen menu entry from the F8 menu and the FullScreen menu entry in the options menu only leads to a "pseudo" fullscreen mode (full screen window, but with window borders). If there is an additional build planned, it would be nice to re-enable this feature (In tigervnc 1.1.0 this feature was also available). Thanks and Best Regards, Werner -- Comment By: Werner B. (werner-b) Date: 2011-12-28 01:42 Message: I have attached two F8 menu screenshots: Tiger-1.2beta1-binary.png shows the current 1.2beta1 vncviewer (windows binary) F8 menu, Tiger-trunk-fullscreen.png shows the F8 menu from my own compiled vncviewer (with HAVE_FLTK_FULLSCREEN). -- Comment By: D. R. Commander (dcommander) Date: 2011-12-27 16:59 Message: I assure you that the official builds are all compiled with USE_INCLUDED_FLTK=1, which should cause HAVE_FLTK_FULLSCREEN to be set automatically. I do concur, however, that full-screen doesn't work for me, and I've never been able to make it work with the 1.2 branch. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1126849&aid=3466072&group_id=254363 -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
[Tigervnc-devel] [ tigervnc-Bug Tracker-3465459 ] about banner opens unnecesary output dialog
Bug Tracker item #3465459, was opened at 2011-12-25 11:03 Message generated for change (Comment added) made by astrand You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1126848&aid=3465459&group_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: canavan (canavan) Assigned to: Adam Tkac (atkac) Summary: about banner opens unnecesary output dialog Initial Comment: The "About" banner should only be displayed if stderr is a tty, otherwise some desktop environments open unnecessary additional windows just for this message, or the console terminal is cluttered with this message. -- >Comment By: Peter Åstrand (astrand) Date: 2011-12-28 00:02 Message: Which desktop environments opens additional windows due to this message? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1126848&aid=3465459&group_id=254363 -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
[Tigervnc-devel] [ tigervnc-Bug Tracker-3465458 ] Badmatch crash in ServerDialog.h
Bug Tracker item #3465458, was opened at 2011-12-25 10:57
Message generated for change (Comment added) made by astrand
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=1126848&aid=3465458&group_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: canavan (canavan)
Assigned to: Adam Tkac (atkac)
Summary: Badmatch crash in ServerDialog.h
Initial Comment:
takeFocus() attemts to get the focus even if the window is not mapped. This
causes a crash when the server selection dialog is iconified and receives the
focus. This is 100% reproducable with MWM or 4DWM. This can be avoided by
checking if the window is visible (patch below) or, as qt does in
qapplication_x11.cpp, by using an XSetErrorHandler() that just ignores
BadMatches from XSetInputFocus() calls, e.g. iif (err->error_code == BadMatch
&& err->request_code == 42 /* X_SetInputFocus */) {return 0;}
The error message when crashing is:
X Error of failed request: BadMatch (invalid parameter attributes)
Major opcode of failed request: 42 (X_SetInputFocus)
Serial number of failed request: 527
Current serial number in output stream: 527
--
>Comment By: Peter Åstrand (astrand)
Date: 2011-12-28 00:00
Message:
Thanks for the patch. However, we are migrating to the new FLTK based
vncviewer, so I'm not sure how useful it is to change the legacy viewer. It
has been removed from trunk.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=1126848&aid=3465458&group_id=254363
--
Write once. Port to many.
Get the SDK and tools to simplify cross-platform app development. Create
new or port existing apps to sell to consumers worldwide. Explore the
Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
http://p.sf.net/sfu/intel-appdev
___
Tigervnc-devel mailing list
Tigervnc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
