Re: WORKAROUND: Unable to load any usable iso8859 font
ThinkDifferently wrote:
My solution was, at the very least, to re-run setup.exe and to install the
package font-misc-misc. Once I did that, XWin stopped hanging and xterm
and xclock ran without a hitch.
I found this nugget of information buried deep in the
http://www.nabble.com/forum/Reply.jtp?post=21828473 Cygwin/X FAQ page ,
section 9.4, sub-item 1. To quote:
You do not have a font package which provides the default font ('fixed')
installed. This is rarely the problem; but in the event that it is the
problem, just rerun Cygwin's setup.exe, select the font-misc-misc package
and install it.
I find the phrase This is rarely the problem to be ironic, considering
that it seems to be the most common, based on what I've read.
Well, in fact, this FAQ is obsolete. The fixed font is now available built-in
to the server, so it starts even when no font packages are installed (to avoid
precisely this kind of configuration problem)
With 1.5.3-6 xserver, it should never happen that the server fails to start
could not open default font 'fixed'. (In fact, since 1.5.3-3, but there was
a bug in libXft which caused it to fail to find 'fixed' after a server restart)
The problem (lately) is that font-misc-misc is a prerequisite, but it is not
(no longer?) flagged as one by setup.exe when you choose the various xorg
packages.
The packages I installed were...
+ xauth
+ xclock
+ xcursor-themes
+ xhost
+ xinit
+ xkbcomp
+ xkeyboard-config
+ xmodmap
+ xorg-server
+ xrdb
+ xterm
None of these flagged font-misc-misc, but when I installed the font package
manually, the above packages all started working.
BUG!
Yes, there is a bug.
Installing the font-misc-misc package is a workaround.
But, no, it's not the obvious packaging error that font-misc-misc should be
in the dependencies for packages which use the 'fixed' font, as that font is
now available 'built-in' to the server and the server starts with no fonts
installed.
It seems the specific error message quoted Unable to load any usable ISO8859
font, comes from libXt [1], when it has failed to find the requested font, it
tries a fallback of -*-*-*-R-*-*-*-120-*-*-*-*-ISO8859-*, which should match
the always-available, built-in fixed font.
I have no problems starting xterm just using the built-in fonts
$ xset fp built-ins
[or start the server with -fp built-ins, or uninstall all font packages]
$ xlsfonts -fn -*-*-*-R-*-*-*-120-*-*-*-*-ISO8859-*
-misc-fixed-medium-r-semicondensed--12-120-75-75-c-0-iso8859-1
-misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso8859-1
$ xterm
[starts with no error]
So, why some people see this error is a mystery to me. The first post in this
thread seems to pin the blame on something which changed recently, possibly
xserver 1.5.3-5, but I can't reproduce it and can't see any changes which seem
likely suspects...
Entered into bugzilla
http://sourceware.org/bugzilla/show_bug.cgi?id=9839
[1] http://cgit.freedesktop.org/xorg/lib/libXt/tree/src/Converters.c
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ: http://x.cygwin.com/docs/faq/
Re: conflicting header files VendorSP.h and VendorP.h
Siegmar Gross wrote: ... if mpic++ -DHAVE_CONFIG_H -I. -I. -I. -I../../src -I/usr/X11R6/include -O -MT xmpi_misc.o -MD -MP -MF .deps/xmpi_misc.Tpo \ -c -o xmpi_misc.o `test -f 'xmpi_misc.cc' || echo './'`xmpi_misc.cc; \ then mv -f .deps/xmpi_misc.Tpo .deps/xmpi_misc.Po; \ else rm -f .deps/xmpi_misc.Tpo; exit 1; \ fi In file included from /usr/X11R6/include/Xm/XmP.h:1646, from /usr/X11R6/include/Xm/PrimitiveP.h:29, from /usr/X11R6/include/Xm/SashP.h:29, from xmpi_misc.cc:29: /usr/X11R6/include/X11/VendorP.h:87: error: previous declaration of 'VendorShellClassRec vendorShellClassRec' with 'C++' linkage /usr/X11R6/include/Xm/VendorSP.h:58: error: conflicts with new declaration with 'C' linkage mpic++: No such file or directory make[3]: *** [xmpi_misc.o] Error 1 I temporarily put the conflicting line in file /usr/X11R6/include/Xm/VendorSP.h into a comment and could finish the installation. Perhaps somebody knows how to fix the problem in the cygwin distribution. Thank you very much for a fix in one of the next distributions in advance. It seems that /usr/include/X11/VendorP.h and other libXt headers are not safe for C++ compilation. This is fixed upstream in X.Org git, but this fix has not yet made it into a release version (the current version 1.0.5) If you want to work with libXt in C++, you'll have to fix the headers to decorate them with 'extern C' as required, or perhaps use the following patch http://cgit.freedesktop.org/xorg/lib/libXt/commit/?id=6b483e355de6c5ee5dc635ab9b817bf72680b016 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: X / gtk-x11 / flicker and other problems [+PATCH]
John Emmas wrote: - Original Message - From: Jon TURNEY Subject: Re: X / gtk-x11 / flicker and other problems btw, I use -multiwindow mode all the time, but I've obviously trained myself not to see any of these artefacts lol - fair point..! But I must admit, having seen how the graphics performance can be under gtk-win32 I'd be very reluctant now to go back to x11, even though I know it must be more sensible to stick with the official backend. Here's some expansion on what I said earlier:- Bah! Now I've noticed the flickering again, so I have to fix it. Your cunning plan worked. :-) Twin monitors are a bit of a pain too, to be honest. Would you care to elaborate on this point a bit? One particular problem is that the xserver will only support twin monitors if they both have the same settings (resolution etc). I happen to use my primary monitor at 1600x1200 and my secondary monitor at 1280x1024. Running the monitors at different resolutions is a lot more common than you might realise. At one time I thought I was pretty unique but in fact, most dual-headers that I've spoken to also have their monitors at different resolutions. Hmm... I thought this worked. The only restriction should be that the colour-depth of the monitors is the same... Another problem (doesn't affect me but I think I read this somewhere) is that Cygwin's xserver isn't very hapy if the primary monitor is on the right-hand side. The internet is full of lies :-) That bug should be fixed. The way the integrated window manager works at the moment, when a window is being resized WM_SIZING is only used to enforce any window sizing constrains specified in hints, that isn't passed onto the X application to allow it to redraw itself until the mouse button is released and a WM_SIZE is sent. Yes, that ties in with what I'm observing. Interestingly I just booted up into Linux and rebuilt the same app using x11 on Linux. That gives more-or-less the same result as Cygwin-X. The window contents don't get redrawn until I either release the mouse button (or in Linux's case, stop dragging for more than about a second). Hmmm... playing around a bit more with the resize, if you grab the window frame and resize it moving the corner of the frame repeatedly around and around in circles, it's quite noticeable when the mouse button is finally released that a backlog of ConfigureWindow requests has built up and then get processed. Don't know if this indicates something is in the wrong thread, if we just need some backpressure to prevent this queue building up, but this isn't right, and needs fixing Cygwin/X: Avoid a visual glitch on window move in rootless modes Handle and ignore WM_ERASEBKGND since we repaint the entire invalidated region anyhow (this avoids a white flickering on window resize) --- xserver/hw/xwin/winmultiwindowwndproc.c |8 xserver/hw/xwin/winwin32rootlesswndproc.c | 11 +++ 2 files changed, 19 insertions(+) Index: xorg-server-1.5.3/xserver/hw/xwin/winmultiwindowwndproc.c === --- xorg-server-1.5.3.orig/xserver/hw/xwin/winmultiwindowwndproc.c 2009-02-10 21:55:54.921875000 + +++ xorg-server-1.5.3/xserver/hw/xwin/winmultiwindowwndproc.c 2009-02-11 14:11:31.34375 + @@ -468,6 +468,14 @@ HandleCustomWM_INITMENU ((unsigned long)hwnd, wParam); break; +case WM_ERASEBKGND: + /* + * Pretend that we did erase the background but we don't care, + * since we repaint the entire region anyhow + * This avoids some flickering when resizing. + */ + return TRUE; + case WM_PAINT: /* Only paint if our window handle is valid */ if (hwndScreen == NULL) Index: xorg-server-1.5.3/xserver/hw/xwin/winwin32rootlesswndproc.c === --- xorg-server-1.5.3.orig/xserver/hw/xwin/winwin32rootlesswndproc.c 2009-02-10 21:55:54.65625 + +++ xorg-server-1.5.3/xserver/hw/xwin/winwin32rootlesswndproc.c 2009-02-10 21:55:56.59375 + @@ -779,6 +779,17 @@ SendMessage (hwndScreen, message, wParam, lParam); return 0; +case WM_ERASEBKGND: +#if CYGDEBUG + winDebug (winMWExtWMWindowProc - WM_ERASEBKGND\n); +#endif + /* + * Pretend that we did erase the background but we don't care, + * since we repaint the entire region anyhow + * This avoids some flickering when resizing. + */ + return TRUE; + case WM_PAINT: /* BeginPaint gives us an hdc that clips to the invalidated region */ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: rgb.txt not honored in X7?
Mike Ayers wrote all on one line: From where? I believe this should be ~/.Xdefaults, but the nature of cygwin can make ~ an indefinite place for startup files. I set %HOME%, which becomes $HOME to what will be ~, but if I put XTerm*toolbar: false in $HOME/.Xdefaults I still have toolbars on my xterms. Case is signficant. Try XTerm*toolBar: false .Xresources is xrdb -merge'd by /etc/X11/xinit/xinitrc (i.e. if you use startx) Yes, or in my case by ~/.xinitrc, which I copied from /etc/X11/xinit/xinitrc and modified to taste. But on a recent update startx opened a root window instead of using the Windows windows - because I rely so heavily on that, I switched to startxwin.bat, which is why I now have problems with trhbe value of ~, as well as issues with cut anbd paste (which only seem to manifest when I have a Windows VNC client running..?). If you can tell me what I need to do to restore the old behavior of startx, I'll do that and I think my problems should go away (at least the ~ related ones...). I suspect you used to have the -multiwindow option to the X server in your startx script somewhere (defaultserverargs?) A few people have reported cut-and-paste problems with vncclient also running. If you can spare the time to write a mail (in a new thread) with some clear reproduction steps, that would be most appreciated. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Addition to FAQ 6.1 - X11 forwarding and xauth
I have an additional answer to Cygwin/X FAQ 6.1, X11Forwarding does not work with OpenSSH under Cygwin --- begin A6: If the *remote* machine is a Windows machine using Cygwin OpenSSH, make sure the Cygwin xauth package is installed on the *remote* machine. The OpenSSH server needs xauth to do X11 Forwarding. --- end For a while I was confounded by this: % export DISPLAY=:0 % ssh -Y -f remote-windows-host printenv DISPLAY Warning: No xauth data; using fake authentication data for X11 forwarding. *** DISPLAY not printed here !!! *** % ssh -Y -f remote-unix-host printenv DISPLAY Warning: No xauth data; using fake authentication data for X11 forwarding. localhost:21.0 *** DISPLAY printed as expected *** I finally noticed a message about xauth in the output of ssh -vvv -Y -f remote-windows-host printenv DISPLAY This was hard enough to diagnose that I think it deserves the FAQ entry above. Fred -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Font problem with remote emacs session
I Have not used X in a while ( a few months). I did a complete update to the latest Cygwin packages. When I logged onto the school system , I tried to open an emacs window and got the following: Warning: Cannot convert string -*-courier-medium-r-*-*-*-120-*-*-*-*-iso8859-* to type FontStruct Warning: Cannot convert string -*-helvetica-medium-r-*--*-120-*-*-*-*-iso8859-1 to type FontStruct Emacs title bar and menu bars are OK, but I get square boxes for the loaded file body. The exact same system works OK from my other machine (a OS X system using the X-Window supplied with OS X). I use to be able to remote into the school's system and open Emacs windows with Cygwin-X. Suggestions? -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Font problem with remote emacs session
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Joe Java wrote: I Have not used X in a while ( a few months). I did a complete update to the latest Cygwin packages. When I logged onto the school system , I tried to open an emacs window and got the following: Warning: Cannot convert string -*-courier-medium-r-*-*-*-120-*-*-*-*-iso8859-* to type FontStruct Warning: Cannot convert string -*-helvetica-medium-r-*--*-120-*-*-*-*-iso8859-1 to type FontStruct Emacs title bar and menu bars are OK, but I get square boxes for the loaded file body. The exact same system works OK from my other machine (a OS X system using the X-Window supplied with OS X). I use to be able to remote into the school's system and open Emacs windows with Cygwin-X. Suggestions? 1) http://cygwin.com/acronyms/#PCYMTWLL 2) http://x.cygwin.com/docs/faq/cygwin-x-faq.html#q-where-are-my-fonts Yaakov Cygwin/X -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREIAAYFAkmUz6cACgkQpiWmPGlmQSPBCwCfSEDwrgP74QNVikvCZsjd5uSr RTEAoKAZsvJZDUORHQKvfJdFydGpLf1u =qI6z -END PGP SIGNATURE- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: I Cannot Start the X Server
I recently upgraded and ran into this problem as well. I watched the XWin.exe process using ProcMon from sysinternals.com and it doesn't look like a problem of directory / file / user permissions as the FAQ would suggest. From ProcMon it looks like /tmp/.tX0-lock is being deleted before it is moved. Specifically, it is being opened with options: Synchronous IO Non-Alert, Non-Directory File, Delete On Close The file is then closed and re-opened and the re-open fails because it no longer exists. Have you looked at this? http://x.cygwin.com/docs/faq/cygwin-x-faq.html#modular F. Bron -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
