[X2go-dev] VcXsrv

[Gerry Reno]

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