On 02/03/2011 02:37 PM, Gerry Reno wrote:
On 02/03/2011 02:26 PM, John A. Sullivan III wrote:
On Thu, 2011-02-03 at 13:54 -0500, Gerry Reno wrote:
On 02/03/2011 01:38 PM, John A. Sullivan III wrote:
<snip> The only reliable solution we have seen so far is X2Go over commercial Xming. Thus, for X2Go to be production worthy for Windows users, we must either fix Xming or vcxsrv. Xming is literally antagonistic to X2Go so our best bet is vcxsrv. Let's hope the vcxsrv devs are able to fix this and we will devote whatever resources we can to work on it as well. As always, thanks - John
John, that has been our assessment as well.
We've demoed x2go to some clients and let them work with it and we definitely need to have an Xserver that is stable and reliable. And right now that is not the case. And I'm getting pushback from the clients about the mouse issue and restarts. For us xming commercial is something we're looking at but that very much muddies up things with a restrictive license. If anyone has any ideas about how to produce some meaningful debug information with either Xming or VcXsrv that could lead to helping fix these problems please share it with us. We'll be glad to help with testing.
<snip> That would be very appreciated. I think the next step is already in motion; Phil has contacted the vcxsrv devs with whom he seems to get on well. In the meantime, we can slot in the bits into the code to make it work with either X server and to call it when we have the session information as opposed to before like it is now. That will give us rootless and fullscreen capabilities. It will be even better if we can detect if there is an existing multiwindow. We need to do all that regardless of whom we ultimately use.
Alex, we would actually prefer you do that as we truly are not developers. Do you have time for that portion, i.e., not fixing vcxsrv but simply changing the X2Go Client code? If, not, we'll take our best stab at it.
Gerry, if we find the vcxsrv folks are not able to get to this right away, do you have anyone with X skills who could troubleshoot and fix it? That's way out of our league. Thanks, all - John
John, if I did we'd have fixed it already. :-)
X is not within our skill sets.
General question, is it possible to build a debug version of X? Can X be run under the control of a debugger? If so, maybe breakpoints could be set until we narrowed down the section of code causing the problem or maybe we could tell where it was from a core file. Just some thoughts.
Regards, Gerry
I just looked at all the various mouse/keyboard issues that we've seen w/X and window managers.
Multiple doodads... (had to restart X) Tried to focus the nofocus window (had to restart X) XID collision. Trouble ahead. (had to restart X) unknown keypress (translated set 2, code 0xd9 on SERIAL) ... mouse pointer disappears but still works (had to restart X) mouse pointer zooms offscreen (had to restart X) dropdown menues stop working on mouse click (gnome-terminal) (had to restart X) keystrokes fail in gnome-terminal - cursor turns to outlined block (had to restart X)
These occurred on both debian-based and redhat-based distros.
So there is plenty of room for discovery for these X issues. And some of them might ultimately be tied to the same solution. I found that some of these issues have been reported for years to Xorg and are still not solved. Of course some might be window manager issues.
Regards, Gerry