I can happily use Xming with older versions of Fedora (and Tru64), but when testing Fedora 7, I use Xlaunch with plink.exe to start gnone-session, authentication is with Pagent, Gnome starts up, wallpaper and top/bottom panels are displayed, and for a few seconds it responds ok (menus drop, tooltips respond to mouseovers, desktp icons show highlighting on mouseover) After a few seconds xming stops responding normally, and only seems to process one event every 60 seconds or so, you can still persevere and click menu items, or hover for a long time over panel-applets to see their tooltips. When this happens windows shows xming as "Not Responding" I was using 6.9.90.23 and have now upgraded to 6.9.0.27, the issue still occurs, but only with Fedora7 machines, could this be tweaking some timing issue with Xlib over XCB changes in recent Xorg server that is in Fedora7? Anyone else? p.s. I do know I'm clutching at straws :-)
Have you got an Xming log file for this?
(In reply to comment #1) > Have you got an Xming log file for this? Installed a server with the final released FC7 and now seems ok (the server does have xen which meansit has an older kernel than a non-xen FC7 install) I will be installing a couple of other servers over the next few days, if they're OK too I suspect this bug can be closed ....
(In reply to comment #2) > Installed a server with the final released FC7 and now seems ok Oh well spoke too soon, that session lasted for a couple of hours or so and only hung once I logged out of gnome (the session was started with gnome-session from plink/xlaunch) but on the next session it "hung" a few seconds after starting up, the differences were that the server had been yum updated from the initial FC7 release to be up to date, the console was switched from running gnome with vesa driver to just being in runlevel3 and text console, and I had upgraded xming from 6.9.90.32 to 6.9.90.37 Lots of changes at once not helpful I know, but I thought it was working. When it freezes it isn't totally dead, it just pauses for 30+ seconds at a time, as the xming.exe is fullscreen no local win32 apps can re-paint until xming comes abck to life, then if you switch back to xming each X screen paint also takes 30+ seconds. What type of log file will help track this down?
(In reply to comment #3) > When it freezes it isn't totally dead OK, I'm understanding a little more about what makes this problem come and go (not much idea on the underlying cause though) If I have a gnome-terminal running, so long as it has focus the regular flashing of the cursor is /almost/ enough to keep the session alive, if I hover the mouse over other desktop items they highlight properly, or display tooltips, sometimes it freezes for about a minute but comes back to life again. But as soon as I click e.g. the gnome menu bar and allow focus to leave the terminal window the response goes very lumpy as the terminal cursor stops flashing, if I leave window running either a continual "ls -lR /" or e.g. have gnome-system-monitor running displaying it's graphs tab then the session stays alive and fairly responsive. However the amount of data being tunnelled through plink is huge, average 300Kbytes/sec over a LAN connection. If I make a similar plink/xlaunch connection to a remote ancient FC3 server it only consumes about 8Kbytes/sec to display the same gnome-system-monitor and idle gnome-terminal sessions within a desktop. So it seems to need a constant supply of data coming from the X-client into Xming's server to stop something going to sleep, if it does go to sleep it only seems to process one "event" every minute, but if you can use that slow response to start something which will generate more output it all comes back to life again. Something changed within FC7 that tickles this, I've made perfectly good connections to FC1 to FC5 and Tru64 servers with various xming (and cygwin/X) versions.
(In reply to comment #4) > OK, I'm understanding a little more I thought I'd try to eliminate the plink/SSH tunnel as a source of problems, set the server back to runlevel5 and made sure gdm was set to accept XDMCP tried a full screen xdmcp login from xlaunch, I get the gdm login screen displayed, and can enter username and password, then just get black screen and xming.exe is taking >95% CPU. pasted below is xming log file Welcome to the Xming X Server Vendor: Colin Harrison Release: 6.9.0.37 OS: Windows XP FreeType2: 2.3.4 Contact: http://sourceforge.net/forum/?group_id=156984 Xming :0 -fullscreen -query 192.168.1.169 -clipboard XdmcpRegisterConnection: newAddress 192.168.1.101 (--) 5 mouse buttons found (--) Setting autorepeat to delay=500, rate=31 (--) winConfigKeyboard - Layout: "00000452" (00000452) (EE) Keyboardlayout "United Kingdom Extended" (00000452) is unknown Could not init font path element C:\Program Files\Xming/fonts/TTF/, removing from list! Could not init font path element C:\Program Files\Xming/fonts/Type1/, removing from list! Could not init font path element C:\Program Files\Xming/fonts/75dpi/, removing from list! Could not init font path element C:\Program Files\Xming/fonts/100dpi/, removing from list! Could not init font path element C:\Program Files\Xming\fonts\cyrillic, removing from list! Could not init font path element C:\WINDOWS\Fonts, removing from list! winProcEstablishConnection - Hello winProcEstablishConnection - Xdmcp enabled, waiting to start clipboard client until fourth call. winProcEstablishConnection - Hello winProcEstablishConnection - Xdmcp enabled, waiting to start clipboard client until fourth call. winProcEstablishConnection - Hello winProcEstablishConnection - Xdmcp enabled, waiting to start clipboard client until fourth call. winProcEstablishConnection - Hello winInitClipboard () winProcEstablishConnection - winInitClipboard returned. winClipboardProc - Hello winClipboardProc - DISPLAY=127.0.0.1:0.0 winClipboardProc - XOpenDisplay () returned and successfully opened the display. winProcQueryTree - Clipboard client already launched, returning. winClipboardIOErrorHandler! winClipboardProc - setjmp returned for IO Error Handler.
(In reply to comment #5) > I thought I'd try to eliminate the plink/SSH tunnel Final update for today .. Since the XDMCP wasn't successful, I just started xming with xming :0 -fullscreen -clipboard -ac then manually logged onto the FC7 server using putty.exe then did export DISPLAY=my.xp.ip.adr:0.0 gnome-session& lo and behold a fully responsive session which nevertheless is very bandwidth hungry, taking about 175Kbyte/sec to display gnome-session-monitor's scrolling graph and over 400Kbytes/sec with an "ls -lR /"
Try without the -clipboard option
(In reply to comment #7) > Try without the -clipboard option No different unfortunately, it seems that anything which sends a trickle of screen updates keeps the session alive, if the updates stop the session only seems capable of performing one "action" per timeout period of about 30 seconds, affects every F7 box I have, regardless of connection method, seems I was wrong when I though I could work around by starting session with export DISPLAY froma putty session, I just happened to run a program that did constant screen updates.
I don't think this is a problem anymore with later versions.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.